WCAG 2.1 vs 2.2: what changed and which version you need

2.4.11 Focus Not Obscured (Minimum), level AA

This criterion requires that when a component receives keyboard focus, it is not entirely hidden by other author content. It helps sighted keyboard users, including people with motor and cognitive disabilities, who track their position by the focus indicator. A common failure: a sticky header or a cookie banner that stays pinned to the top of the viewport, so that tabbing to a link near the top scrolls it under the fixed element and the user loses sight of where they are. The fix is usually CSS scroll-padding on the scroll container, or reserving space so the focused element is never fully covered. This is partly automatable because a tool can detect fixed and sticky elements and flag likely overlaps, but confirming that focus is fully hidden across states still needs a human pass.

2.4.12 Focus Not Obscured (Enhanced), level AAA

The enhanced version raises the bar from "not entirely hidden" to "not hidden at all". No part of the focused component may be covered by author content. It helps the same keyboard users who benefit from 2.4.11, giving them a fully visible indicator rather than a partial one. A failure looks similar: a focused button whose bottom edge slides beneath a sticky footer. Fixing it means guaranteeing full visibility, typically with generous scroll-padding on both axes or by making overlays dismiss on focus. Because it depends on pixel-level visibility judgement across layouts and viewport sizes, treat it as a manual check.

2.4.13 Focus Appearance, level AAA

Focus Appearance sets a minimum size and contrast for the visible focus indicator, so that the indicator itself is easy to see. It helps low-vision keyboard users for whom a thin, low-contrast outline is effectively invisible. A failure is the classic one-pixel light-grey outline on a white background, or a custom style that removes the outline and replaces it with a barely perceptible tint. The fix is a thick, high-contrast focus ring that meets the area and contrast thresholds, for example a solid two-pixel outline with sufficient contrast against both the component and its background. Judging area and contrast per state makes this a manual evaluation. If your focus styles are missing entirely, start with our focus not visible fix.

2.5.7 Dragging Movements, level AA

If any functionality is operated by a dragging movement, there must be a single-pointer alternative that does not require dragging, unless dragging is essential. It helps people with motor disabilities and anyone using a device where precise dragging is hard, such as a head pointer or a switch. A failure: a slider or a kanban board where the only way to move an item is to press and drag it. The fix is to add buttons, tap targets, or a menu that performs the same action with a single click or tap. This is a manual check because a tool cannot reliably tell that a given feature relies on dragging or that the alternative reaches the same result.

2.5.8 Target Size (Minimum), level AA

Pointer targets must be at least 24 by 24 CSS pixels, unless one of the exceptions applies: sufficient spacing around a smaller target, an inline target within a block of text, a target whose size is controlled by the user agent, or a case where a specific presentation is essential. It helps people with reduced dexterity and anyone on a small touchscreen. A failure: a row of 16-pixel social icons packed tightly together in a footer. The fix is to enlarge the target or its hit area, or to add spacing so the exception is met. This is partly automatable: a scanner can measure rendered size and flag targets under the threshold, but deciding whether the spacing or essential exception applies needs judgement. See our small touch target fix for the concrete CSS.

3.2.6 Consistent Help, level A

When a set of pages provides help mechanisms, such as a contact link, a phone number, a chat widget, or a self-help option, they must appear in the same relative order across those pages. It helps people with cognitive disabilities who rely on finding help in a predictable place. A failure: a support link that sits in the header on one page, drops into the footer on the next, and disappears on a third. The fix is to place help mechanisms consistently in the layout so their relative order never changes. This is a manual check because it compares placement and meaning across pages, which a single-page scan does not capture.

3.3.7 Redundant Entry, level A

Information that a user has already entered in the same process must be auto-populated or available to select, rather than requested again, unless re-entering it is essential, for example a password confirmation. It helps people with cognitive and memory disabilities, and anyone doing a long form. A failure: a checkout that asks for the shipping address, then asks for the identical billing address again with no "same as shipping" option. The fix is to carry earlier answers forward or offer a one-tap copy. This is a manual check because it depends on the semantics of a multi-step flow, which automated tooling cannot follow reliably.

3.3.8 Accessible Authentication (Minimum), level AA

Authentication must not require a cognitive function test, such as remembering a password or solving a puzzle, unless an alternative method is available, or a mechanism assists the user, or the test recognizes objects or user-provided content. It helps people with cognitive disabilities who cannot reliably memorize or transcribe secrets. A failure: a login that blocks paste and forbids password managers, forcing the user to remember and retype a complex string, or a puzzle-style CAPTCHA with no alternative. The fix is to allow paste, support password managers and passkeys, and avoid memory-based puzzles. Missing autocomplete attributes are a frequent underlying cause; see our autocomplete missing fix. This is a manual check.

