WCAG 2.2: What Changed and What It Means

WCAG 2.2 became a W3C Recommendation on 5 October 2023. It adds nine success criteria to WCAG 2.1 and removes one, 4.1.1 Parsing. Six of the nine sit at Level A or AA, which is the level most teams, contracts and laws target, so those six are the practical scope of an upgrade. The other three are AAA.

The new criteria cluster in three places: keyboard focus, pointer input on small or draggable controls, and the cognitive load of forms and logins. Nothing about colour contrast changed. For the rest of the topic, see our accessibility hub.

The nine new success criteria at a glance

Criterion	Name	Level
2.4.11	Focus Not Obscured (Minimum)	AA
2.4.12	Focus Not Obscured (Enhanced)	AAA
2.4.13	Focus Appearance	AAA
2.5.7	Dragging Movements	AA
2.5.8	Target Size (Minimum)	AA
3.2.6	Consistent Help	A
3.3.7	Redundant Entry	A
3.3.8	Accessible Authentication (Minimum)	AA
3.3.9	Accessible Authentication (Enhanced)	AAA

Focus visibility: 2.4.11, 2.4.12 and 2.4.13

WCAG 2.1 already required a visible focus indicator (2.4.7). It didn't say anything about that indicator being covered up, and in practice it often is.

2.4.11 Focus Not Obscured (Minimum), AA. When a control receives keyboard focus, it can't be entirely hidden by content the site itself put on the page. Sticky headers, sticky footers, cookie banners and chat launchers cause most of these failures. A keyboard user tabs down a long page, focus moves to a link that has scrolled under a fixed header, and the indicator is technically present but invisible. Partial overlap passes at this level. Full overlap fails.

The fix is usually CSS rather than a redesign. scroll-padding-top set to the header's height keeps focused elements clear of it, and a cookie banner that doesn't sit over content (or that can be dismissed before anything else is reachable) removes the other common case.

2.4.12 Focus Not Obscured (Enhanced), AAA. The same rule, but no part of the focused control may be hidden.

2.4.13 Focus Appearance, AAA. This one defines what a sufficient indicator is. The focus indicator has to be at least as large as a 2 CSS pixel thick perimeter around the unfocused control, and it needs a contrast ratio of at least 3:1 between the focused and unfocused states. A 2px solid outline in a colour that contrasts with the surrounding background meets it in most layouts. Browser default rings often don't, depending on the background.

Pointer input: 2.5.7 and 2.5.8

2.5.7 Dragging Movements, AA. Anything that works by dragging needs a single-pointer alternative that doesn't involve dragging. Examples are sortable lists, kanban boards, range sliders, map panning and drag-to-upload zones. Dragging requires holding a press while moving precisely, which is hard or impossible with a tremor, a head pointer or some switch setups. The alternative can be as simple as up and down buttons on a sortable row, a "Move to…" menu on a card, or a click on the slider track that sets the value. Dragging is exempt only when it's essential to the function, as in a freehand drawing tool.

This criterion is separate from 2.5.1 Pointer Gestures, which covers multipoint and path-based gestures such as pinch or swipe. A drag is neither multipoint nor path-based, because only the start and end points matter, so 2.5.1 never covered it.

2.5.8 Target Size (Minimum), AA. Pointer targets need to be at least 24 by 24 CSS pixels. A smaller target still passes if it has enough space around it: draw a 24px circle centred on each undersized target, and if no circle overlaps another target or another circle, the spacing exception applies. Links inside a sentence are exempt, as are targets whose size is set by the browser and targets where a specific small size is essential. A target also passes if an equivalent control elsewhere on the page meets the size.

The older 2.5.5 Target Size criterion, at 44 by 44 pixels, still exists at AAA and is now titled Target Size (Enhanced). The 24px minimum is the one that counts for AA. In audits it mostly catches icon rows: pagination numbers, close buttons on tags and chips, table row actions and social icons packed together in a footer.

Help, forms and sign-in: 3.2.6, 3.3.7, 3.3.8 and 3.3.9

3.2.6 Consistent Help, A. If a site offers help on several pages, such as a phone number, a contact form, a chat widget or a link to an FAQ, it has to appear in the same relative order on each of those pages. It doesn't require offering help at all. A support link that sits in the header on one template and at the bottom of the page on another fails it.

3.3.7 Redundant Entry, A. Information a user has already entered in the same process must be filled in automatically or offered for selection, not asked for again. A checkout that collects a shipping address and then asks for the billing address from scratch fails it. A "Same as shipping address" checkbox fixes that. Re-entry is allowed when it's essential, such as confirming a new password, when it's needed for security, or when the earlier information is no longer valid.

3.3.8 Accessible Authentication (Minimum), AA. A login step can't depend on a cognitive function test, meaning remembering a password, transcribing a code or solving a puzzle, unless the user has another way through. That alternative can be a different sign-in method, or support for a mechanism that does the work for them. The biggest practical consequence is that password fields must allow paste and autofill, so password managers work. A one-time code field that blocks paste, or that splits the code across six inputs that break paste, is the other frequent failure. At AA, CAPTCHAs that ask the user to recognise objects, and challenges based on content the user supplied themselves, are still allowed.

3.3.9 Accessible Authentication (Enhanced), AAA. The same rule without those two exceptions, so image-recognition CAPTCHAs fail too.

