"WCAG 2.2 AA: what to audit and how to test"
A practical guide to auditing for WCAG 2.2 AA: the four principles, what version 2.2 added, how automated and manual testing differ, and how to add checks to CI.
To audit for WCAG 2.2 AA, check your product against the success criteria at levels A and AA under four principles: perceivable, operable, understandable and robust. Use automated tools to catch the mechanical failures, then test with a keyboard and at least one screen reader to find everything tools cannot see. Build the automated part into your pipeline so regressions do not ship.
WCAG, the Web Content Accessibility Guidelines, is a W3C standard. This post is an engineering guide, not legal advice, so confirm which standard and level apply to you with your counsel or regulator.
The four principles
WCAG organizes its success criteria under four principles, often shortened to POUR.
| Principle | The question | Typical checks |
|---|---|---|
| Perceivable | Can users perceive the content? | Text alternatives, captions, contrast, not relying on color alone |
| Operable | Can users operate the interface? | Full keyboard use, enough time, no dangerous flashing, clear navigation |
| Understandable | Is behavior predictable? | Clear labels, explained errors, consistent pages |
| Robust | Does it work with assistive technology? | Correct semantics, name, role and value for custom components |
What AA means
WCAG has three conformance levels: A, AA and AAA. Level A is the baseline, and AA adds criteria that matter to many more users, such as contrast and consistent navigation. AA is the level most laws, procurement rules and standards point to, and it is the practical target for most products. AAA is not usually required for a whole site, since some of its criteria cannot be met for all content.
What WCAG 2.2 added
Version 2.2 builds on 2.1 and adds criteria that matter for real interfaces.
| Addition | What it asks | Usual offender |
|---|---|---|
| Focus visibility | Keyboard focus is not hidden | Sticky headers, cookie banners and chat widgets covering the focused element |
| Target size | Pointer targets are at least 24 by 24 CSS pixels, with some exceptions | Tiny icon buttons packed together |
| Accessible authentication | No cognitive test to log in unless an alternative exists | Blocked paste, puzzles, memory-only passwords |
| Dragging alternatives | A single-pointer alternative to dragging | Sliders, sortable lists, map pans |
| Consistent help and redundant entry | Help in a consistent place, no re-entering known data | Multi-step forms that ask twice |
Automated versus manual testing
| Approach | Reliably catches | Cannot judge |
|---|---|---|
| Automated scanners | Missing alt text, low contrast, missing labels, invalid ARIA | Meaningful alt text, sensible focus order, usable custom widgets |
| Manual testing | Focus order, keyboard traps, announcements, content quality | Nothing at scale, since it is slower and harder to repeat |
A workable audit moves through these stages:
- 01Scopepick key flows and states
- 02Scanrun automated checks
- 03Manualkeyboard and screen reader
- 04Fixtriage by severity
- 05Guardadd checks to CI
The manual pass
Work through these on every key flow:
- Keyboard only. Unplug the mouse. Every control works with Tab, Shift+Tab, Enter, Space and arrow keys, focus is always visible, the order is logical, you can leave modals and menus, and there is no keyboard trap
- Screen reader. Test with at least one common pairing, such as NVDA or JAWS on Windows and VoiceOver on macOS and iOS, and listen for page titles, headings, landmarks, form labels, error announcements and live updates
- Zoom and reflow. At higher browser zoom and text size, content reflows without losing information or needing two-dimensional scrolling for ordinary text
- Contrast and color. Text, icons and focus indicators checked against their backgrounds, in each theme
- Motion and time. Reduced-motion settings respected, with user control over auto-playing and timed content
- Real users. Testing with people who use assistive technology every day, which finds problems no checklist predicts
Put checks in CI
Run what can be automated on every change, so accessibility regressions fail like any other bug.
- Add a linter for accessibility rules in your component code, which flags problems while developers type.
- Run an engine such as axe-core against rendered pages in your end-to-end tests, covering key flows and each state, such as open modals, error states and logged-in views.
- Fail the CI/CD build on new violations, and keep a documented baseline for existing ones so the number only goes down.
- Add accessibility cases to your regression testing suite for components like menus, dialogs and forms.
- Keep a short manual checklist in your pull request template for keyboard and screen reader checks on UI changes.
How this looks at Techdome
For a UAE public-sector tourism programme, we delivered digital accessibility advisory and a UX audit across 5 user archetypes, with live testing involving People of Determination. The work targeted WCAG 2.2 AA and EN 301 549, used Axe-core alongside NVDA, JAWS and VoiceOver, and produced 11 compliance artifacts. The audit scope was about 640 hours.
The mix matters more than the tool names: scanners for coverage, assistive technology for judgment, and real users for the problems neither finds. For more, see accessibility and UX.
Takeaways
- WCAG 2.2 AA means meeting level A and AA criteria across the four principles, on whole pages and flows.
- Version 2.2 added focus visibility, target size, accessible authentication and dragging alternatives, among others.
- Automated tools catch only part of the issues. Keyboard and screen reader testing finds the rest.
- Run an engine like axe-core in CI and fail builds on new violations.
- Involve users of assistive technology, and confirm legal requirements with counsel.
Have a project like this? Talk to our engineers.
