What Changed in WCAG 2.2

Most of the guidance on this site was written against WCAG 2.1. In October 2023 the W3C published WCAG 2.2, and it is now the version most regulations point at. If you already meet 2.1 at level AA, the gap is small but specific.

What actually changed

WCAG 2.2 adds nine success criteria and removes one, bringing the total to 86. It is fully backwards compatible: if you conform to 2.2, you also conform to 2.1 and 2.0.

The removed criterion is 4.1.1 Parsing. It used to require valid, non-duplicated markup on the grounds that assistive technology parsed HTML directly. Assistive technology no longer does that, so the criterion had stopped doing useful work. Genuine markup problems that used to fail 4.1.1 now fail something else instead — usually 1.3.1 Info and Relationships or 4.1.2 Name, Role, Value.

That is worth saying clearly, because "we removed a criterion" is easy to misread as "markup validity stopped mattering". It did not. The failure just has a more accurate name now.

The two that catch most sites

Six of the nine new criteria are at level A or AA, which is the level most laws and contracts reference. Two of those are the ones I would check first.

2.4.11 Focus Not Obscured (Minimum) — AA

When something receives keyboard focus, it must not be entirely hidden behind other content.

The usual culprit is a sticky header. Tab down a long page and, at some point, the focused element scrolls up underneath the fixed bar. The element still has focus, the browser has scrolled to it, and a sighted keyboard user cannot see where they are.

Cookie banners and non-modal dialogues do the same thing.

This one is easy to test and easy to miss, because it only shows up when you actually tab through a scrolled page rather than checking the top of it.

2.5.8 Target Size (Minimum) — AA

Interactive targets need to be at least 24 by 24 CSS pixels, with exceptions — including where the target is inline in a sentence, or where spacing around a smaller target keeps it clear of its neighbours.

The exceptions matter, so read the criterion rather than applying 24 pixels universally. Icon-only buttons packed tightly together are the common failure.

The rest of the nine

2.4.12 Focus Not Obscured (Enhanced), AAA — the same idea as 2.4.11 but requiring the focused component to be entirely visible rather than merely partly.

2.4.13 Focus Appearance, AAA — minimum size and contrast for the focus indicator itself. Even at AAA this is worth reading, because a faint one-pixel outline is a real barrier and is very common.

2.5.7 Dragging Movements, AA — anything you can do by dragging must also be achievable without dragging. Reorderable lists and sliders are the usual cases.

3.2.6 Consistent Help, A — if a help mechanism appears on multiple pages, it appears in the same relative place each time.

3.3.7 Redundant Entry, A — do not make someone type the same information twice in one process, unless there is a good reason such as confirming a password.

3.3.8 Accessible Authentication (Minimum), AA — do not require a cognitive function test to log in, unless an alternative exists. In practice this means allowing paste into password fields, supporting password managers, and not requiring someone to transcribe a code by hand with no alternative.

3.3.9 Accessible Authentication (Enhanced), AAA — the same without the object-recognition exception.

How big is the gap

If you already meet 2.1 AA properly, the work is usually:

• checking focus visibility against sticky and fixed elements, on real pages, by tabbing through them
• measuring your smallest interactive targets
• providing non-drag alternatives where you have drag interactions
• checking that nothing in your login flow blocks a password manager

Most of the new criteria cannot be checked by an automated tool. Whether help is in a consistent place, or whether a drag alternative is genuinely equivalent, is a judgement. That makes the manual pass more important under 2.2 than it was before, which is worth knowing before you assume a clean automated scan means anything has changed.

Which version should you target

WCAG 2.2 is the current W3C Recommendation and is backwards compatible, so targeting 2.2 AA satisfies anything that points at 2.1 or 2.0.

Regulations vary in which version they name, and some still reference 2.1. Aiming at 2.2 is the simpler position: you cannot be caught out by a rule that names an older version, and you are ready for one that names the newer.

[Suzanne: if you have a specific example from client work where the sticky-header focus problem showed up, it would land better than my generic description. I have deliberately not invented one.]