3.3.9 Accessible Authentication (Enhanced), level AAA

The enhanced version removes the exceptions that 3.3.8 allows for recognizing objects or user-provided content, so authentication may rely on no cognitive function test at all beyond the permitted assistive mechanisms. It helps the same users, more strictly. A failure: a login step that asks the user to identify images of a specific type, which 3.3.8 tolerated but 3.3.9 does not. The fix is to move entirely to passkeys, links sent to a verified device, or another route that carries no memory or recognition test. This is a manual check.

What was removed: 4.1.1 Parsing

WCAG 2.2 removes success criterion 4.1.1 Parsing, which required markup to avoid duplicate IDs and certain nesting errors. The W3C marked it obsolete because modern browsers and assistive technologies recover from these markup issues on their own, so the criterion no longer measured a real barrier. The change is retroactive in spirit: the W3C treats 4.1.1 as always satisfied in the 2.0 and 2.1 errata too. In practice this means one fewer thing to test, and it means you should stop counting duplicate-ID and parsing errors as WCAG failures under 2.2. The genuinely user-facing part of what people associated with 4.1.1, such as accessible names and roles, lives on in 4.1.2 Name, Role, Value, which is unchanged. Everything else from 2.1 carries over exactly, which is why a 2.2 AA page conforms to 2.1 AA.

Which laws require which version

Standards and statutes move at different speeds. The W3C published 2.2 in 2023, but regulations adopt a version by naming it, and most still name 2.1 AA. The table below is the picture as of 2026. Treat it as a starting point and verify the current wording of the law and its referenced standard, because the referenced version is the part most likely to change.

Does 2.1 compliance still count?

Yes. This is the most reassuring fact about the move from 2.1 to 2.2. Because 2.2 only adds criteria and removes an obsolete one, none of your 2.1 conformance is invalidated. A page that met 2.1 AA still meets 2.1 AA, and where a law still names 2.1 AA, that page is still compliant. Your existing audit, your remediation log, and your accessibility statement all remain valid for the standard they targeted. What changes is that if you want to claim 2.2 AA, or if your regulator adopts 2.2, you have a small, well-defined delta to close: the six new A and AA criteria. You are extending a passing result, not starting over. The reality across the web, though, is that most sites are not even at 2.1 yet. In Certvo's scan of 1,564 websites, only 18.8% passed every automated 2.1 AA check, so for most teams the honest first move is reaching 2.1, then layering 2.2 on top.

Migration checklist: 2.1 to 2.2

If you already have a 2.1 baseline, here is the concrete path to a defensible 2.2 AA claim. Work through it in order.

1. Confirm your current 2.1 AA conformance is real and dated, not assumed. Re-scan if the evidence is stale.
2. Audit 2.4.11 Focus Not Obscured: tab the whole site and watch for focus hidden under sticky headers, footers, and cookie bars.
3. Audit 2.5.7 Dragging Movements: list every drag interaction and add a single-pointer alternative to each.
4. Audit 2.5.8 Target Size: measure interactive targets, enlarge or space any under 24 by 24 CSS pixels, and document any exception you rely on.
5. Audit 3.2.6 Consistent Help: fix the relative order of help mechanisms across templates so it never shifts.
6. Audit 3.3.7 Redundant Entry: find places that re-ask for data already entered and auto-populate or offer to copy it.
7. Audit 3.3.8 Accessible Authentication: allow paste, support password managers and passkeys, and remove memory puzzles from login.
8. Stop reporting 4.1.1 Parsing failures, update your accessibility statement and VPAT to name 2.2, and set a re-scan schedule so a later change does not quietly regress a criterion.

What automated scanners can and cannot test in 2.2

Be honest about tooling, because overclaiming here is how a compliance program fails an audit. Of the nine new criteria, only two are even partly machine-testable. A scanner can measure target size for 2.5.8 and flag targets under 24 by 24 CSS pixels, though it cannot decide whether the spacing or essential exception legitimately applies. A scanner can detect fixed and sticky elements and surface likely focus-obscured cases for 2.4.11, but confirming that focus is genuinely hidden is a human judgement. The remaining criteria, dragging alternatives, focus appearance and full visibility, consistent help, redundant entry, and accessible authentication, are manual by nature: they depend on multi-page behaviour, on the semantics of a flow, or on pixel-level and interaction judgement that no single-page automated pass can resolve.

That is the correct way to use a scanner: as the fast, repeatable layer that catches the mechanical failures and gives you a measured baseline, not as the whole audit. Run an automated pass to find the 2.1 issues and the two partly automatable 2.2 checks, then spend human time on the criteria that only a person can judge. A free accessibility scan gives you that baseline in minutes and shows exactly which findings are decided by the tool and which still need a manual review.

Frequently asked questions