WCAG 2.2 Audit Checklist 2026: every AA criterion, tested

A WCAG 2.2 accessibility audit is only as current as the checklist behind it — and most teams are still running the 2.1 list. WCAG 2.2 became a W3C Recommendation on October 5, 2023, added nine new success criteria, and removed one (4.1.1 Parsing). If your QA gate has not been re-pointed at 2.2, you are quietly failing criteria that regulators and litigants increasingly treat as the baseline.

The stakes are not abstract. The 2026 WebAIM Million report found that 95.9% of the top one million home pages had detectable WCAG failures, up from 94.8% a year earlier, with low-contrast text alone affecting 83.9% of pages. Detectable means an automated tool flagged it — and automation only sees part of the picture. The honest figure, from Deque's coverage study, is that tooling catches roughly 57% of accessibility issues by volume; the remainder needs a human at a keyboard and a screen reader.

This guide is built to be used, not just read. Below you will find the complete Level AA checklist mapped criterion-by-criterion to a one-line test method and its single most common failure, a clear line between what automation catches and what it cannot, the WCAG 2.2 criteria most auditors still miss, and the ADA and European Accessibility Act context that determines which version your clients are actually on the hook for.

Accessibility has moved from a nice-to-have to a measurable risk surface, and the gap between intent and execution is widening rather than closing. The WebAIM Million project automatically tests the home pages of the top one million websites every year; the 2026 report recorded an average of 56.1 detectable errors per page, up 10.1% year-over-year. That regression is not because the standard got harder — WCAG 2.2 is largely a superset of 2.1 — but because pages keep getting more complex.

The same report found home-page DOM complexity grew 22.5% in a year, and the average number of ARIA attributes per page climbed 27% to more than 133. That last number is the trap worth naming: more ARIA does not mean more accessible. Misapplied roles and states routinely introduce new failures that an automated scanner cannot catch and a screen-reader user trips over immediately. The teams shipping the most markup are often shipping the most defects.

Against that backdrop, re-pointing your audit at WCAG 2.2 is the cheapest reliability win available. The five new Level AA criteria are concrete and testable, the removal of 4.1.1 Parsing eliminates a criterion many auditors still waste time on, and the structure below turns a vague obligation into a checklist a QA engineer can run without an accessibility-specialist credential. Accessibility, like a front-end performance audit, belongs in your CI quality gate — not in a once-a-year scramble.

WCAG 2.2 introduced nine new success criteria and removed one. The removal matters as much as the additions: 4.1.1 Parsing is gone, because modern browsers handle malformed HTML robustly enough that the criterion became effectively obsolete. If your inherited 2.1 checklist still lists 4.1.1, you are spending audit time on a criterion that no longer applies — and any conformance claim that cites it needs updating.

Of the nine additions, five sit at Level AA, which is the bar most laws and clients target. Two more land at Level A. The remaining ones, including 2.4.13 Focus Appearance, are Level AAA and outside the scope of a standard AA audit. A common error in third-party checklists is promoting 2.4.13 to AA or demoting 2.5.7 Dragging Movements to AAA — both are wrong against the W3C source. The cards below summarise the additions that change your AA obligations.

The two new Level A criteria are easy wins that audits frequently overlook. 3.3.7 Redundant Entry requires that information already supplied in a multi-step process be auto-populated or selectable rather than re-typed — the common failure is clearing valid form data after a validation error in a later step. 3.2.6 Consistent Help requires that help mechanisms (phone, chat, FAQ links) appear in the same relative order across pages; moving a live-chat widget from top-right on one page to bottom-left on another fails it. Both are cheap to satisfy and cheap to break during a redesign.

This is the proprietary core of the guide: every Level AA success criterion that is unique to Level AA, each mapped to a one-line test method, its single most common failure, and whether automated tooling can fully evaluate it. Rows tagged NEW were introduced in WCAG 2.2 and are the ones a 2.1-era checklist will be missing. The 32 Level A criteria are also required for AA conformance but are not repeated here; this table isolates the AA-specific layer where most audit gaps live.

The Auto column is the part teams most often misread. "Yes" means a scanner can reliably determine pass/fail; "Partial" means it flags candidates but a human confirms; "No" means the criterion is effectively a manual judgment. Notice how many of the highest-value criteria — focus visibility, dragging alternatives, consistent navigation, error suggestion — sit at "No." That is not a tooling gap to be fixed later; it is the structural reason accessibility cannot be fully automated.

