What's New in WCAG 2.2? The Nine New Success Criteria Explained
## The short answer
WCAG 2.2 introduces nine new success criteria on top of WCAG 2.1, and removes one (4.1.1 Parsing) that has become obsolete. The new criteria mostly tackle problems that affect keyboard users, people with motor impairments, and people with cognitive or memory difficulties. They cover focus visibility, focus position, dragging alternatives, minimum target sizes, consistent help placement, redundant data entry, and accessible authentication. If you already meet WCAG 2.1 AA, you are most of the way there - WCAG 2.2 is an incremental update, not a rewrite.
## The nine new criteria
Here is each new criterion, grouped by who it helps most.
### Focus and keyboard navigation
- **2.4.11 Focus Not Obscured (Minimum) - AA**: When an element receives keyboard focus, it must not be entirely hidden by other content such as a sticky header or cookie banner.
- **2.4.12 Focus Not Obscured (Enhanced) - AAA**: A stricter version requiring that no part of the focused element is obscured.
- **2.4.13 Focus Appearance - AAA**: Sets a minimum size and contrast for the focus indicator so it is genuinely visible.
### Motor and pointer interaction
- **2.5.7 Dragging Movements - AA**: Any function that uses a dragging movement must have a single-pointer alternative, such as tapping or clicking, unless dragging is essential.
- **2.5.8 Target Size (Minimum) - AA**: Interactive targets must be at least 24 by 24 CSS pixels, with sensible exceptions for spacing, inline links, and browser-default controls.
### Cognitive support and memory
- **3.2.6 Consistent Help - A**: If help mechanisms (contact details, a help link, a chat widget) appear on multiple pages, they must appear in the same relative order.
- **3.3.7 Redundant Entry - A**: Information a user has already entered in a process must not be requested again in the same session, unless re-entry is essential (for example, confirming a password).
- **3.3.8 Accessible Authentication (Minimum) - AA**: Logging in must not rely on a cognitive function test such as remembering a password or solving a puzzle, unless an alternative or assistance is provided.
- **3.3.9 Accessible Authentication (Enhanced) - AAA**: A stricter version with fewer exceptions.
## What got removed
WCAG 2.2 retires **4.1.1 Parsing**. This criterion originally addressed broken or duplicated markup that confused assistive technology. Modern browsers and assistive technologies handle malformed HTML robustly, so the criterion no longer reflects a real barrier. Importantly, this means meeting WCAG 2.2 can in one narrow respect be easier than meeting 2.1, but you should still write valid markup as a matter of quality.
## How the levels stack up
WCAG criteria are graded A, AA and AAA. Most legal and procurement requirements target **AA**. Of the new criteria, six are at A or AA level and therefore relevant to typical compliance goals:
1. 2.4.11 Focus Not Obscured (Minimum) - AA
2. 2.5.7 Dragging Movements - AA
3. 2.5.8 Target Size (Minimum) - AA
4. 3.2.6 Consistent Help - A
5. 3.3.7 Redundant Entry - A
6. 3.3.8 Accessible Authentication (Minimum) - AA
The remaining three (2.4.12, 2.4.13, 3.3.9) are AAA and usually aspirational rather than mandatory.
## Why this matters for software teams
The theme running through WCAG 2.2 is reducing unnecessary effort and friction. Dragging is hard for people with tremors or limited dexterity. Tiny tap targets cause mis-taps on touchscreens. Remembering passwords and copying one-time codes is taxing for people with cognitive impairments - and frankly for everyone. Consistent help and avoiding redundant data entry reduce confusion in long flows like checkout or onboarding.
Because these are concrete, testable rules, they are well suited to being baked into a design system. If your buttons, links and form fields meet the target-size and focus rules by default, individual feature teams inherit compliance rather than re-discovering it. This is the approach we take when building enterprise-grade products at neart.ai: accessibility constraints live in shared components, so the safe path is also the easy path.
## A quick self-check
Use this as a fast triage before a formal audit:
- Tab through a page with a sticky header open - is the focused control ever hidden?
- Try every drag interaction (sliders, sortable lists, map panning) with single clicks or taps only.
- Measure your smallest buttons and icon controls - are they at least 24 by 24 pixels?
- Can you log in using a password manager's autofill, or without solving a puzzle?
- In a multi-step form, are you ever asked to retype something you already gave?
- Is the help link in the same place on every page?
## Practical takeaway
WCAG 2.2 is an additive update: keep your WCAG 2.1 AA work and layer the six new A/AA criteria on top, focusing first on focus visibility, target size, dragging alternatives and accessible login. Encode these rules in shared components so every new feature inherits them rather than re-litigating accessibility each sprint.