WCAG 2.2 was published as a W3C Recommendation in October 2023. Most teams I work with are still operating on 2.1 in their default checklist, partly out of habit and partly because the new criteria are genuinely fiddly to test for. They are also, in most cases, reasonable. They surface issues that experienced designers were already trying to avoid by instinct.
This piece walks through what 2.2 actually adds, what it removes, and — more usefully — what it changes about how you should be drawing components in your Figma file before they reach engineering. I'll skip the standards bureaucracy. If you want the spec itself, it lives at w3.org/TR/WCAG22.
What's new at a glance
2.2 adds nine new success criteria and removes one. The new ones cluster around three themes: focus visibility, mobile and motor accessibility, and cognitive load on authentication and forms. The removed one is 4.1.1 Parsing, which became obsolete because modern browsers handle malformed HTML gracefully. You don't need to remember it; just don't grieve.
Three of the new criteria are A or AA conformance — meaning if you're targeting AA, which is what most regulated industries effectively require, you now have new things to test against. Six are AAA, which most teams treat as aspirational rather than mandatory. I'll focus on the AA changes first.
The AA additions: what's blocking AA conformance now
2.4.11 Focus Not Obscured (Minimum)
When an element has keyboard focus, it cannot be entirely hidden by other content — for example, by a sticky header, a cookie banner, or a footer that overlaps when you tab into the bottom of the page.
This is more common than designers realise. Sticky elements are everywhere, and tab-order doesn't always scroll the page to keep the focused element visible. The fix is usually one of: ensure the focused element scrolls into view, give sticky elements a sensible z-index stack, or use scroll-padding to offset the scroll target.
What to check in design: any sticky/fixed-position element. If a focusable element could ever sit underneath it, you have a problem.
2.5.7 Dragging Movements
If your interface relies on dragging to perform an action (sliders, kanban boards, range pickers, map pans), there must be a non-drag alternative. Buttons that increment a value, click-to-position, or keyboard arrow controls all qualify.
This is mainly a problem for designers shipping novel interactions. The classic offenders are temperature controls in IoT apps, image cropping tools, and signature capture widgets. If your only way to use it is to drag, you're not 2.2 compliant.
What to check in design: any drag-driven interaction. The alternative doesn't need to be visually equivalent — it just needs to exist and work.
2.5.8 Target Size (Minimum)
This is the headline change for designers. All interactive targets must be at least 24×24 CSS pixels, or have spacing of at least 24 pixels between them so a circle of 24px diameter centred on the target wouldn't overlap any other interactive target.
That sounds generous compared to the long-established Apple (44pt) and Material (48dp) recommendations. But the 2.2 criterion has exceptions: if the target is part of a sentence (an inline link), or it's controlled by the user agent, or it has equivalent UI elsewhere on the page. So in practice it mainly hits things like icon-only nav bars, dense table-row actions, and tag close buttons.
The places I see this fail most often: pagination controls, "remove" X buttons in tag pickers, sort/filter icons in data tables, and the right-side cluster of actions on email clients. If you're shipping a 16px icon as a clickable target, it needs at least 4px of padding on every side, with at least 24px spacing to the next target.
What to check in design: every clickable thing under 24×24px, especially when adjacent to other clickable things.
3.2.6 Consistent Help
If your site provides a help mechanism — a chat, a contact link, a help search — its location must be consistent across pages. You can't have it in the header on most pages and in the footer on others.
This sounds obvious. It is constantly violated in practice, especially when product pages and marketing pages use different templates. What to check: walk through your site map and locate the help element on each page type. If it moves, that's a finding.
3.3.7 Redundant Entry
If a user has already entered information in a session, you can't ask them to enter it again unless re-entry is essential — for example, asking for a password again before a destructive action. The most common violations are checkout flows that re-ask for the email already used at sign-in, and multi-step forms that re-collect identity information at each step.
Fix: prefill where possible. If you can't prefill, allow the user to copy from a previous step.
3.3.8 Accessible Authentication (Minimum)
The most controversial new criterion. It states that any cognitive function test (remembering a password, transcribing a code, solving a CAPTCHA) cannot be the only way to authenticate. There must be an alternative for users who struggle with cognitive function tests.
In practice this usually means supporting password managers (don't disable autofill or paste), supporting passwordless options (magic links, WebAuthn), or providing image-based CAPTCHAs alongside text-based ones.
The most frequent violation: autocomplete="off" on password fields, or JavaScript that intercepts and blocks paste into the password field. Both make the field hostile to password managers, which is exactly the cognitive crutch this criterion exists to protect.
The AAA additions (briefly)
For completeness:
- 2.4.12 Focus Not Obscured (Enhanced) — focused elements must be entirely visible, not just partially.
- 2.4.13 Focus Appearance — focus indicators must meet specific size and contrast minimums (not just "be visible").
- 3.3.9 Accessible Authentication (Enhanced) — same as 3.3.8 but stricter, no exceptions.
If you're targeting AAA, you'll know it. Most teams shouldn't unless they've been asked to.
What this means for your design files
Three concrete things to do this week if your component library predates WCAG 2.2:
1. Audit interactive sizes
Walk through your icon-only buttons. Anything below 24×24 CSS pixels should be reviewed. The fix is usually padding, not changing icon size — your 16px icon can stay 16px, but the clickable wrapper around it needs to be 24×24 minimum.
2. Audit your focus styles
Make sure focus rings are visible against every background colour your site uses, including hover states and disabled states. Sticky headers and modal overlays are the usual culprits — a focus ring that's perfect on the body background can disappear when an element is behind a translucent overlay.
3. Audit your auth flow
Open your password field. Try pasting into it. Does it work? Try with a password manager. Does autofill work? If either fails, you've got a 3.3.8 problem. Most fixes here are removing JavaScript event handlers that were probably added to "help" but actively block users.
What 2.2 doesn't fix
The persistent gaps in WCAG remain — and they're the same ones that have always frustrated designers actually working on accessibility:
- Cognitive accessibility is still under-specified compared to motor and visual.
- Reading level and plain language are still nowhere in the standard.
- Animation, autoplay and motion sickness only get partial coverage.
- The standard doesn't and can't tell you whether your information architecture is actually findable for the people you're designing for.
WCAG remains a floor, not a ceiling. Hitting AA is the legal minimum in most jurisdictions; it isn't the same as building something genuinely usable for disabled users. That work continues to require research, testing with real users, and a willingness to be told your beautiful design is unusable.
Tools
For the deterministic parts of WCAG 2.2 — contrast, target size, focus visibility — automation can catch a lot. The contrast checker on this site handles 1.4.3 (and the related criteria for non-text contrast). Lighthouse, axe-core and Wave will catch most of the rest. The new 2.2 target-size criterion is partially automatable but often requires manual review for edge cases.
For the human-judgement parts — was the form genuinely accessible to a user with cognitive load? did the dragging alternative work for someone with motor differences? — there is no substitute for testing with disabled users. WCAG is the floor, not the ceiling.