Skip to main content

ResourcesWCAG

WCAG

WCAG 2.2, Without the Jargon: What Changed and What to Do About It

Nine new success criteria, one retired, and six that apply to almost everyone. Here's what each one means in practice — and the quickest way to check your product against them.

By the Axiya team4 min read

WCAG 2.2 became a W3C Recommendation in October 2023. If your team built to WCAG 2.1, the good news is that nearly all of that work still counts — 2.2 adds to 2.1 rather than replacing it. The less good news is that the new criteria target exactly the places where products tend to cut corners: sticky headers, tiny icons, drag-and-drop, and login screens.

This is a plain-language walk through what changed. No acronyms we don't explain, and no pretending every criterion matters equally.

The short version

  • Nine new success criteria were added.
  • Six of them are Level A or AA — the levels most laws and contracts ask for.
  • Three are Level AAA, which is aspirational for most products.
  • One old criterion, 4.1.1 Parsing, was removed because modern browsers and assistive technologies made it obsolete.

The six you'll almost certainly need

2.4.11 Focus Not Obscured (Minimum) — AA

When someone tabs to a link or button, it can't be completely hidden behind something you put on the page — a sticky header, a chat widget, a cookie banner. Keyboard users need to see where they are. Partially covered is allowed at this level; fully hidden is not.

How to check: tab through your longest page with the cookie banner still open and the header pinned. If the focus ring ever disappears under something, you've found it. A little scroll-padding in CSS usually fixes the header case.

2.5.7 Dragging Movements — AA

Anything you can do by dragging — reordering a list, moving a slider, arranging cards on a board — also needs a way to do it with single taps or clicks. Dragging is genuinely hard for people with tremors, people using a head pointer, or anyone who can't hold a press steady.

How to check: try every drag interaction without dragging. Up and down buttons on a sortable list, or tapping a point on a slider track, are common fixes. This criterion is about pointer input; keyboard access is covered separately.

2.5.8 Target Size (Minimum) — AA

Clickable targets need to be at least 24 by 24 CSS pixels, or have enough space around them that a 24-pixel circle centred on each doesn't overlap its neighbour. Links inside a sentence are exempt, and so are a few other cases, such as when the size is set by the browser rather than by you.

How to check: look hard at icon-only buttons, close crosses on modals, pagination numbers, and the little info icons next to form labels. Those are where 16-pixel targets tend to hide.

3.2.6 Consistent Help — A

If you offer help — a phone number, a contact link, a chat button, an FAQ — on several pages, it should appear in the same relative place on each. People who find navigation hard shouldn't have to hunt for help all over again on every screen. This doesn't force you to offer help; it asks you to be consistent when you do.

3.3.7 Redundant Entry — A

Within a single process, don't make people type the same information twice. If they gave you their address in step two, pre-fill it in step four or let them pick it. Exceptions exist where re-entry is essential, needed for security, or the earlier information is no longer valid.

This one quietly helps everyone — but for people with memory or motor impairments, retyping is where forms get abandoned.

3.3.8 Accessible Authentication (Minimum) — AA

Logging in shouldn't depend on a cognitive function test — remembering a password, transcribing a code, solving a puzzle — unless there's an alternative or some help. In practice, that means letting people paste into password and code fields, supporting password managers, and offering options like email links or passkeys.

How to check: try logging in with a password manager and try pasting a one-time code. If either is blocked, you fail this criterion. Image-based puzzles are allowed at AA only when they ask people to recognise objects, or to identify content they provided themselves.

The three at AAA

  • 2.4.12 Focus Not Obscured (Enhanced): the focused item can't be hidden at all, not even partially.
  • 2.4.13 Focus Appearance: the focus indicator must be large enough and have enough contrast to be seen easily.
  • 3.3.9 Accessible Authentication (Enhanced): no cognitive tests for login, with no exceptions for object recognition or personal content.

You don't usually need AAA for compliance. But Focus Appearance in particular is worth treating as a design goal: a clear, thick focus ring is cheap to build and makes a real difference to keyboard users.

What happened to 4.1.1 Parsing?

Parsing required markup to be well-formed — no duplicate IDs, properly nested elements, and so on. It dates from a time when assistive technology parsed HTML itself and choked on errors. Browsers now handle that consistently, so the criterion was removed in WCAG 2.2. Real problems that used to be flagged under Parsing, like duplicate IDs that break label associations, are still caught by other criteria.

Where to start

  1. Tab through your three most important pages with the sticky header and banners visible.
  2. Find every drag interaction and confirm there's a tap or click alternative.
  3. Measure your smallest icon buttons.
  4. Try logging in with a password manager and pasting a one-time code.
  5. Walk a multi-step form and note anywhere you're asked for the same thing twice.

That's an afternoon's work, and it covers most of what's new. For everything else — and for the 50-odd criteria that were already there — you'll want a proper review with real assistive technology.

Want a second pair of eyes on your product?

Our pay-what-you-feel audit covers the three pages that matter most. We show you the effort; you decide the price.

See the offer

Back to all resources