WCAG 2.2 vs 2.1: what changed, and why AA is still the target

WCAG 2.2 vs 2.1: what changed, and why AA is still the target
If you have read that you need to meet "WCAG 2.1 AA" in one place and "WCAG 2.2 AA" in another, you are not missing something - the laws and the standard are simply on slightly different clocks. Here is what actually changed between the two versions, what the new criteria ask for, and why targeting 2.2 is the right call regardless of which version your particular law names.
The short version
The Web Content Accessibility Guidelines (WCAG) are published by the W3C. WCAG 2.1 arrived in June 2018; WCAG 2.2 became the recommended version in October 2023. WCAG 2.2 is backwards-compatible: it keeps everything in 2.1 and adds new criteria on top. So if you meet WCAG 2.2 at a given level, you also meet 2.1 at that level. That single fact resolves most of the confusion.
What changed in the counts
WCAG has three conformance levels - A, AA and AAA - and AA is the level the law expects almost everywhere. Counting cumulatively through AA:
- WCAG 2.1 AA = 50 success criteria.
- WCAG 2.2 AA = 55 success criteria.
WCAG 2.2 added nine new criteria across all levels and removed one old one (4.1.1 Parsing, which modern browsers made obsolete), for a net increase of five at each level. It is worth being precise here: 2.2 did not add "nine more at AA" - the net change at AA is +5.
The four new Level AA criteria, in plain English
These are the additions most teams need to act on:
- 2.4.11 Focus Not Obscured (Minimum). When you tab to an element, it must not be completely hidden behind a sticky header, footer or cookie banner. If the user can't see what has focus, they can't use it.
- 2.5.7 Dragging Movements. Any action that relies on dragging - reordering a list, a slider, a map - must also have a simple single-tap or click alternative, for people who can't drag accurately.
- 2.5.8 Target Size (Minimum). Clickable and tappable targets must be at least 24 by 24 CSS pixels, or have enough spacing around them. Tiny, crowded buttons fail this.
- 3.3.8 Accessible Authentication (Minimum). Logging in must not depend on a cognitive test like solving a puzzle, remembering a password from memory, or transcribing a code, unless an easier alternative exists. Let people paste, and support password managers.
(There are also Level A additions - Consistent Help and Redundant Entry - and Level AAA criteria such as Focus Appearance. A common mix-up: Focus Appearance is AAA, not AA.)
Which version does the law name?
This is where the two clocks show. Most current laws still point at WCAG 2.1 AA, because they were written before 2.2 was finalised:
- The EU's harmonised standard EN 301 549, used by the European Accessibility Act, currently incorporates WCAG 2.1 AA.
- The US DOJ's ADA Title II rule for state and local government adopts WCAG 2.1 AA.
- Section 508 references the older WCAG 2.0 AA.
But because 2.2 is backwards-compatible, meeting WCAG 2.2 AA satisfies all of those at once. Standards bodies are expected to move to 2.2 over time, so building to 2.2 now is simply future-proofing - you won't have to revisit the same pages when the references update.
What to do
- Target WCAG 2.2 AA. It covers 2.1 AA and 2.0 AA, so you only have to track one standard.
- Start with the five additions. Focus visibility, drag alternatives, target sizes, accessible login and the two Level A additions are the deltas a 2.1-compliant site most often misses.
- Work from the full list. Our free WCAG 2.2 AA checklist lays out all 55 Level A and AA criteria in plain English, with how to test each one.
For the full explainer on WCAG, levels and the POUR principles, see our WCAG guide. This is guidance, not legal advice - confirm specifics with the official W3C text or a qualified adviser.
Related reading

Your Design System Is Your Accessibility Infrastructure: An Operating Model for 2026
95.9% of the web still fails WCAG. The bottleneck isn't detection - it's organisational capacity to act. A design system is the only place where one accessibility decision propagates everywhere.

Cookie Banner Accessibility: Why Your Vendor's Conformance Claim Doesn't Protect You
Your site may pass an audit and still block every keyboard user at the front door. The consent banner, chat widget, and payment iframe are someone else's code - but your legal liability.

Transport Accessibility Under the EAA: A Journey-Stage Compliance Guide for Operators and Travel-Tech Vendors
A practitioner's guide to EAA transport accessibility: what's in scope by mode and journey stage, the WCAG 2.2 failure modes that block passengers, and a prioritised remediation order for operators and travel-tech vendors.