How to test for WCAG 2.2
The nine criteria new in 2.2 are mostly manual. Here is what automated tools catch, the small toolkit you need, and a one-line test for every new criterion.
Automated vs manual
Automated accessibility tools are excellent at the things machines can see — missing alt text, empty buttons, color-contrast on static text, missing form labels — but they evaluate only a portion of WCAG, commonly cited at roughly a third of the criteria (Source: W3C WAI, Evaluating Web Accessibility ) . The nine 2.2 additions are mostly about behavior — what happens when you focus, drag, or log in — which a tool cannot reliably judge. So the model is:
- Automated first pass: run axe (or equivalent) to clear the carried-forward 2.0/2.1 issues quickly and consistently.
- Manual review: verify the nine new criteria by hand, plus everything automation cannot see (meaningful alt text, logical reading order, sensible focus order).
The minimum toolkit
- A keyboard. Tab, Shift+Tab, Enter, Space, Escape, and arrow keys cover focus order, the obscured-focus criteria, and dragging alternatives.
- Browser dev tools. The box model reports target sizes in CSS pixels for 2.5.8; the inspector reveals sticky elements that obscure focus.
- A contrast / color picker. To check the 3:1 change-of-state contrast for 2.4.13 and non-text contrast generally.
- A password manager. To confirm autofill and paste are not blocked for 3.3.8 and 3.3.9.
- An automated checker such as axe-core, plus a screen reader (NVDA, VoiceOver, or JAWS) for the carried-forward criteria.
Test the 9 new criteria
A one-line verification for each criterion added in WCAG 2.2, with how much an automated tool can help. Linked names open the full reference page with thresholds, code, and exceptions.
| SC | Criterion | Level | How to test | Automated? |
|---|---|---|---|---|
| 2.4.11 | Focus Not Obscured (Minimum) | AA | Tab through the page with sticky headers, footers, and banners present; confirm no focused element is entirely hidden. | Manual |
| 2.4.12 | Focus Not Obscured (Enhanced) | AAA | Same as 2.4.11, but confirm no part of any focused element is covered. | Manual |
| 2.4.13 | Focus Appearance | AAA | Inspect each focus indicator for at least a 2 px perimeter area and a 3:1 contrast change between focused and unfocused states. | Partial |
| 2.5.7 | Dragging Movements | AA | For each drag interaction, confirm a single-pointer click or tap alternative exists. | Manual |
| 2.5.8 | Target Size (Minimum) | AA | Measure pointer targets; confirm at least 24 by 24 CSS px, or that an exception (spacing, inline, user-agent, essential, equivalent) applies. | Partial |
| 3.2.6 | Consistent Help | A | If help links or contact options repeat across pages, confirm they appear in the same relative order. | Manual |
| 3.3.7 | Redundant Entry | A | In multi-step processes, confirm earlier-entered data is auto-filled or selectable rather than re-typed. | Manual |
| 3.3.8 | Accessible Authentication (Minimum) | AA | Confirm login allows password autofill and paste, accepts pasted one-time codes, or offers a non-cognitive method. | Manual |
| 3.3.9 | Accessible Authentication (Enhanced) | AAA | As 3.3.8, plus confirm no object-recognition or personal-content test is relied on. | Manual |
“Partial” means a tool can flag some failures (for example, axe has a target-size rule for 2.5.8) but cannot confirm a pass; a human still has to judge the exceptions and edge cases.
A repeatable method (WCAG-EM)
For a defensible evaluation rather than a spot check, follow the W3C’s Website Accessibility Conformance Evaluation Methodology, WCAG-EM (Source: W3C, WCAG-EM 1.0 ) . Its five steps:
- Define the scope — the site, the target (WCAG 2.2 AA), and the conformance basis.
- Explore the site — identify page types, key flows, and the technologies in use.
- Select a representative sample — common pages, complete processes (checkout, sign-up), and a random sample.
- Audit the sample — test each page against every Level A and AA criterion, automated then manual.
- Report the findings — record outcomes per criterion, which feeds your conformance statement.
For a quick sanity pass before a full audit, W3C’s Easy Checks are a good starting point (Source: W3C, Easy Checks ) .
What automated tools miss
To set expectations honestly: a clean automated report does not mean conformance. Tools cannot judge whether a drag has a real single-pointer alternative (2.5.7), whether help is in a consistent order across pages (3.2.6), whether a form actually re-uses earlier input (3.3.7), or whether login avoids a cognitive-function test (3.3.8 / 3.3.9). They also cannot tell if alt text is meaningful or if focus order is logical. This site itself passes axe-core with zero violations across every page, and we still treat that as the floor, not the finish line — see our accessibility statement and the conformance checklist.
Common questions
Can an automated tool check WCAG 2.2 compliance?
Only partly. Automated tools like axe reliably catch many of the carried-forward 2.0 and 2.1 issues, but the nine criteria new in WCAG 2.2 are largely manual: focus, dragging alternatives, help consistency, redundant entry, and authentication all need a human. Treat automation as a first pass, not proof of conformance.
How do I test the new WCAG 2.2 success criteria?
Most of the nine need only a keyboard, browser dev tools, a contrast tool, and a password manager. Tab through the page watching focus, look for single-pointer alternatives to any drag, measure target sizes, and walk every login and multi-step form. The per-criterion table on this page gives a one-line test for each.
Does passing axe mean my site is WCAG 2.2 AA compliant?
No. Automated tools evaluate roughly a third of WCAG criteria and cannot judge most of the 2.2 additions. Passing axe with zero violations is necessary but not sufficient; a conformance claim still requires manual review.