WCAG 2.1 vs 2.2 — What Changed?
TL;DR
WCAG 2.2 was published in October 2023 and adds 9 new success criteria to WCAG 2.1. The biggest changes improve mobile usability (minimum target sizes, dragging alternatives), authentication accessibility (no cognitive function tests for login), and help consistency. One WCAG 2.1 criterion (4.1.1 Parsing) was removed. If you are already meeting WCAG 2.1 AA, the gap to 2.2 AA is manageable — 6 new criteria at Levels A and AA.
If you have been targeting WCAG 2.1 for your website's accessibility compliance, you might be wondering what WCAG 2.2 changes and whether you need to update. The short answer: yes, you should. WCAG 2.2 is now the current standard, and regulations are beginning to reference it. Here is exactly what changed.
Quick History
The Web Content Accessibility Guidelines have evolved in stages:
- WCAG 2.0 (December 2008) — The foundational standard. 61 success criteria.
- WCAG 2.1 (June 2018) — Added 17 new criteria addressing mobile, low vision, and cognitive needs. 78 success criteria total.
- WCAG 2.2 (October 2023) — Added 9 new criteria, removed 1. 86 success criteria total.
Each version is backwards-compatible: a site conforming to WCAG 2.2 also conforms to 2.1 and 2.0. The criteria numbers are additive — nothing was renumbered.
What Was Added in WCAG 2.2
WCAG 2.2 introduces 9 new success criteria. Here is every one, with what it actually requires and why it matters.
Level A (Minimum)
3.2.6 Consistent Help (Level A)
What it requires: If your website provides help mechanisms (contact information, chat, FAQ links), they must appear in the same relative position on every page.
Why it matters: People with cognitive disabilities need predictable interfaces. If your phone number is in the header on one page and the footer on another, that inconsistency creates a barrier.
What to do: Ensure your contact details, live chat widget, and help links are in the same location across all pages. Most sites already do this via shared headers/footers, so this is typically a pass.
3.3.7 Redundant Entry (Level A)
What it requires: If a user has already entered information in a multi-step process, the site must either auto-populate that information or allow the user to select it — not force them to re-enter it.
Why it matters: Re-entering data is a significant barrier for people with motor or cognitive impairments. It increases error rates and abandonment.
What to do: In multi-step forms, pre-fill fields with previously entered data. Offer "same as billing address" checkboxes. Never ask for the same information twice without offering auto-fill.
Level AA (Standard Target)
2.4.11 Focus Not Obscured (Minimum) (Level AA)
What it requires: When an element receives keyboard focus, it must not be entirely hidden behind other content (sticky headers, modals, cookie banners).
Why it matters: Keyboard users need to see where focus is. If a sticky navigation bar covers the focused element, the user is navigating blind.
What to do: Test keyboard navigation with sticky headers and banners present. Ensure focused elements scroll into visible viewport area. Add scroll-padding-top to account for fixed headers.
2.4.12 Focus Not Obscured (Enhanced) (Level AAA)
What it requires: The focused element must be fully visible — not just partially visible.
Difference from 2.4.11: The Level AA version (2.4.11) only requires the element to not be entirely hidden. This AAA version requires it to be fully visible.
2.5.7 Dragging Movements (Level AA)
What it requires: Any functionality that uses dragging (drag-and-drop, sliders, map panning) must also be operable with a single pointer without dragging.
Why it matters: People with motor impairments often cannot perform drag gestures. Someone using a head pointer, eye tracker, or who has tremors needs an alternative.
What to do: Provide click/tap alternatives for all drag interactions. Sortable lists should have up/down buttons. Sliders should accept click-to-set or keyboard input. Maps should have zoom buttons, not just pinch-to-zoom.
2.5.8 Target Size (Minimum) (Level AA)
What it requires: Interactive targets (buttons, links, form controls) must be at least 24×24 CSS pixels, or have sufficient spacing from adjacent targets.
Why it matters: Small touch targets are difficult for people with motor impairments, older users, and anyone using a mobile device in less-than-ideal conditions.
WCAG 2.1 had 2.5.5 (Level AAA): That required 44×44px but was only Level AAA. WCAG 2.2 introduces a more pragmatic 24×24px minimum at Level AA, making it a practical requirement rather than an aspirational one.
What to do: Audit all interactive elements. Ensure buttons, links, and form controls meet the 24px minimum or have adequate spacing. Common failures: inline text links in paragraphs, small icon buttons, closely-spaced pagination links.
3.3.8 Accessible Authentication (Minimum) (Level AA)
What it requires: Login processes must not require cognitive function tests (memorising a password, solving a puzzle, recognising objects) unless an alternative is available. Password managers and browser autofill must be allowed to work.
Why it matters: CAPTCHAs that require identifying traffic lights, and login flows that block password managers, create barriers for people with cognitive disabilities, learning difficulties, and memory impairments.
What to do: Ensure login forms allow paste and autofill (do not use autocomplete="off" on password fields). If you use CAPTCHA, provide an alternative like email verification. If you use "pick the images containing boats" challenges, provide an audio or logic-based alternative.
Level AAA (Enhanced)
2.4.13 Focus Appearance (Level AAA)
What it requires: Focus indicators must meet specific size and contrast requirements — a minimum area of the focus indicator must have at least 3:1 contrast against the unfocused state.
What to do: Use visible, high-contrast focus outlines. The default browser outline usually works. If you customise focus styles, ensure they meet the contrast and size requirements.
3.3.9 Accessible Authentication (Enhanced) (Level AAA)
What it requires: Same as 3.3.8, but also prohibits object recognition tests (even with alternatives) and image-based CAPTCHAs entirely.
What to do: Use non-visual authentication methods: email magic links, SMS codes, biometrics, or simply allowing password managers to work.
What Was Removed
4.1.1 Parsing (Level A) — REMOVED
What it was: Required that HTML could be parsed without errors — no duplicate IDs, properly nested elements, unique attributes.
Why it was removed: Modern browsers and assistive technologies are far more resilient to HTML errors than they were in 2008. The criterion was obsolete — the parsing problems it addressed are handled automatically by browser error recovery.
Impact: If your WCAG 2.1 compliance reports included 4.1.1 Parsing failures, those are no longer violations under 2.2. However, clean HTML is still good practice.
Side-by-Side Comparison
| Aspect | WCAG 2.1 (June 2018) | WCAG 2.2 (October 2023) |
|---|---|---|
| Total criteria | 78 | 86 (+9, −1) |
| Level A criteria | 30 | 31 (+2, −1) |
| Level AA criteria | 20 | 24 (+4) |
| Level AAA criteria | 28 | 31 (+3) |
| Target size | 44px (AAA only) | 24px minimum at AA |
| Authentication | Not addressed | Cognitive tests restricted |
| Drag interactions | Not addressed | Must have single-pointer alternative |
| Focus visibility | Basic requirement (2.4.7 AA) | Not obscured (2.4.11 AA) + appearance (2.4.13 AAA) |
| Help consistency | Not addressed | Must be in consistent location (A) |
| Parsing (4.1.1) | Required (Level A) | Removed (obsolete) |
What This Means for Your Website
If you are already at WCAG 2.1 AA
The gap to WCAG 2.2 AA is 4 new criteria at Level AA plus 2 at Level A. In practice, the most likely failures are:
- Target size (2.5.8) — Check that all clickable elements are at least 24px or have adequate spacing. Inline text links in dense paragraphs are the common failure.
- Focus not obscured (2.4.11) — Test keyboard navigation with any sticky headers or cookie banners active.
- Dragging movements (2.5.7) — If you have drag-and-drop, sliders, or interactive maps, ensure single-pointer alternatives exist.
- Accessible authentication (3.3.8) — Ensure login forms allow password manager autofill and do not require CAPTCHA as the only option.
If you are starting from scratch
Target WCAG 2.2 directly. There is no reason to aim for 2.1 when 2.2 is the current standard. All testing tools (including axe-core, which PEER uses) now test against 2.2 criteria.
Which version does the law require?
The UK public sector regulations reference WCAG 2.1 AA. The European Accessibility Act references WCAG 2.1 AA. However, both the W3C and accessibility professionals recommend targeting 2.2 as the current best practice. When regulations catch up (they always do), you will already be compliant.
How PEER Tests Against WCAG 2.2
The PEER framework tests against 87 WCAG 2.2 rules using axe-core 4.11, plus custom detection rules for issues that standard tools miss (visual stress from saturated colours, inconsistent alt text on repeated images, duplicate carousel content, decorative punctuation). The audit checks every page on both desktop and mobile, producing cross-page violation counts with full evidence: element selectors, HTML snippets, page URLs, and device.
If you want to know where your website stands against WCAG 2.2, request a PEER audit. You will get a clear breakdown of Level A, AA, and AAA compliance with prioritised remediation guidance.
Ready to reduce your digital waste?
Book a free consultation to discuss how OYNK can help your organisation achieve its sustainability goals.
Book a Consultation