WCAG 2.2 accessibility testing: a scan is not a compliance program

Most teams treat WCAG 2.2 compliance as a scanner result: run an automated audit, fix what turns red, ship. We treat it as three separate layers of testing that only work in combination. The difference shows up the moment a real user with a screen reader tries to complete your checkout flow.

WCAG 2.2 organizes its requirements around four principles, Perceivable, Operable, Understandable, and Robust, and adds new success criteria on top of WCAG 2.0 and 2.1 rather than replacing them. That backward compatibility matters in practice: it means an existing WCAG 2.1 program does not get thrown out, it gets extended. The new criteria concentrate on three areas that automated scanners have always struggled to judge: focus visibility for keyboard users, touch target sizing for mobile, and simplified, accessible authentication for users with cognitive disabilities.

Scans are a floor, not a ceiling

Tools like Axe, WAVE, and Lighthouse are a reasonable place to start a testing program, and they will find the obvious problems fast: missing alt text, insufficient color contrast, unlabeled form fields. What they cannot do is tell you whether a keyboard user can actually reach and operate every interactive element, or whether a screen reader announces a form error in a way a person can act on. That gap is why an automated result and a compliant site are not the same claim.

• Keyboard-only navigation testing, so focus order and visibility get checked the way a real user experiences them.
• Screen reader testing with tools like NVDA and VoiceOver, so content is verified the way it is actually announced.
• Manual color contrast checks against WCAG 2.2's new focus appearance and target spacing criteria.
• Usability sessions with people who have disabilities, because some barriers only show up when a real person hits them.

A scanner can tell you a site passed. Only a person trying to use it can tell you it works.

Build the process before the deadline

The organizations that struggle most with WCAG 2.2 are the ones treating it as a one-time retrofit against legacy code. A phased approach that prioritizes the issues blocking real users, paired with accessibility checks built into the normal development and design cycle, holds up far better than a pre-launch scramble. Accessibility handled this way stops being a compliance cost and starts being a permanent part of how a wider audience actually reaches your product.