"Are We Already Compliant, or Not?"
It's a Tuesday afternoon and a dev lead named Marcus is closing out a ticket he's been chasing for three months: the company site is finally WCAG 2.1 AA. Contrast ratios fixed. Alt text audited. Keyboard traps gone. He posts the sign-off in the team channel and, for the first time in a quarter, breathes out.
Forty minutes later, a message lands from legal.
"Hey — our new enterprise vendor's procurement team says they require WCAG 2.2 now. Are we covered, or do we need another sprint?"
Marcus stares at the message. He doesn't actually know. Is 2.2 a totally different standard? Did all that work just get made obsolete? Does he need to start over?
He doesn't need to start over. But he does need to know exactly what changed — because the honest answer is "mostly compliant, with a handful of specific new gaps," and "mostly" is not a word that holds up in a vendor security questionnaire.
This article is the answer Marcus needed.
The Short Version: 2.2 Doesn't Replace 2.1 — It Builds On It
Here's the part that should make Marcus (and you) relax a little: WCAG 2.2 became a W3C Recommendation in October 2023, and it is fully backward compatible with WCAG 2.1. Nothing was invalidated. Every success criterion you satisfied for 2.1 AA still counts, still matters, and is still exactly what it was.
What WCAG 2.2 does is add new success criteria on top of the existing 2.1 set, plus formally remove one criterion that had become obsolete. That's the whole shape of the change. It's additive, not a rewrite.
So the real question isn't "is our 2.1 work wasted?" It's "which of the nine new rules are we missing?"
What's New in WCAG 2.2: Nine Success Criteria
WCAG 2.2 introduces nine new success criteria. Here they are, with the practical translation for each.
2.4.11 Focus Not Obscured (Minimum) — Level AA
When a user tabs to a link or button, that focused element can't be completely hidden behind something else on the screen — a sticky header, a sticky footer, or a cookie consent banner sitting on top of it.
This is the single most common way sites that just passed 2.1 AA fail 2.2. Picture a keyboard user tabbing through a navigation menu on a page with a sticky top header. On the sixth tab stop, the focus lands on a link that's now scrolled up underneath that header. Visually, nothing is there. The user has genuinely lost track of where they are, with no way to see it.
2.4.12 Focus Not Obscured (Enhanced) — Level AAA
The stricter version of the above: no part of the focused element may be hidden, not just "not entirely" hidden. AAA-only, so most consultancies treat it as an aspirational target rather than a compliance requirement.
2.4.13 Focus Appearance — Level AAA
Sets minimum requirements for how visible a focus indicator has to be — size, contrast, and thickness. Also AAA, also usually a "nice to have" rather than a must-fix for most organizations targeting AA.
2.5.7 Dragging Movements — Level AA
Any interface that relies on a drag gesture — a slider, a reorderable list, a drag-to-dismiss card — needs a non-drag alternative. Think buttons to move an item up or down in a list, or arrow-key support on a slider, instead of forcing a click-and-drag motion that's difficult or impossible for users with limited fine motor control.
2.5.8 Target Size (Minimum) — Level AA
Interactive targets — buttons, icon links, nav pills — need to be at least 24x24 CSS pixels, with a short list of exceptions (inline text links, targets where an equivalent larger target exists elsewhere, etc.). This one catches teams off guard constantly, because it's invisible in a design review and only shows up when someone actually measures. A row of icon-only social buttons at 18x18px with 4px of spacing between them, which looked perfectly fine in Figma, fails outright.
3.2.6 Consistent Help — Level A
If your site offers a help mechanism — a live chat launcher, a "Contact us" link, a link to an FAQ — it has to appear in the same relative order across every page it shows up on. If chat support sits in the top-right on your homepage but drops to the bottom of a footer on your checkout page, that's a fail. The logic here is straightforward: users build a mental map of where help lives, and moving it around breaks that map exactly when someone's most likely to need it.
3.3.7 Redundant Entry — Level A
Don't make users retype information they already gave you earlier in the same process. The textbook failure case is a multi-step checkout: step one collects a shipping address, step three asks for a billing address, and the form makes the user retype the whole thing even when it's identical, instead of offering a "same as shipping" option or auto-filling it.
3.3.8 Accessible Authentication (Minimum) — Level AA
Login can't rely solely on a "cognitive function test" — remembering a password, solving a puzzle, transcribing a distorted CAPTCHA image, doing mental math — unless there's an alternative method or some kind of assistance available. A login screen that requires solving an image puzzle with zero alternative path is exactly the failure this criterion targets.
3.3.9 Accessible Authentication (Enhanced) — Level AAA
Same idea, stricter: essentially no cognitive function test at all, even with an alternative. AAA-only.
What Got Removed: 4.1.1 Parsing
WCAG 2.2 also formally removed 4.1.1 Parsing. This criterion originally required strict, valid HTML — no duplicate IDs, properly nested tags, complete start/end tags — because older assistive technology genuinely depended on clean parsing to function correctly. Modern browsers and modern assistive tech no longer have that dependency, so the criterion had become obsolete rather than protective. Removing it doesn't mean "write sloppy HTML on purpose" — it means the specific compliance checkbox is gone because the underlying risk it addressed no longer applies the way it used to.
Which Version Do You Actually Need to Hit?
This is the nuance that matters for a conversation like the one Marcus had with legal.
Most current legal and regulatory references — including the DOJ's Title II rule for state and local government websites — still explicitly cite WCAG 2.1 AA. If your organization's specific legal obligation names 2.1, you are not out of compliance with that obligation by not yet having every 2.2 criterion covered.
But two things are true at the same time:
- WCAG 2.2 is the current technical recommendation, and it's increasingly what shows up in newer contracts, RFPs, and vendor security/accessibility questionnaires — which is exactly the situation Marcus is in.
- Because 2.2 is a strict superset of 2.1, meeting 2.2 AA automatically means you still meet 2.1 AA. There's no scenario where chasing 2.2 puts your 2.1 status at risk. It only adds coverage.
That makes WCAG 2.2 AA the safer target to build toward now, even if your immediate legal requirement still names 2.1.
A Practical WCAG 2.2 Gap Checklist
Before you tell legal (or a vendor, or a client) "we're covered," walk through this list against your actual site:
- Sticky elements: Tab through your site with a keyboard. Does any sticky header, footer, or cookie banner ever fully cover the focused element? (2.4.11)
- Drag interactions: Does every slider, reorderable list, or drag-based control have a non-drag way to perform the same action? (2.5.7)
- Tap targets: Measure your icon buttons, nav pills, and close buttons. Are any smaller than 24x24 CSS pixels with no adequate spacing exception? (2.5.8)
- Help placement: Does your chat widget, contact link, or FAQ link appear in a consistent relative position across every page? (3.2.6)
- Multi-step forms: Does any step re-ask for information the user already entered earlier in the same flow? (3.3.7)
- Login and authentication: Can a user log in without solving a visual puzzle, transcribing a distorted image, or passing a memory/cognitive test — or is there a real alternative if one exists? (3.3.8)
If any of those turn up a fail, you're in exactly the position most sites are in right now: solidly built on 2.1, with a short, specific list of 2.2 gaps to close.
Get It Right the First Time
The gap between "we did an accessibility pass" and "we can prove exactly which success criteria we meet, at which level, with evidence" is where most organizations get caught off guard — usually at the worst possible moment, like a vendor questionnaire or a procurement review.
Reading a list of nine new criteria is one thing. Auditing a real, complex site against every one of them — sticky UI, drag interactions, multi-step forms, authentication flows — and fixing what fails without breaking what already passes is a different job entirely. It's exactly the work WCAG.World does for clients every day: precise, criterion-by-criterion audits against both 2.1 and 2.2, with fixes that are documented and defensible.
If you're not sure whether your site's 2.1 work already covers 2.2, don't guess — get a WCAG 2.2 gap audit and know exactly where you stand before the next legal or vendor question lands in your Slack.