WCAG 2.2 for product teams: what changed from 2.1, and how to design for it
Gideon Awolesi ·
WCAG 2.2 was published by the W3C on 5 October 2023. It keeps almost everything from WCAG 2.1, adds nine new success criteria, and removes one. Six of the new criteria are at level A or AA, so they're part of the target if you're building to WCAG 2.2 AA. And since EN 301 549 V4.1.1 adopted WCAG 2.2 in September 2026, that's the version to build to if you sell into the EU. This guide goes through what changed, in the terms your designers and developers use.
01What changed between 2.1 and 2.2
| Criterion | Level | What it asks for |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | A focused element isn't completely hidden by content you added, like a sticky header or a cookie banner |
| 2.4.12 Focus Not Obscured (Enhanced) | AAA | No part of the focused element is hidden |
| 2.4.13 Focus Appearance | AAA | The focus indicator is large enough and has enough contrast |
| 2.5.7 Dragging Movements | AA | Anything you can do by dragging, you can also do with a single pointer, like a tap or a click |
| 2.5.8 Target Size (Minimum) | AA | Targets are at least 24 by 24 CSS pixels, or have enough space around them |
| 3.2.6 Consistent Help | A | Help, like a contact link or a chat, appears in the same place on every page |
| 3.3.7 Redundant Entry | A | People don't have to type the same information twice in one process |
| 3.3.8 Accessible Authentication (Minimum) | AA | Logging in doesn't depend on a cognitive function test, like remembering a password or solving a puzzle, unless there's a way around it |
| 3.3.9 Accessible Authentication (Enhanced) | AAA | The same, without the exceptions for object recognition and personal content |
WCAG 2.2 also removed 4.1.1 Parsing, because browsers and assistive technology now handle the problems it was written for. So a page that meets 2.2 doesn't automatically meet everything in 2.1, but in practice that one criterion is the only difference.
02Focus that people can actually see
Right now, a lot of products have a sticky header, a cookie banner, or a chat widget that covers the bottom of the screen. When a keyboard user tabs down the page, the focused link can end up hidden behind one of them, and they lose track of where they are. 2.4.11 asks that the focused element is never completely hidden.
In practice, that means adding scroll padding equal to the height of your sticky header, and checking that banners and chat widgets don't sit on top of the content people are tabbing through.
03Targets you can tap
2.5.8 sets a minimum target size of 24 by 24 CSS pixels. A smaller target can still pass if there's enough space around it, so that a 24 pixel circle centred on it doesn't overlap another target. Icon buttons in table rows, close buttons on modals, and links packed into a footer are where this usually fails.
2.5.7 asks for a single-pointer alternative to every drag. If people can reorder a list by dragging, give them move up and move down buttons too. If they can drag a slider, let them tap a position on the track or type a value.
04Forms that don't ask twice
3.3.7 means that if someone has already entered their address in one step, the next step either fills it in for them or lets them pick it, like a "same as billing address" checkbox. Asking again is allowed only when it's essential, for security, or when the earlier information is no longer valid.
3.2.6 asks that help appears in the same relative order across pages. If your contact link is in the footer on one page and in the header on another, people who rely on finding it in a predictable place will struggle.
05Log-in without a memory test
3.3.8 is the one product teams ask about most. It doesn't ban passwords. It asks that people aren't forced to remember or transcribe something to log in, unless they get help doing it. Letting password managers fill in the field, and letting people paste into it, is usually enough. So is a magic link, a passkey, or logging in with another account.
Where it fails is when you block paste on the password field, ask people to retype a code from one device into another with no copy option, or use a puzzle CAPTCHA with no alternative.
06Which version to build to
Build to WCAG 2.2 AA. It's the version EN 301 549 V4.1.1 points to, and it's the benchmark for the European Accessibility Act once V4.1.1 is cited in the Official Journal. If your product already meets 2.1 AA, the gap is the six new A and AA criteria above, and you can usually close it in a few sprints.
Our Accessibility Audit tests up to five key journeys by hand against WCAG 2.2 AA in two weeks, from €2,500.