Offering a passkey, a magic link sent by email or a "Sign in with…" provider as an alternative satisfies 3.3.8, because none of them asks the user to recall or transcribe anything. A paste-blocked password field that is the only way in still fails.

4.1.1 Parsing was removed

WCAG 2.2 drops 4.1.1 Parsing, which required well-formed markup: complete start and end tags, no duplicate IDs, correctly nested elements. The HTML specification now defines exactly how browsers recover from markup errors, and assistive technology reads the browser's accessibility tree rather than parsing the source itself, so the problems it guarded against mostly surface under other criteria instead. A duplicate ID that breaks an aria-labelledby reference, for example, still fails 1.3.1 or 4.1.2 through the broken name, which is the part that actually affects users. Our guide to ARIA labels covers how those references resolve.

The W3C also published an erratum saying 4.1.1 should be treated as always satisfied for content using HTML or XML under WCAG 2.0 and 2.1. Where a law incorporates the older text directly, check how the regulator treats that erratum before dropping parsing from a compliance report.

What didn't change: contrast

Contrast requirements in WCAG 2.2 are the same as in 2.1:

• 1.4.3 Contrast (Minimum), AA: 4.5:1 for normal text, 3:1 for large text (at least 18pt, or 14pt bold).
• 1.4.6 Contrast (Enhanced), AAA: 7:1 for normal text, 4.5:1 for large text.
• 1.4.11 Non-text Contrast, AA: 3:1 for the visual boundaries and states of controls, such as input borders, checkbox outlines and toggle states, and for the parts of graphics needed to understand them.

The new focus criterion connects to these. 2.4.13's 3:1 comparison between focused and unfocused states uses the same ratio as 1.4.11, so a focus ring can be checked with the same tool. Our free contrast checker gives the ratio for any two colours and shows which WCAG 2.2 thresholds the pair passes.

Which laws reference WCAG 2.2

Most legislation still points at WCAG 2.1 AA, and a few older rules point at 2.0.

• European Accessibility Act. Its requirements have applied to covered products and services since 28 June 2025. Its harmonised standard, EN 301 549, currently references WCAG 2.1 AA for web content.
• Section 508 (US federal). The 2017 refresh incorporates WCAG 2.0 AA.
• ADA Title II (US state and local government). The Department of Justice's 2024 rule adopts WCAG 2.1 AA.

WCAG 2.2 is backwards compatible: a page that conforms to 2.2 also conforms to 2.1 and 2.0. Building to WCAG 2.2 AA therefore covers the web-content portion of all three. EN 301 549 and Section 508 also have requirements outside WCAG, for non-web software, documents and support services, which 2.2 doesn't address.

Moving a WCAG 2.1 audit to WCAG 2.2

For a product that already passes 2.1 AA, the upgrade is six new checks and one deletion:

1. Remove 4.1.1 Parsing from the checklist and from any open issue list. Re-file genuine duplicate-ID problems under 1.3.1 or 4.1.2 if they break a name or relationship.
2. Tab through every template with the sticky header, footer, cookie banner and chat widget all present. Note any focused element that ends up completely hidden (2.4.11).
3. List every drag interaction and confirm each has a click or tap alternative (2.5.7).
4. Measure icon buttons, chips, pagination and table actions. Anything under 24px needs either more size or more spacing (2.5.8).
5. Compare where help and contact links appear across templates (3.2.6).
6. Walk each multi-step form and flag any field that asks for something the user has already given (3.3.7).
7. Try pasting into every password and one-time code field, and check that password managers can fill them (3.3.8).

Most of these are fast to test. Fixes for 2.5.7 take longer: someone has to design the alternative control. The accessibility heuristics guide covers what a checklist like this misses.

FAQ

What is WCAG 2.2? WCAG 2.2 is the current version of the W3C's Web Content Accessibility Guidelines, published as a Recommendation in October 2023. It keeps every WCAG 2.1 criterion except 4.1.1 Parsing and adds nine new ones.

What is the difference between WCAG 2.1 and WCAG 2.2? WCAG 2.2 adds nine success criteria covering focus visibility, dragging, target size, consistent help, redundant entry and accessible authentication, and removes 4.1.1 Parsing. Six of the new criteria are at Level A or AA.

How many new success criteria are in WCAG 2.2? Nine: two at Level A (3.2.6, 3.3.7), four at AA (2.4.11, 2.5.7, 2.5.8, 3.3.8) and three at AAA (2.4.12, 2.4.13, 3.3.9).

Did WCAG 2.2 change the contrast ratio requirements? No. Normal text still needs 4.5:1 at AA and large text 3:1. Non-text contrast under 1.4.11 is still 3:1.

What is the minimum target size in WCAG 2.2? 24 by 24 CSS pixels at Level AA under 2.5.8, with an exception for smaller targets that have enough spacing around them. The 44 by 44 pixel size is the AAA criterion, 2.5.5.

Is WCAG 2.2 legally required? Most laws currently reference WCAG 2.1 AA (the European Accessibility Act via EN 301 549, and the US ADA Title II rule) or 2.0 AA (Section 508). Conforming to WCAG 2.2 AA also meets the WCAG portion of those, because 2.2 is backwards compatible. Some of those laws have additional requirements beyond web content.

Is WCAG 3.0 replacing WCAG 2.2? Not soon. WCAG 3.0 is still a working draft with a different structure and scoring model. WCAG 2.2 is the version to build and audit against now.

Source: W3C — What's New in WCAG 2.2.