WCAG 2.2: The Nine New Success Criteria That Matter Most

WCAG 2.2 became a W3C Recommendation in October 2023, building on 2.1 with nine additional success criteria. Crucially, 2.2 is backward compatible: meeting 2.2 means you also meet 2.1 and 2.0. If you are working toward a Title II or procurement target framed around 2.1 AA, moving to 2.2 is the safer bet - it future-proofs your work.

Here is what the new criteria are actually trying to protect, in plain terms.

Focus and interaction

Focus Not Obscured (2.4.11, AA) requires that when an element receives keyboard focus, it is not completely hidden by other content - a sticky header or a cookie banner, for example. Keyboard users need to see where they are.

Focus Appearance (2.4.13, AAA) goes further, defining how visible a focus indicator must be in terms of size and contrast.

Dragging Movements (2.5.7, AA) says any action that relies on dragging must offer a single-pointer alternative that does not require dragging. Think reordering a list or a slider - there should be buttons or taps that achieve the same thing.

Target Size (Minimum) (2.5.8, AA) sets a minimum interactive target of 24 by 24 CSS pixels (with sensible exceptions for inline links and spacing). This is a direct response to tiny, hard-to-tap controls on mobile.

Reducing cognitive load

Consistent Help (3.2.6, A) asks that help mechanisms - a contact link, a chat widget, a phone number - appear in the same relative order across pages, so people do not have to relearn where to find support.

Redundant Entry (3.3.7, A) says you should not force users to re-enter information they have already provided in the same process, unless it is essential. Auto-populate or let them select previously entered data.

Accessible Authentication (Minimum) (3.3.8, AA) is one of the most consequential. It prohibits cognitive function tests - like remembering a password or solving a puzzle - as the only way to log in, unless an alternative exists. Allowing password managers to paste credentials satisfies it. Many login flows quietly fail this today.

Accessible Authentication (Enhanced) (3.3.9, AAA) removes the object-recognition and personal-content exceptions allowed at AA.

What got removed

One criterion from earlier versions, 4.1.1 Parsing, was deprecated in 2.2. Modern browsers handle the underlying parsing issues, so it no longer maps to real user harm. If your old reports still flag it, they are out of date.

How to test for the new criteria

Some of these are straightforwardly automatable. Target size, for instance, can be measured programmatically. Others - consistent help, redundant entry, accessible authentication - require an understanding of flow and context that pure automation cannot fully judge. The honest answer is that good accessibility programs combine automated scanning for the criteria machines test well with human review for the criteria that need judgment.

GuardGrid runs the full WCAG 2.2 automated rule set on every page and flags the criteria that warrant manual confirmation, so your team spends its limited review time where it actually counts - not re-checking things a scanner already proved.