Two numbers get quoted about automated accessibility testing, and they appear to contradict each other until you understand what each measures. The first: axe-core (the open-source engine from Deque, v4.11.4 as of April 2026) catches approximately 57% of accessibility issues by volume in real audits. The second: only about 29.5% of WCAG 2.2 success criteria are fully automatable, with another 10.3% partly covered and 60.2% requiring manual testing. Both are correct.

The reconciliation is that a small number of highly automatable criteria account for an outsized share of real-world defects. Per Deque's coverage data, contrast, language-of-page, and name/role/value together represent roughly 58.8% of all real accessibility issues by volume — and all three are categories automation handles well. So a scanner clears a huge fraction of the defect count while still touching only a minority of the criteria. Optimise for the wrong number and you either over-trust automation or dismiss it.

Google Lighthouse uses axe-core as its accessibility engine but runs a subset of the rules and produces a weighted 0–100 score, so in practice it catches a smaller share of real-world issues than running axe-core directly. The practical takeaway: a Lighthouse accessibility score of 100 is a floor, not a finish line. It confirms the automatable criteria pass; it says nothing about focus order, screen-reader semantics, or whether your drag interactions have a click alternative.

Focus management is the canonical example of why automation is not enough. Focus Order (2.4.3), Focus Visible (2.4.7), and Meaningful Sequence (1.3.2) are effectively 100% manual categories — no scanner reliably evaluates whether the focus path through your page makes sense to someone who cannot see it. These need a person tabbing through every interactive element, watching the indicator, and confirming the order matches the visual and logical flow.

The W3C WAI-ARIA Authoring Practices Guide (APG) defines the keyboard conventions complex widgets are expected to follow. The core rule: Tab and Shift+Tab move focus into and out of a composite widget, while arrow keys navigate within it — the "roving tabindex" pattern used by grids, trees, toolbars, and tab panels. If a custom component does not follow these conventions, no automated tool will tell you; a keyboard-only user will discover it in seconds. Teams building in React should bake these patterns into their components directly — see our Next.js accessibility considerations for where focus and ARIA work sits in a Server Components architecture.

The WebAIM Million 2026 report gives the most reliable picture of where accessibility actually fails at scale, because it tests real home pages rather than curated examples. Six failure categories dominate, and the striking part is that nearly all of them are automatable — meaning these are not subtle judgment calls, they are defects a scanner in CI would have caught before deploy.

Low contrast is the standout, and not just because it tops the list at 83.9% of pages — it is because the figure rose from 79.1% the year before. Contrast is one of the most automatable criteria there is, yet its prevalence keeps climbing as design systems chase muted greys and ever-lighter placeholder text against white. The lesson is structural: a defect being automatable does nothing if the automation never runs in the pipeline. The single highest-leverage move for most teams is wiring axe-core into CI so these six categories simply cannot ship.

The most common compliance mistake is assuming "the law requires WCAG 2.2" everywhere. It does not — yet. Different regimes reference different versions, and conflating them leads to either over-engineering or a false sense of safety. The decision cards below map the major regimes to the WCAG version each currently enforces and the practical posture we recommend.

A defensible audit is layered, not a single tool run. Start with the automated pass to clear the high-volume, high-automation defects — contrast, missing labels, empty controls, page language. Run axe-core (or a wrapper like Lighthouse) across representative templates rather than every URL, because most failures are template-level, not page-level. This pass alone should eliminate the bulk of the WebAIM Million top-six failures.

Then layer the manual passes the table marks as "No": a full keyboard traversal for focus order, visibility, and traps; a screen-reader pass for names, roles, states, and status messages; and a reflow-and-zoom check at 200% and 320px width. Finally, walk the new WCAG 2.2 criteria explicitly, since they are the ones a carried-over 2.1 checklist will silently skip — focus not obscured by sticky elements, 24px target sizing, dragging alternatives, accessible authentication, redundant entry, and consistent help.

This layering applies with extra force to commerce flows. The EAA scope explicitly includes e-commerce, and checkout is where the new criteria concentrate: redundant entry across multi-step forms, target sizing on quantity steppers, and accessible authentication at login. If you are auditing a store, fold accessibility into your broader ecommerce accessibility requirements review so the checkout path is tested as one system. For teams that want this operationalised as a recurring quality gate rather than a one-off, our web development engagements build accessibility testing directly into CI, and our broader AI digital transformation work covers the governance side for organisations standardising across many properties.