WCAG 2.1 vs 2.2: What Changed and How to Migrate
WCAG 2.2 became the official W3C Recommendation on October 5, 2023. It adds nine new success criteria, removes one obsolete criterion (4.1.1 Parsing), and changes nothing else — every other requirement carries over from WCAG 2.1 word for word. Here is the complete list of changes, what each new criterion means in practice, and how to move an existing WCAG 2.1 program to 2.2.
9
New success criteria
1
Criterion removed (4.1.1)
6
New at Level A/AA
86
Total criteria in 2.2
A quick history: 2.0 → 2.1 → 2.2
The Web Content Accessibility Guidelines evolve slowly and deliberately. WCAG 2.0 (December 2008) established the four POUR principles — Perceivable, Operable, Understandable, Robust — and 61 success criteria. WCAG 2.1 (June 2018) added 17 criteria focused on mobile devices, low vision, and cognitive disabilities. WCAG 2.2 (October 2023) adds nine more, concentrated on three groups the earlier versions underserved: users with cognitive and learning disabilities, users with motor impairments, and sighted keyboard users.
Each version is a strict superset of the last (with the single exception of 4.1.1, covered below). That backwards compatibility is the key fact for migration planning: a site that conforms to WCAG 2.2 also conforms to WCAG 2.1 and 2.0 at the same level. The next major revision, WCAG 3.0, is a ground-up redesign that is still years from becoming a standard — 2.2 is what you should build against today.
WCAG 2.1 vs 2.2 side by side
| WCAG 2.1 | WCAG 2.2 | |
|---|---|---|
| Published | June 5, 2018 | October 5, 2023 |
| Total success criteria | 78 | 86 (78 − 4.1.1 + 9 new) |
| Level A criteria | 30 | 31 (+3.2.6, +3.3.7, −4.1.1) |
| Level AA criteria | 20 | 24 (+2.4.11, +2.5.7, +2.5.8, +3.3.8) |
| Level AAA criteria | 28 | 31 (+2.4.12, +2.4.13, +3.3.9) |
| Removed criteria | None | 4.1.1 Parsing (obsolete) |
| Main focus of additions | Mobile, low vision, cognitive | Cognitive, motor impairments, keyboard focus visibility |
| Referenced by law | DOJ ADA Title II rule, EN 301 549 / EAA | Not yet — but conforming to 2.2 satisfies 2.1 references |
| W3C status | Superseded Recommendation | Current Recommendation |
The 9 new success criteria in WCAG 2.2
Six of the nine apply at Level A or AA — the levels legal standards and most conformance targets care about. The remaining three are Level AAA. Each links to our full criterion reference with examples and testing steps.
New at Level A and AA (required for AA conformance)
When a component receives keyboard focus, it is not entirely hidden.
Who it helps: Sighted keyboard users who lose track of focus behind sticky UI.
In practice: Make sure sticky headers, cookie banners, chat widgets, and non-modal footers never completely cover the element that has keyboard focus. Use scroll-padding or adjust z-index/scroll behavior so at least part of the focused element stays visible.
2.5.7 Dragging Movements
Level AAFunctionality that uses dragging has a single pointer alternative.
Who it helps: People with motor disabilities who cannot perform precise drag gestures.
In practice: Any drag-and-drop interaction (sortable lists, sliders, kanban boards, map panning) needs a single-pointer alternative such as up/down buttons, a select menu, or click-to-move — unless dragging is essential.
2.5.8 Target Size (Minimum)
Level AATarget size is at least 24 by 24 CSS pixels except in specific cases.
Who it helps: People with tremors or limited dexterity, and everyone on touch screens.
In practice: Interactive targets must be at least 24 by 24 CSS pixels, or have enough surrounding spacing that a 24px circle centered on each target does not overlap another. Inline links in text, browser-native controls, and essential presentations are exempt.
3.2.6 Consistent Help
Level AHelp mechanisms appear in the same relative order across pages.
Who it helps: People with cognitive disabilities who need to find help quickly.
In practice: If help mechanisms (contact phone/email, contact form, live chat, FAQ/self-help, automated assistant) are offered on multiple pages of a site, they must appear in the same relative order on every page. It does not require adding help — only consistency where help exists.
3.3.7 Redundant Entry
Level AInformation previously entered is either auto-populated or selectable.
Who it helps: People with memory or cognitive limitations filling out multi-step processes.
In practice: Do not ask users to re-type information they already entered in the same process (for example, shipping address again as billing address). Auto-populate it or let them select it — unless re-entry is essential, needed for security, or the info is no longer valid.
Authentication methods don't rely solely on cognitive function tests.
Who it helps: People with cognitive disabilities who cannot memorize or transcribe codes.
In practice: Login must not depend solely on a cognitive function test like memorizing a password or transcribing characters. Supporting password managers and paste, email magic links, passkeys, or OAuth all satisfy it. CAPTCHAs based on object recognition are allowed at this level.
New at Level AAA (optional for most conformance targets)
2.4.12 Focus Not Obscured (Enhanced)
Level AAAWhen a component receives keyboard focus, no part of it is hidden.
In practice: The stricter AAA version of 2.4.11: no part of the focused component may be hidden by author-created content. Only required for AAA conformance claims.
2.4.13 Focus Appearance
Level AAAThe focus indicator has sufficient size and contrast.
In practice: Focus indicators must be at least as large as a 2 CSS pixel thick perimeter around the component and have at least 3:1 contrast between focused and unfocused states. AAA only, but an excellent default for design systems.
Authentication methods don't rely on cognitive function tests.
In practice: The AAA version of 3.3.8: even object recognition (image CAPTCHAs) and identifying personal content are not allowed as the only path to authenticate.
The one removal: 4.1.1 Parsing
WCAG 2.2 is the first version ever to remove a success criterion. 4.1.1 Parsing (Level A) required markup to be well-formed — no unclosed tags, no duplicate IDs, proper nesting. In 2008 that mattered because some assistive technologies parsed HTML themselves and could fail on malformed markup. Today, browsers repair markup errors consistently before assistive technologies ever see the content, so the criterion had stopped catching real accessibility problems while still generating audit noise.
Cases where markup errors genuinely harm users — a duplicate ID that breaks a form label, for instance — are already failures under 1.3.1 Info and Relationships or 4.1.2 Name, Role, Value. The W3C has additionally published errata stating that for HTML content, 4.1.1 should be treated as always satisfied in WCAG 2.0 and 2.1 conformance claims. Practical consequence: you can drop parsing-only findings from your audit backlog regardless of which version you target.
Migrating from WCAG 2.1 AA to 2.2 AA
Because everything else is unchanged, migration is exactly the gap between the two versions: verify the six new A/AA criteria and stop testing 4.1.1. A focused pass looks like this:
- Audit sticky UI against focus. Tab through every page template and confirm sticky headers, cookie banners, and chat launchers never fully cover the focused element (2.4.11).
- Inventory drag interactions. Sliders, sortable lists, file-drop zones, map panning — each needs a single-click alternative (2.5.7).
- Measure target sizes. Check icon buttons, pagination, and toolbars against the 24×24 CSS pixel minimum or its spacing exception (2.5.8). Fixing this once in your design system usually fixes it everywhere.
- Standardize help placement. If contact links, chat, or FAQs appear across pages, keep them in the same relative order (3.2.6).
- Remove redundant form entry. Auto-populate or offer to reuse anything the user already typed in the same process (3.3.7).
- Modernize login. Allow paste and password managers, or offer passkeys, magic links, or OAuth so authentication never depends solely on memory or transcription (3.3.8).
Teams already at 2.1 AA typically close this gap in days, not months. Work through the full list with our WCAG 2.2 checklist, or see exactly what AA requires end to end in our complete WCAG 2.2 AA requirements list.
Legal context: which version do laws actually require?
As of mid-2026, most binding standards still reference WCAG 2.1 AA, not 2.2:
- ADA Title II (U.S. state and local government): the DOJ's web accessibility rule requires WCAG 2.1 AA. See our analysis of the Title II compliance deadlines.
- European Accessibility Act / EN 301 549: the harmonized European standard references WCAG 2.1 AA for web content.
- Section 508 (U.S. federal): still references WCAG 2.0 AA.
- ADA Title III (U.S. private sector): no formal technical standard, but WCAG 2.1 AA is the de facto benchmark in settlements and demand letters — with 2.2 appearing more often. Our lawsuit tracker follows the trend.
None of this is a reason to stay on 2.1. Since WCAG 2.2 AA conformance satisfies every 2.1 AA reference above, building to 2.2 AA is the strictly safer choice: you meet today's legal standards and are already done when regulators update their citations.
Check your site against WCAG 2.2
Work through every criterion with the interactive checklist, or scan a URL to find machine-detectable failures first.
Frequently asked questions
What is the difference between WCAG 2.1 and WCAG 2.2?
WCAG 2.2 builds directly on WCAG 2.1. It adds nine new success criteria — two at Level A (3.2.6 Consistent Help, 3.3.7 Redundant Entry), four at Level AA (2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.3.8 Accessible Authentication (Minimum)), and three at Level AAA (2.4.12, 2.4.13, 3.3.9) — and removes one criterion, 4.1.1 Parsing, which had become obsolete. Everything else carries over unchanged: all remaining WCAG 2.1 success criteria appear verbatim in WCAG 2.2, bringing the total to 86 criteria.
When was WCAG 2.2 released?
WCAG 2.2 became an official W3C Recommendation on October 5, 2023, five years after WCAG 2.1 (June 2018) and fifteen years after WCAG 2.0 (December 2008). It is the current recommended version of the Web Content Accessibility Guidelines, and W3C encourages using it for new and updated conformance efforts.
If my site meets WCAG 2.2, does it also meet WCAG 2.1?
Effectively yes. WCAG 2.2 is backwards compatible: a page that conforms to WCAG 2.2 satisfies every WCAG 2.1 requirement except 4.1.1 Parsing, which was removed in 2.2. The W3C has since published guidance that 4.1.1 should be considered always satisfied for HTML content in WCAG 2.0 and 2.1 conformance claims, because modern browsers and assistive technologies fully handle parsing errors. So in practice, conforming to WCAG 2.2 AA also gives you WCAG 2.1 AA and WCAG 2.0 AA conformance.
Do laws require WCAG 2.2 yet?
Mostly not yet — most regulations still cite WCAG 2.1 AA. The U.S. DOJ's ADA Title II rule for state and local governments requires WCAG 2.1 AA, the European standard EN 301 549 (which underpins the European Accessibility Act) references WCAG 2.1 AA, and U.S. Section 508 still points to WCAG 2.0 AA. Because WCAG 2.2 is backwards compatible, targeting 2.2 AA satisfies all of these at once while future-proofing you as standards bodies update their references.
What happened to success criterion 4.1.1 Parsing?
It was removed in WCAG 2.2. When 4.1.1 was written in 2008, malformed HTML (unclosed tags, duplicate IDs, improper nesting) could crash or confuse assistive technologies that parsed markup directly. Modern browsers now repair markup errors consistently before assistive technologies ever see the content, so the criterion no longer improved accessibility on its own. Cases where markup errors cause real user harm — like duplicate IDs breaking a label association — are already covered by other criteria such as 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.
Should I target WCAG 2.1 AA or WCAG 2.2 AA?
Target WCAG 2.2 AA. It is the current W3C Recommendation, it automatically satisfies WCAG 2.1 AA (the version most laws reference), and the six new A/AA criteria are comparatively cheap to implement — mostly touching focus styling, target sizes, drag alternatives, form flows, and login. Auditing once against 2.2 AA costs little more than auditing against 2.1 AA and saves you a re-audit when regulators inevitably update their references.
How hard is it to migrate from WCAG 2.1 AA to WCAG 2.2 AA?
For most sites it is a small, well-scoped project. Only six new criteria apply at A/AA, and they cluster in a few places: check that sticky UI never fully covers focused elements (2.4.11), give every drag interaction a click alternative (2.5.7), make interactive targets at least 24 by 24 CSS pixels or spaced equivalently (2.5.8), keep help mechanisms in a consistent order (3.2.6), stop asking users to re-enter data within a process (3.3.7), and support password managers, paste, or passwordless login (3.3.8). Teams with a design system can often fix target size and focus styles globally in one pass.