WCAG 2.2 is the current version of the Web Content Accessibility Guidelines, published by the W3C in October 2023. Compared with WCAG 2.1, it adds nine new success criteria — focus appearance, target size, dragging alternatives, easier logins, and more — and removes one. It’s fully backward-compatible: meet 2.2 AA and you also meet 2.1 AA.
The short answer: what changed
WCAG 2.2 is not a rewrite. It keeps every requirement from WCAG 2.1 AA — the baseline most ADA cases reference — and layers nine new success criteria on top, mostly aimed at people with low vision, motor disabilities, and cognitive disabilities. It also retires one outdated criterion (4.1.1 Parsing).
Think of the versions as nested circles. WCAG 2.0 sits inside 2.1, which sits inside 2.2. Because each version is a superset of the last, conforming to the newest version automatically covers the older ones. That’s why the practical advice is simple: target WCAG 2.2 Level AA and you’re covered for 2.1 AA too.
| Version | Released | New criteria | Backward-compatible? |
|---|---|---|---|
| WCAG 2.0 | 2008 | — | Baseline |
| WCAG 2.1 | 2018 | +17 (mobile, low vision, cognitive) | Includes 2.0 |
| WCAG 2.2 | 2023 | +9, −1 (Parsing removed) | Includes 2.1 |
The 9 new WCAG 2.2 success criteria
Here are the new criteria added in WCAG 2.2, with the conformance level and a plain-language explanation of what each one asks for.
| # | Success criterion | Level | What it means in plain terms |
|---|---|---|---|
| 2.4.11 | Focus Not Obscured (Minimum) | AA | When you tab to an element, it can’t be completely hidden behind a sticky header, cookie banner, or chat widget. |
| 2.4.12 | Focus Not Obscured (Enhanced) | AAA | A stricter version: the focused element must not be hidden at all, even partially. |
| 2.4.13 | Focus Appearance | AAA | The keyboard focus indicator must be large and high-contrast enough to actually see. |
| 2.5.7 | Dragging Movements | AA | Anything you do by dragging (sliders, reorder lists, map panning) must also work with a single click or tap. |
| 2.5.8 | Target Size (Minimum) | AA | Clickable targets — buttons, links, icons — must be at least 24×24 CSS pixels, or have enough spacing around them. |
| 3.2.6 | Consistent Help | A | If you offer help (contact link, chat, phone number), it must appear in the same place on every page. |
| 3.3.7 | Redundant Entry | A | Don’t make users re-type information they already gave you in the same process (auto-fill or carry it forward). |
| 3.3.8 | Accessible Authentication (Minimum) | AA | Logins can’t force a “cognitive function test” — like solving a puzzle or remembering a code — without an easier alternative. |
| 3.3.9 | Accessible Authentication (Enhanced) | AAA | A stronger version with no object-recognition or puzzle-based exceptions. |
Six of these — 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7, and 3.3.8 — land at Level A or AA, which is the level businesses should target. The three AAA criteria (2.4.12, 2.4.13, 3.3.9) are good practice but not part of the standard AA goal.
Why these criteria were added
Each new criterion closes a real gap that left people locked out:
- Focus and target size help people who navigate by keyboard or have tremors, low vision, or limited fine motor control. A focus ring you can’t see, or a 12-pixel “X” you can’t reliably tap, is a barrier.
- Dragging alternatives matter for anyone using a head pointer, switch device, screen reader, or other assistive technology that can’t perform a drag.
- Consistent Help, Redundant Entry, and Accessible Authentication reduce cognitive load — they help people with memory, attention, and learning disabilities complete tasks like checkout and login without being tripped up.
What was removed in WCAG 2.2
WCAG 2.2 removed one criterion: 4.1.1 Parsing. It originally required clean, well-formed HTML (no duplicate IDs, properly nested tags). Modern browsers and screen readers — NVDA, JAWS, and VoiceOver — now handle those markup quirks gracefully, so the criterion no longer reflected a real-world barrier. The W3C marked it obsolete.
Practically: if an old accessibility audit flagged your site only for 4.1.1 issues, those are no longer conformance failures under 2.2. The underlying ARIA and markup still need to be valid for assistive tech to work — just not as a standalone criterion.
Which version should businesses target?
Target WCAG 2.2 Level AA. Here’s the reasoning:
- It’s backward-compatible. Meeting 2.2 AA means you also meet 2.1 AA and 2.0 AA. There’s no scenario where 2.2 leaves a 2.1 requirement unmet.
- It future-proofs your work. Standards keep moving toward the newest version. Remediating to 2.2 now means you won’t redo the work when a contract or regulation catches up.
- It’s the current W3C recommendation. The W3C lists 2.2 as the latest stable guidelines, and the WAI recommends using the most recent version.
The one nuance: regulation and contracts sometimes lag. The 2024 DOJ rule under the ADA’s Title II (state and local government) names WCAG 2.1 AA. Many VPATs and federal Section 508 procurements also reference 2.1 or earlier. That’s fine — conforming to 2.2 AA satisfies any of those, so you can confidently state 2.1 AA conformance on a VPAT while building to 2.2.
If a specific contract names a version, match its language in your accessibility statement and conformance report — but build to the higher bar.
How the new criteria affect testing
Most of the new 2.2 criteria can’t be checked by an automated scanner. Tools are good at flagging missing alt text or low color contrast, but they can’t judge whether a focus indicator is visible enough, whether a slider works without dragging, or whether your login forces a memory test. Those require manual testing with a real keyboard and screen reader.
This is exactly where automated checkers and accessibility overlays fall short. An overlay widget — the kind sold by accessiBe, UserWay, or AudioEye — bolts a script onto your site and claims instant compliance. It can’t reliably fix focus order, resize touch targets in your source, or provide a true non-drag alternative to a custom control. Worse, overlays don’t ensure ADA compliance and have themselves drawn demand letters and lawsuits. The dependable path is manual remediation: fixing the underlying code so the page works for everyone, with or without the new 2.2 features.
A quick WCAG 2.2 readiness checklist
Before you call your site WCAG 2.2 AA, confirm these new-criteria basics:
- Visible focus: every interactive element shows a clear, high-contrast focus ring when tabbed to, and nothing hides it.
- Touch targets: buttons, icons, and links are at least 24×24 pixels or well-spaced.
- No drag-only actions: sliders, sortable lists, and map controls have a click/tap alternative.
- Consistent help: your contact or support link sits in the same spot on every page.
- No re-typing: multi-step forms don’t ask for the same information twice.
- Easy login: authentication offers an alternative to puzzles, memorization, or transcription.
Where Curbcut fits
The jump from 2.1 to 2.2 is small in principle but easy to miss in practice — the new criteria live in details like focus rings and tap targets that automated tools wave past. Curbcut audits and remediates to WCAG 2.2 AA by hand, no overlay, so your site genuinely works for screen-reader and keyboard users. Start with a free accessibility scan, or read the WCAG pillar for the full picture.
This page is general information about accessibility standards, not legal advice. For questions about your specific ADA obligations or risk, consult a qualified attorney.