Start scanning free

( WCAG )

WCAG 2.2 explained: what changed and what to do about it

WCAG 2.2 added nine success criteria covering focus visibility, dragging, target size, consistent help and accessible authentication. Here's each one in plain English.

WCAG 2.2 is the current version of the Web Content Accessibility Guidelines. It adds nine success criteria to WCAG 2.1 — six at Level A/AA that most teams need — and removes one (4.1.1 Parsing). The new criteria focus on keyboard focus visibility, easier pointer interaction, consistent help, less repeated typing and login without memory tests.

The six new criteria most teams must meet

2.4.11 Focus Not Obscured (Minimum) — AA

When a control receives keyboard focus, it must not be completely hidden by other content — sticky headers, cookie banners and chat widgets are the usual offenders. If a keyboard user tabs to a link and your sticky footer covers it entirely, that’s a failure. Leave a visible portion, or use scroll-padding to keep focused elements clear of fixed bars.

2.5.7 Dragging Movements — AA

Anything achievable by dragging must also work without it — sliders, kanban boards, reorderable lists, map panning. Dragging is hard or impossible for many people with motor disabilities. Provide a single-pointer alternative: buttons to move items up and down, a numeric input beside the slider, tap-to-select then tap-to-place.

2.5.8 Target Size (Minimum) — AA

Interactive targets must be at least 24×24 CSS pixels, or have enough spacing that a 24px circle centred on each target doesn’t intersect a neighbour. Dense icon rows and inline link clusters are the common failures. Exceptions exist for inline links inside sentences and where spacing compensates.

3.2.6 Consistent Help — A

If you offer help — contact link, phone number, chat widget — it must appear in the same relative place on every page where it appears. Users with cognitive disabilities rely on that consistency to find help when they’re stuck.

3.3.7 Redundant Entry — A

Don’t make people re-type information they already gave you in the same session. Shipping address equals billing address should be a checkbox, not a second form. Auto-populate or offer selection instead. (Security exceptions apply — password confirmation is fine.)

3.3.8 Accessible Authentication (Minimum) — AA

Login must not depend on a cognitive function test — memorising a password with no paste allowed, solving puzzles, transcribing codes without copy support. Allow password managers to work: no blocked paste, no disabled autofill. Support alternatives like email magic links or passkeys where you can.

The three AAA additions

  • 2.4.12 Focus Not Obscured (Enhanced) — the focused element must be entirely visible, not just partially.
  • 2.4.13 Focus Appearance — focus indicators must meet minimum size and contrast requirements.
  • 3.3.9 Accessible Authentication (Enhanced) — removes the object-recognition and personal-content exceptions from the AA version.

Most organisations target AA, but 2.4.13 is worth reading anyway — its guidance produces focus states that are simply better for everyone.

What was removed: 4.1.1 Parsing

WCAG 2.2 deletes 4.1.1 Parsing. When it was written, malformed HTML genuinely broke assistive technologies. Modern browsers normalise broken markup before AT ever sees it, so the criterion was retired. Duplicate IDs and broken ARIA references still fail — they just fail under 4.1.2 Name, Role, Value and related criteria instead.

How to adopt WCAG 2.2

  1. Confirm your baseline. If you conform to 2.1 AA today, only the six new A/AA criteria are new work.
  2. Audit the hot spots. Sticky UI (2.4.11), drag interactions (2.5.7), small targets (2.5.8), help placement (3.2.6), long forms (3.3.7) and your login flow (3.3.8).
  3. Fix the login first. Accessible Authentication failures are common, high-impact and usually cheap to fix — stop blocking paste, stop fighting password managers.
  4. Keep scanning. Automated checks catch the structural failures continuously; schedule manual review for the interaction-heavy criteria that automation can’t judge.

New projects should target WCAG 2.2 AA from day one. It’s a strict superset of 2.1 AA, so there’s no scenario where meeting it puts you behind a legal requirement that references the older version.

Frequently asked questions

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 adds nine new success criteria to WCAG 2.1 — mostly around keyboard focus visibility, pointer interactions like dragging and target size, consistent help placement, redundant form entry and accessible authentication. It also removes 4.1.1 Parsing. Everything that conformed to 2.1 still applies.

Do I need to conform to WCAG 2.2 or is 2.1 enough?

It depends on your legal context. Many procurement and government requirements still reference WCAG 2.1 AA, but new legislation increasingly points to 2.2. Since 2.2 is a superset, conforming to 2.2 AA satisfies 2.1 AA automatically — target 2.2 for new work.

Which WCAG 2.2 criteria are Level AA?

Six of the nine new criteria are AA or below: Focus Not Obscured (Minimum), Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry and Accessible Authentication (Minimum). The remaining three are AAA.

Was anything removed in WCAG 2.2?

Yes — success criterion 4.1.1 Parsing was removed. Modern browsers and assistive technologies handle malformed HTML consistently enough that the criterion no longer added value. Validation errors can still cause real failures under other criteria like 4.1.2 Name, Role, Value.

AI Search Does accessibility affect Google rankings? AI Search Why accessibility matters for AI search Product Design Accessibility mistakes product teams make