Frequently asked questions
Quick answers to common questions. If you don't see yours, get your audit and we'll walk through it.
About A11ySolutions
We typically audit against WCAG 2.2 AA (included WCAG 2.1 AA). We confirm the standard and scope based on your industry, procurement requirements, and risk profile. WCAG defines conformance criteria by level (A/AA/AAA).
It depends on scope (templates, critical flows, and platforms). For a focused scope, a web audit usually completes in 1–4 weeks and includes prioritized findings and remediation guidance.
Yes. We support creating or updating VPAT/ACR documents with defensible evidence based on technical product evaluation. A VPAT is used to document conformance and communicate it during procurement.
Yes. We can work with your team to remediate issues (component patterns, implementation guidance, acceptance criteria) and provide retesting/validation to reduce regressions before release.
Yes. We combine automated testing with manual evaluation: keyboard, screen reader, focus, semantics, and real user journeys. This catches issues that scanners miss in complex flows.
A short kickoff to define scope (URLs or builds), target standard (e.g., WCAG 2.2 AA), and critical journeys. From there we propose a plan, deliverables, and timeline; if applicable, we coordinate access to environments and design artifacts.
Accessibility FAQs
General questions about web accessibility, WCAG, audits, and compliance.
Web accessibility is the design and development of websites and digital products so they can be used by people with disabilities (visual, motor, cognitive, hearing), including users of screen readers and keyboard navigation. It also improves the user experience (UX) for everyone (mobile, low connectivity, older users).
WCAG 2.2 (Web Content Accessibility Guidelines) is the most widely used standard for evaluating accessibility compliance. Many enterprise procurement policies and requirements are based on WCAG, typically at the AA level.
It means that your product meets (or is aligned with) a set of criteria that cover aspects such as contrast, forms, focus, text alternatives, keyboard navigation, and proper behavior with assistive technologies. It is not "perfect," but it is the most common level of compliance.
The reliable way is an accessibility audit with manual and automated testing, including keyboard and screen reader testing. Scanners help, but they don't accurately detect issues with semantics, focus, tab order, misapplied ARIA, or actual user flows.
An audit is a structured evaluation against WCAG that produces a report of findings, evidence, severity, impact on users, and a prioritized remediation backlog (what to fix first, with technical guidance). Many organizations also use it for a defensible compliance baseline.
It depends on the scope (templates, critical flows, web/app). For a focused scope, it typically takes 1–4 weeks to deliver the report and roadmap; large products are usually addressed in phases (templates + journeys).
Automated validation detects patterns (e.g., missing alt text, labels, some contrast issues), but manual validation addresses what truly impacts tasks: keyboard, screen reader, focus, modals, error messages, semantics, and interaction logic. It's best to combine them.
A VPAT®/ACR (Accessibility Conformance Report) is the most common format for documenting accessibility conformity in procurement processes (especially in the enterprise and public sectors). It doesn't replace addressing issues, but it helps communicate the status and the plan.
EN 301 549 is a European standard for accessibility requirements for ICT (including web, software, documentation, etc.) and typically references WCAG for the web component. The EAA (European Accessibility Act) is a legal framework; in practice, many implementations rely on WCAG + EN 301 549 depending on the context.
The most frequent are usually insufficient contrast, forms without clear labels, unannounced errors, poor focus management (especially in modals), incomplete keyboard navigation, and weak semantic structure (headings/landmarks).
Start with: correct semantic structure (headings/landmarks), visible and logical focus, interactive components operable with the keyboard, well-labeled forms, and clearly announced states/errors. Use ARIA only when necessary and always validate with a screen reader.
Yes, if they are part of the user experience (policies, contracts, reports, invoices). An accessible PDF requires a tagged structure, correct reading order, headings, marked tables, selectable text, and image alternatives; otherwise, it can break end-to-end compliance.
Users and business: People with disabilities (and many mobile users or users with time constraints) may not complete key tasks such as registering, purchasing, or requesting support, which reduces conversions and increases abandonment. Legal and compliance risk: You may be exposed to claims or audits depending on the applicable framework (for example, WCAG 2.2 as a technical reference, and requirements such as ADA/Section 508 or European frameworks linked to EN 301 549/EAA, depending on the country and sector). Cost and delays: The later the problems are detected (whether in QA or production), the more expensive they are to correct and the greater the risk of regressions. The most efficient way is usually an accessibility audit + a prioritized remediation backlog and retest.