WCAG 2.2: The 9 New Success Criteria — and Whether You Need to Target Them Yet

WCAG 2.2 has been the official version of the Web Content Accessibility Guidelines since 5 October 2023, when the W3C published it as a Recommendation — the final, stable form of a web standard (W3C). It is not a rewrite. It keeps every criterion from 2.0 and 2.1 intact, removes one outdated rule, and adds nine new success criteria — most of them aimed squarely at people with low vision, motor impairments, and cognitive disabilities.

If you have spent any time on WCAG 2.1 AA, the good news is that the jump to 2.2 is small. Here is what each of the nine additions actually asks of your site, in plain terms, and then an honest answer to the question every business owner has: do I need to target 2.2 or is 2.1 still fine?

The nine new success criteria, in plain language

WCAG 2.2 groups its additions into three areas — keyboard focus, pointer/touch interaction, and forms/login. Here is the full list, with the official numbers, names, and levels straight from the W3C standard.

Focus you can actually see

• 2.4.11 Focus Not Obscured (Minimum) — AA. When an element receives keyboard focus, it must not be entirely hidden behind something the author added, like a sticky header or a cookie banner. Tab through your site; if the focused item disappears under a fixed bar, you fail.
• 2.4.12 Focus Not Obscured (Enhanced) — AAA. The stricter version: no part of the focused element may be obscured.
• 2.4.13 Focus Appearance — AAA. The focus indicator itself must be substantial — at least the area of a 2px-thick outline around the component — and change by a contrast ratio of at least 3:1 between its focused and unfocused states (W3C Understanding). This is the AAA companion to the AA-level 2.4.7 Focus Visible you already know.

Pointer and touch that forgives

• 2.5.7 Dragging Movements — AA. Anything you can do by dragging — a slider, a “drag to reorder” list, a map — must also work with a single tap or click. People with tremors or who use a head pointer often cannot drag accurately.
• 2.5.8 Target Size (Minimum) — AA. Clickable targets should be at least 24 by 24 CSS pixels, or have enough spacing that a 24px circle centered on each one doesn’t overlap its neighbors (W3C Understanding). There are sensible exceptions: inline links inside a sentence, elements the browser controls (like default scrollbars), and cases where the exact size is essential, such as map pins.

Forms and login that respect memory

• 3.2.6 Consistent Help — A. If you offer a help mechanism — contact link, chat, phone number — put it in the same place on every page that has it. Predictability matters for people with cognitive disabilities.
• 3.3.7 Redundant Entry — A. Don’t ask for the same information twice in one process. If a user typed their address at step one, don’t make them retype it at step four — auto-populate it or let them pick it.
• 3.3.8 Accessible Authentication (Minimum) — AA. A login step can’t require a “cognitive function test” — remembering, transcribing, or solving a puzzle — unless there’s an alternative. In practice, this means you must let browsers and password managers fill the fields and must not block paste into login boxes (W3C Understanding). The notorious “type the characters you see” CAPTCHA is the classic failure here.
• 3.3.9 Accessible Authentication (Enhanced) — AAA. Removes the object-recognition and personal-content exceptions allowed at AA — the strictest login bar.

WCAG 2.2 also removed 4.1.1 Parsing, which is now marked obsolete (W3C). Modern browsers handle malformed markup gracefully, so the rule had stopped being useful — one of the rare cases where a standard gets easier. If you want the full picture of how criteria are organized, our WCAG success criteria index and conformance levels guide break it all down.

2.1 AA or 2.2 AA — which should you target?

Here is the honest version. No U.S. law currently names WCAG 2.2 by version. The Department of Justice’s 2024 Title II rule for state and local governments points specifically at WCAG 2.1 Level AA, with compliance phased in by population — large entities by April 26, 2027 and smaller ones by April 26, 2028 under the 2026 interim final rule extension (ADA.gov). Private-business ADA Title III cases are typically argued against WCAG 2.1 AA as well, because that’s the standard courts and plaintiffs have settled on. This is general information and not legal advice — talk to a qualified accessibility attorney about your specific exposure.

So does 2.1 get you off the hook? Practically, no — and here’s the key fact: WCAG 2.2 is backward compatible. Because it keeps every 2.1 criterion and only adds to them, a site that meets 2.2 AA automatically meets 2.1 AA (W3C). The reverse isn’t true. Targeting 2.2 is a strict superset — you lose nothing and you future-proof.

That future is already arriving abroad: the next version of the EU’s EN 301 549 standard, which underpins the European Accessibility Act, adopts WCAG 2.2 AA. Regulators tend to follow the latest stable W3C Recommendation eventually, so building to 2.2 now means you won’t be re-auditing when the reference updates.

Our recommendation for most small businesses: treat WCAG 2.2 Level AA as the target, WCAG 2.1 AA as the legal floor. The six new A/AA criteria are not exotic — they’re better tap targets, a focus ring you can see, and not torturing people at the login screen. You were going to want those anyway.

How this plays out in a real remediation

The six A/AA additions tend to surface in predictable places. Sticky headers swallow keyboard focus (2.4.11). Icon-only buttons and tightly packed footer links fall under 24px (2.5.8). Multi-step checkouts re-ask for data (3.3.7). And login forms that block paste quietly fail accessible authentication (3.3.8). None of these are fixed by an overlay widget — they’re structural issues in the HTML, CSS, and flow logic that need real manual remediation.

That’s the whole reason Curbcut works by hand rather than bolting on a script. A focus indicator, a tap-target size, a paste-friendly password field — these live in your actual code, and that’s the only place a real fix can go.

Want to know which of the nine you already pass and which you don’t? Start with a free accessibility scan, or get a human to look with a full accessibility audit.