WCAG 2.2: What Changed from 2.1, and Whether You Need to Meet It

WCAG 2.2 became a W3C Recommendation in October 2023. It adds nine success criteria and removes one, and it is backwards compatible: if you meet 2.2 at a given level, you meet 2.1 at that level.

That creates a question worth answering deliberately rather than by default. Most regulation currently cites WCAG 2.1 Level AA — including the DOJ’s ADA Title II rulemaking, and Section 508, which still references 2.0 AA. So do you build to a standard your regulator has not adopted?

What was added

Six of the nine new criteria land at Level A or AA — the levels that get enforced.

Level AA

2.4.11 Focus Not Obscured (Minimum) — When an element receives keyboard focus, it must not be entirely hidden behind other content. The classic failure is a sticky header or cookie banner that covers the focused element, so a keyboard user is typing somewhere they cannot see.

2.5.7 Dragging Movements — Anything achievable by dragging must also be achievable with a single pointer action without dragging. Drag-to-reorder lists, drag-and-drop uploads, and slider controls need a click-based alternative. This matters for people with tremors or limited fine motor control.

2.5.8 Target Size (Minimum) — Interactive targets must be at least 24 by 24 CSS pixels, with exceptions for inline links and spacing. This is aimed squarely at cramped mobile UIs and tightly packed icon rows.

3.3.8 Accessible Authentication (Minimum) — Do not require a cognitive function test — remembering a password, solving a puzzle, transcribing characters — unless there is an alternative or a mechanism to assist. In practice this means allowing password managers to paste into your login field. Blocking paste on a password field is now a conformance failure, and it was always user-hostile.

Level A

3.2.6 Consistent Help — If you offer a help mechanism (contact link, chat, phone number), it must appear in a consistent relative order across pages.

3.3.7 Redundant Entry — Do not make users re-enter information they already provided in the same process. Auto-populate it or let them select it. Long multi-step government forms are the obvious target.

Level AAA

2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, and 3.3.9 Accessible Authentication (Enhanced) round out the nine.

What was removed

4.1.1 Parsing is obsolete and removed. It required well-formed markup — no duplicate IDs, properly nested elements. Modern browsers and assistive technology handle these robustly enough that the criterion was catching problems that no longer caused real harm. If you have an old audit report with 4.1.1 findings, those findings no longer apply as conformance failures.

This is worth noting when comparing audits across versions: a 2.2 audit can legitimately show fewer failures than a 2.1 audit of the same site, purely from 4.1.1 dropping out.

Should you target 2.2 now?

Our answer for most organizations is yes, but calmly — as the target for new work rather than a reason to reopen everything.

The case for it:

• Backwards compatibility means no wasted effort. Meeting 2.2 AA means you meet 2.1 AA. There is no scenario where the work is thrown away.
• The new criteria are mostly small. Target size and paste-into-password are cheap in new development and disproportionately expensive to retrofit later.
• Regulations move toward the current version. Building to 2.1 today means a migration project when the citation updates.
• They are genuinely good requirements. Redundant Entry and Accessible Authentication address real, common frustrations — not obscure edge cases.

The case for caution:

• Your legal obligation is what your regulator cites. If your contract says WCAG 2.1 AA, that is the bar you must clear, and your conformance report should say 2.1 AA.
• Do not confuse the two in documentation. Claiming “WCAG 2.2 AA” on a VPAT when you evaluated against 2.1 is a misstatement. See what a VPAT actually commits you to.

A practical split: hold existing content to the version your regulation cites, and build new work to 2.2. Note both in your documentation, so a reviewer can see exactly what was tested against what.

What to check first if you are moving to 2.2

In our experience these four surface most often on sites that already conform to 2.1:

1. Password fields that block paste — usually one attribute, and it is a Level AA failure.
2. Sticky headers covering focused elements — test by tabbing through a long page and watching where focus lands.
3. Drag-only interactions without a click alternative.
4. Small icon targets, especially in mobile navigation and toolbars.

None require redesign. All are easy to miss without deliberate keyboard testing, which is why they rarely appear in automated scan results. See how to run a website accessibility audit.

What about WCAG 3.0?

You will see references to WCAG 3.0 (formerly “Silver”). It is an early draft with a fundamentally different conformance model, and it is years from being a Recommendation, let alone a regulatory citation. It is not something to plan compliance work around today. Build to 2.2.

Getting help

Taika provides ADA website accessibility, Section 508 remediation, accessibility assessments, and accessible video.

If you need to know which version you currently meet — and what the gap to 2.2 actually costs — request an assessment. Related reading: Section 508 vs ADA vs WCAG and WCAG & ADA compliance tips.