Web Accessibility and WCAG 2.2 Compliance: A Practical Guide
How to build and remediate sites to WCAG 2.2 AA, from design tokens and focus states to keyboard and screen-reader testing.
Accessibility is no longer a compliance checkbox bolted on at the end of a build. It is a design constraint that shapes markup, color, motion, and interaction from the first wireframe. Teams that treat WCAG 2.2 as part of the definition of done ship faster, get sued less, and reach a materially larger audience than teams that retrofit.
Key takeaways
- WCAG 2.2 AA is the practical benchmark most legal frameworks and procurement teams reference.
- Roughly a quarter of adults report a disability, so accessibility failures are a revenue problem before they are a legal one.
- Automated scanners catch about a third of issues; keyboard and screen-reader passes catch the rest.
- Accessible semantics, contrast, and focus states also improve SEO and general usability.
What WCAG 2.2 AA actually requires
WCAG organizes requirements under four principles: content must be perceivable, operable, understandable, and robust. Level AA is the tier referenced by the ADA guidance in the United States, the European Accessibility Act, and virtually every enterprise procurement questionnaire. It is achievable on any modern stack without compromising visual ambition.
In practice, most AA failures cluster in a small number of predictable places. Fixing those categories systematically resolves the majority of findings in a typical audit.
- Text contrast below 4.5:1, and interface component contrast below 3:1.
- Interactive elements that cannot be reached or operated with a keyboard alone.
- Missing or decorative-only alternative text on images that carry meaning.
- Form inputs without programmatically associated labels and error messaging.
- Focus indicators removed by a CSS reset and never replaced.
- Content that only conveys state through color, such as a red border with no message.
Rule of thumb: If a feature cannot be completed using only the Tab, Enter, Space, and arrow keys, it is not accessible, regardless of what an automated report says.
Build accessibility into the design phase
The cheapest accessibility work happens before a single component is coded. Choosing a palette that already clears contrast ratios, specifying focus styles alongside hover styles, and defining heading hierarchy in the layout eliminates entire categories of rework.
We annotate designs with the semantic element each block should become, the reading order for assistive technology, and the visible focus treatment. Developers then implement from a spec instead of guessing, and QA has something concrete to test against.
- Lock a palette with verified contrast pairs for text, borders, and disabled states.
- Specify hover, focus-visible, active, and disabled states for every interactive component.
- Set a single H1 per page and a logical H2/H3 outline that mirrors the visual hierarchy.
- Design error, empty, and loading states with text, not just iconography or color.
- Respect prefers-reduced-motion for any animation longer than a subtle transition.
Implementation patterns that hold up
Native HTML elements carry accessibility behavior for free. A button element is focusable, announces its role, and fires on Enter and Space. A div with a click handler does none of that until you add a role, a tabindex, and keyboard handlers, and most teams add only one of the three.
When a pattern genuinely requires ARIA, such as a combobox, tab set, or modal dialog, implement against the ARIA Authoring Practices Guide rather than inventing attributes. Incorrect ARIA is measurably worse than no ARIA, because it overrides the accurate information the browser would otherwise expose.
- Use button, a, input, select, and dialog before reaching for ARIA roles.
- Trap focus inside modals, return it to the trigger on close, and support Escape.
- Announce dynamic updates through a polite live region rather than a silent DOM swap.
- Give every image a purposeful alt attribute, and an empty alt when it is decorative.
- Label icon-only controls with visually hidden text or aria-label.
How to test without a dedicated accessibility team
A pragmatic testing loop takes under an hour per major template. Run an automated scanner such as axe or Lighthouse to sweep the mechanical failures, then do a manual keyboard pass on every interactive flow, then listen to the page with a screen reader.
Automated tooling in continuous integration prevents regressions. Adding axe-core to the end-to-end suite means a contrast or label regression fails the build rather than surfacing in an audit six months later.
Testing stack we use: axe DevTools for static scanning, keyboard-only navigation for operability, VoiceOver on macOS and NVDA on Windows for announcement quality, and axe-core assertions inside Playwright to prevent regressions.
The business case
Accessibility lawsuits against websites have run in the thousands per year in the United States alone, and the overwhelming majority target issues that a competent build would never have shipped. But litigation avoidance undersells the return. Accessible sites are easier to use for everyone: clearer labels reduce form abandonment, better contrast helps outdoor mobile users, and semantic structure improves how AI assistants and search crawlers interpret pages.
For organizations selling into government, education, healthcare, or enterprise, an accessibility conformance report is often a procurement requirement. Having one ready shortens sales cycles.
Frequently asked questions
Does an accessibility overlay widget make a site compliant?
No. Overlays cannot repair underlying markup, and a large share of accessibility complaints now name sites that use them. Fix the source.
How long does remediation take on an existing site?
A focused audit and remediation on a typical marketing site runs two to four weeks. Applications with complex interactive components take longer, and are best phased by user flow.
Ready to move on this?
We build every site to WCAG 2.2 AA by default and can audit and remediate an existing property on a fixed scope. Send us the URL and we will return a prioritized findings list.