WCAG 2.1 vs 2.2: What Actually Changed and What Your Team Needs to Re-Test

WCAG 2.2 added nine success criteria in total, but only the A and AA ones are in scope for legal baselines that reference WCAG A and AA, such as EN 301 549. That leaves six new A/AA criteria to action and one criterion removed. The AAA additions are good practice but not required for AA conformance.

• 2.4.11 Focus Not Obscured (Minimum) — AA, Operable
• 2.5.7 Dragging Movements — AA, Operable
• 2.5.8 Target Size (Minimum) — AA, Operable
• 3.2.6 Consistent Help — A, Understandable
• 3.3.7 Redundant Entry — A, Understandable
• 3.3.8 Accessible Authentication (Minimum) — AA, Understandable
• Plus AAA additions: 2.4.13 Focus Appearance and 3.3.9 Accessible Authentication (Enhanced) — not required for AA
• Removed: 4.1.1 Parsing — obsoleted in 2.2

If you maintain an accessibility checklist, these are the rows to add. Everything else carries over from 2.1 untouched.

WCAG 2.1 already required a visible focus indicator (2.4.7). What it did not say was that the focused element must actually be on screen. 2.4.11 closes that hole: when a component receives keyboard focus, it must not be entirely hidden by author-created content such as a sticky header, a cookie banner, or a floating chat bubble.

This is one of the most common real-world failures. Picture a sticky header that is 80px tall. A keyboard user tabs down the page, and as focus reaches a link near the top of the viewport, the browser scrolls it into view — directly under the fixed header, where the focus ring is invisible. The fix is usually CSS: add scroll-padding-top to the scroll container, or reserve space so sticky elements never cover the focused control. Test it by tabbing through every page with a sticky or fixed element and watching where focus lands.

The AAA sibling, 2.4.13 Focus Appearance, goes further by dictating the minimum size and contrast of the focus indicator itself. You do not need it for AA, but meeting it is cheap insurance and good design.

2.5.7 Dragging Movements (AA)

Any functionality that works by dragging must also have a single-pointer alternative that does not require dragging. Think of a kanban board, a reorderable list, a map you pan, or a slider you drag. Users with tremors, limited dexterity, or a head-pointer often cannot perform a sustained drag. The alternative does not have to be elegant: move-up / move-down buttons next to a draggable item, or clickable +/- controls on a slider, both satisfy it. There is an exception when dragging is genuinely essential, such as a freehand drawing canvas, but that bar is high.

2.5.8 Target Size (Minimum) (AA)

Pointer targets must be at least 24 by 24 CSS pixels, or a smaller target must have enough spacing that a 24px circle centred on it does not overlap an adjacent target. Note this is the more forgiving AA threshold — the 44px figure people remember comes from common platform design guidance and the stricter AAA criterion (2.5.5), not WCAG 2.2 AA. Several exceptions apply: inline links inside a sentence, targets whose spacing keeps them apart, and controls whose size is determined by the browser (a default checkbox) or is essential. The usual offenders are cramped icon-only buttons, tight pagination controls, and close (×) icons. Audit toolbars, footers, and table-row action icons first.

3.2.6 Consistent Help (A)

If your site offers a help mechanism — a contact link, a phone number, a chat widget, an FAQ link — and it appears on multiple pages, it must appear in the same relative order across those pages. The point is predictability: a user who relies on routine should not have to re-hunt for support on every page. This is an A-level criterion and usually a layout/template fix, not a code change. It does not force you to add help; it governs consistency if help exists.

3.3.7 Redundant Entry (A)

Within a single process (a checkout, a multi-step form, an application), do not ask users to re-enter information they already provided in the same process. Auto-populate it, or let them select it (the classic “billing address same as shipping” checkbox). This reduces load for everyone but especially for people with cognitive disabilities or anyone using a screen magnifier where re-finding and re-typing data is costly. Exceptions exist where re-entry is essential, such as confirming a password. Anyone building accessible forms should treat this as a default expectation.

3.3.8 Accessible Authentication (Minimum) (AA)

This is the one most likely to require engineering work. A login step must not depend on a cognitive function test — remembering a password, solving a puzzle, transcribing characters — unless an alternative, a mechanism to assist, or an exception applies. Crucially, the criterion is satisfied if you let password managers work: do not block paste into password fields, use correct autocomplete attributes (autocomplete="current-password"), and let the browser fill credentials. Email magic links, passkeys/WebAuthn, and OAuth (“sign in with…”) also pass. A pure text-distortion or puzzle CAPTCHA with no alternative fails. WCAG carves out exceptions for object recognition and identifying non-text content the user provided, so an image-selection step recognising everyday objects can pass — but a math or memory CAPTCHA does not.

WCAG 2.2 removed 4.1.1 Parsing, which previously required that markup avoid duplicate IDs, properly nest elements, and have complete start/end tags. It is the only criterion ever to be obsoleted, and it is the one piece of genuinely good news for migrating teams.

The reasoning: when 4.1.1 was written, assistive technologies parsed HTML themselves and broke on malformed markup. Modern browsers now build a consistent, error-corrected DOM, and assistive tech reads that DOM rather than the raw source. The specific failures 4.1.1 guarded against either no longer cause accessibility problems or are already caught by other criteria — for example, a duplicate id that breaks a label/for association still fails 1.3.1 Info and Relationships or 4.1.2 Name, Role, Value. So 4.1.1 is now treated as “always satisfied” in both WCAG 2.1 and 2.2 going forward.

Practical impact: you can stop treating raw HTML-validator parsing errors as conformance blockers. Valid markup is still worth keeping for maintainability and to avoid those downstream 1.3.1/4.1.2 failures — but a stray unclosed tag is no longer, by itself, a WCAG failure.

Because 2.2 is additive, you do not need a fresh full audit. Run a targeted gap pass against the six new A/AA criteria, in roughly this order of effort:

• Authentication (3.3.8) — highest risk. Check that paste is allowed, autocomplete is set, and no puzzle/transcription step lacks an alternative. Often needs dev work.
• Target size (2.5.8) — sweep icon buttons, pagination, close icons, and table-row actions for anything under 24px without enough spacing.
• Dragging (2.5.7) — find every drag interaction and confirm a click-based alternative exists.
• Focus not obscured (2.4.11) — tab through pages with sticky/fixed elements and add scroll-padding where focus disappears.
• Redundant entry (3.3.7) and Consistent help (3.2.6) — mostly template and form-flow fixes; low effort, do them in a batch.

An automated checker catches a meaningful slice of this — target sizes, missing autocomplete, contrast, duplicate IDs — but criteria like dragging alternatives and consistent help placement need human judgement. Run your pages through AccessScan to surface the machine-detectable gaps, then hand the rest to a manual pass.