WCAG 2.2 New Requirements: All 9 New Success Criteria Explained
WCAG 2.2 was published in October 2023. It added 9 new success criteria and removed one (4.1.1 Parsing). Four of the new criteria are Level AA — meaning they carry legal weight. Here's exactly what changed and how to meet each requirement.
TL;DR — The 4 New AA Requirements You Need to Implement
- 2.4.11Focus Not Obscured — Sticky headers/footers must not completely hide the focused element
- 2.5.7Dragging Movements — Every drag interaction must have a non-drag alternative (click, tap, or keyboard)
- 2.5.8Target Size Minimum — Interactive targets must be at least 24×24 CSS pixels
- 3.3.8Accessible Authentication — CAPTCHAs must have an accessible alternative; don't block password manager paste
Plus 2 new Level A criteria: 3.2.6 Consistent Help and 3.3.7 Redundant Entry (most sites with consistent headers/auto-fill already meet these)
1. What Changed in WCAG 2.2
WCAG 2.2 is a backwards-compatible update to WCAG 2.1. All existing WCAG 2.1 success criteria remain in 2.2, with one exception: 4.1.1 Parsing has been removed. The W3C concluded that modern browsers and assistive technologies now handle HTML parsing errors gracefully enough that this criterion no longer serves its original purpose.
The 9 new criteria were developed to address gaps in mobile accessibility, cognitive accessibility, and real-world patterns that WCAG 2.1 didn't cover — particularly around touch targets, authentication barriers, and the growing prevalence of sticky navigation.
| SC | Name | Level | Principle |
|---|---|---|---|
| 2.4.11 | Focus Not Obscured (Minimum) | AA | Operable |
| 2.4.12 | Focus Not Obscured (Enhanced) | AAA | Operable |
| 2.4.13 | Focus Appearance | AAA | Operable |
| 2.5.7 | Dragging Movements | AA | Operable |
| 2.5.8 | Target Size (Minimum) | AA | Operable |
| 3.2.6 | Consistent Help | A | Understandable |
| 3.3.7 | Redundant Entry | A | Understandable |
| 3.3.8 | Accessible Authentication (Minimum) | AA | Understandable |
| 3.3.9 | Accessible Authentication (Enhanced) | AAA | Understandable |
| 4.1.1 | Parsing (REMOVED) | Removed | Robust |
2. Each New Criterion Explained
Below is a plain-language breakdown of every new WCAG 2.2 success criterion, including why it exists, how to meet it, and the most common failure patterns.
When a UI component receives keyboard focus, it must not be entirely hidden by sticky headers, cookie banners, chat widgets, or other author-created content.
Why this criterion exists:
Keyboard users navigate by watching the focus indicator move around the screen. If a focused element is completely covered by a sticky element, the user has no visual feedback about where they are in the page.
How to meet it:
- ✓Ensure sticky headers have a scroll-margin-top or scroll-padding-top applied to focusable elements below them
- ✓When a modal opens, move focus into the modal — not to an element behind it
- ✓Test by tabbing through the page with any sticky bars visible — every focused element must be at least partially visible
- ✓Cookie consent banners that cover content below them are a common failure point
How to test:
Tab through the page and check that no focused element is 100% obscured by sticky headers, footers, or overlays. Partial obscuring passes (2.4.12 covers full unobscured visibility at AAA).
Common failures:
- ✗Sticky navigation bar covers focused links below it
- ✗Live chat widget obscures focused form fields
- ✗Cookie banner sits over top of all page content on load
The focused component must not be obscured by author-created content at all — not even partially. This is the stricter version of 2.4.11.
Why this criterion exists:
Some users need to see the entire focused element to understand its context, label, and state. Partial visibility (allowed by AA) may not be sufficient for users with low vision who use screen magnification.
How to meet it:
- ✓Apply scroll-margin-top equal to the height of any sticky header, plus a small buffer
- ✓Use JS to programmatically scroll the focused element fully into the visible viewport
- ✓Architect sticky elements with z-index layering so they never intersect with the content layer
How to test:
Tab through all interactive elements and verify each is fully visible when focused. No part of the element should be behind a sticky element.
Common failures:
- ✗Partial sticky header overlap on focused links
- ✗Bottom navigation bars partially covering focused buttons on mobile
The keyboard focus indicator must meet specific minimum size and contrast requirements: the focus indicator must have a perimeter of at least the CSS outline size of the unfocused component, with a contrast ratio of at least 3:1.
Why this criterion exists:
Many sites suppress the default browser focus ring (outline: none) and replace it with subtle custom styles that are too low-contrast or too thin to be visible to users with low vision.
How to meet it:
- ✓Use a focus ring with at least 3:1 contrast against both the focused element's background and the adjacent color
- ✓The focus indicator area should cover the perimeter of the component
- ✓Thick, high-contrast focus rings (e.g., 3px solid #005FCC) are the safest pattern
- ✓Test with browser default focus styles replaced by custom ones — verify they remain visible
How to test:
Manually tab through each interactive element and verify the focus ring is visually prominent. Use a contrast checker on the focus ring color vs. background.
Common failures:
- ✗Custom focus ring with 1px border barely visible on light backgrounds
- ✗Focus indicator only changes background color with insufficient contrast
All functionality that uses dragging (sliders, drag-and-drop, map panning) must also be achievable with a single pointer without dragging — for example, via click/tap alternatives.
Why this criterion exists:
Dragging requires precise motor control and sustained pointer pressure that many users with motor disabilities, tremors, or limited hand dexterity cannot perform reliably.
How to meet it:
- ✓Sliders: provide +/- buttons or allow direct numeric input as an alternative to dragging
- ✓Drag-and-drop file upload: also accept a click-to-browse alternative
- ✓Sortable lists: add up/down arrow buttons as alternatives to drag reordering
- ✓Map controls: provide keyboard-accessible zoom controls alongside pinch/drag
- ✓Exception: dragging is essential to the function (e.g., a drawing canvas) — the criterion does not apply
How to test:
Identify every interaction on the page that requires drag. Verify an equivalent non-drag alternative exists and is accessible via keyboard.
Common failures:
- ✗Range sliders without keyboard access or step input fallback
- ✗Drag-to-sort lists with no button-based reordering
- ✗File upload zones with no browse button
Interactive targets must be at least 24×24 CSS pixels, or have spacing around them (offset) that brings the total activation area to 24×24px.
Why this criterion exists:
Small targets — like icon buttons without padding, inline text links, or tightly packed navigation items — are difficult to activate accurately for users with motor disabilities, tremors, or those using touch screens.
How to meet it:
- ✓Most buttons and controls should be at least 24px in their smallest dimension
- ✓For inline text links, the spacing offset exemption usually applies — surrounding whitespace counts toward the 24px total
- ✓Add padding to icon buttons to increase their activation area without changing visual size
- ✓WCAG 2.2 AAA (2.5.5) requires 44×44px — 24px is the minimum AA floor, not the ideal
How to test:
Inspect small buttons and icon-only controls in browser devtools. Check computed height/width. For touch: test on a real device or use Chrome DevTools device simulation.
Common failures:
- ✗16px × 16px icon buttons without surrounding padding
- ✗Dense navigation menus with 18px link height and no vertical padding
- ✗Close (×) buttons on modals that are visually small
If a help mechanism (phone number, chat, contact form, self-help link) appears on multiple pages of a website, it must appear in a consistent location relative to the page content.
Why this criterion exists:
Users with cognitive disabilities often rely on consistent patterns to navigate. If a help link is in the header on some pages and the footer on others, it creates confusion and additional cognitive load.
How to meet it:
- ✓Place help mechanisms (live chat, contact links, phone numbers) in the same location across all pages
- ✓Most sites satisfy this naturally if they use a consistent header/footer across all pages
- ✓If you add a 'Need help?' link to some pages but not others, this criterion doesn't apply — it only applies when the help mechanism IS present on multiple pages
How to test:
Navigate to 5-10 different page templates (home, product, checkout, contact, blog). Verify that any help mechanism that appears on multiple pages appears in the same relative position.
Common failures:
- ✗Live chat button in bottom-right on marketing pages but absent on app pages
- ✗Contact link in header nav on some pages, footer-only on others
Information users have already provided in a multi-step process must not be requested again — unless re-entering is essential (e.g., password confirmation) or the information has expired.
Why this criterion exists:
Requiring users to re-type information they already provided creates barriers for users with cognitive disabilities, motor impairments, and memory difficulties. It also increases error rates for everyone.
How to meet it:
- ✓Pre-populate form fields with data already collected (e.g., billing address defaults to shipping address in checkout)
- ✓In multi-step forms, carry forward selections rather than resetting them
- ✓Provide auto-fill-friendly field names and autocomplete attributes
- ✓Password confirmation fields are an explicit exception — re-entry is essential for accuracy
How to test:
Complete a multi-step form or checkout flow. Track every piece of data you enter. Verify no field asks for information you already provided (unless the re-entry is explicitly necessary).
Common failures:
- ✗Checkout flow asks for email again on the payment step after collecting it during account creation
- ✗Multi-step forms reset previous step answers when the user navigates back
If a cognitive function test (like solving a puzzle or recognizing characters) is required during authentication, an alternative must be provided — unless the test is for essential recognition or the website provides a helper mechanism.
Why this criterion exists:
CAPTCHAs and other cognitive puzzles during login create significant barriers for users with cognitive disabilities, dyslexia, and screen reader users. Many users cannot reliably solve these puzzles.
How to meet it:
- ✓Provide an audio alternative for visual CAPTCHAs
- ✓Use email/SMS OTP codes instead of cognitive puzzles — these don't require cognitive function tests
- ✓Magic link authentication (click a link sent to your email) fully satisfies this criterion
- ✓Passkeys and biometric login satisfy this criterion
- ✓If you use a CAPTCHA service, ensure it has an accessible alternative mode — reCAPTCHA v3 (invisible) and hCaptcha's accessibility cookie are common solutions
- ✓Allowing users to copy-paste passwords from password managers satisfies the intent (no retype cognitive load)
How to test:
Attempt to log in using only a keyboard and/or screen reader. If a CAPTCHA appears, verify an accessible alternative is available. Check if the site blocks password manager auto-fill.
Common failures:
- ✗Image-based CAPTCHA with no audio alternative
- ✗Blocking paste in password fields
- ✗Custom image-selection puzzles with no alternative authentication path
The stricter version of 3.3.8 — no cognitive function tests during authentication, period. No exceptions for object recognition or personal content identification.
Why this criterion exists:
Even image-based alternatives (select all photos with a traffic light) require cognitive processing that is a barrier for users with cognitive disabilities. The AAA level requires complete elimination of cognitive tests from authentication.
How to meet it:
- ✓Use passkeys, biometric authentication, or magic link email authentication
- ✓OTP via email or SMS is acceptable at AAA level
- ✓If you must use image recognition, provide an alternative path that has no cognitive test at all
How to test:
Verify that every authentication pathway available to the user is free of any cognitive puzzle, riddle, image selection task, or character-matching exercise.
Common failures:
- ✗Image-CAPTCHA with audio alternative (this passes AA 3.3.8 but fails AAA 3.3.9)
- ✗Object recognition CAPTCHA ('select all bicycles')
3. WCAG 2.2 and the Law
The DOJ's 2024 Title II rule (for state and local government websites) references WCAG 2.1 Level AA as the technical standard. However, the DOJ explicitly noted that entities may comply by meeting WCAG 2.2 instead. For private-sector websites (Title III ADA), courts and plaintiffs continue to use WCAG 2.1 AA as the benchmark.
In practice, this means:
- Meeting WCAG 2.2 AA is better than meeting WCAG 2.1 AA. A site conforming to WCAG 2.2 is automatically conforming to WCAG 2.1 (since 2.2 is backwards-compatible), minus the removed 4.1.1 criterion — which no longer matters.
- The new AA criteria (2.4.11, 2.5.7, 2.5.8, 3.3.8) are increasingly referenced in plaintiff demand letters. Sticky header focus obscuring and CAPTCHA barriers are frequently cited in ADA demand letters targeting e-commerce sites.
- Section 508 was updated in 2017 to reference WCAG 2.0. Federal agencies are not yet required to meet WCAG 2.2, but many are proactively upgrading to 2.2 AA.
- EU EN 301 549 references WCAG 2.1 AA. The European Accessibility Act (effective June 2025) uses this standard. EU harmonized standards are expected to adopt WCAG 2.2 references in future updates.
Practical Guidance
If your site currently meets WCAG 2.1 AA and you want to upgrade to 2.2 AA, you need to audit for the 4 new AA criteria (2.4.11, 2.5.7, 2.5.8, 3.3.8) and the 2 new A criteria (3.2.6, 3.3.7). Remove 4.1.1 from your testing checklist — it no longer applies. The upgrade is typically a few days of work for a typical web application, not a major overhaul.
4. How to Audit for WCAG 2.2 Compliance
Automated Testing Gaps
Most automated accessibility scanners (axe, WAVE, Lighthouse) were built around WCAG 2.1. They are slower to update for WCAG 2.2. As of 2026:
- axe-core — has rules for some 2.2 criteria (target size, focus not obscured) but coverage is incomplete. Deque's paid axe DevTools has better 2.2 coverage.
- WAVE — limited WCAG 2.2 coverage as of 2026; treats it as supplementary.
- Siteimprove / Pope Tech / Monsido — enterprise platforms are actively adding 2.2 rules; check their documentation for current coverage.
Manual Testing Checklist for WCAG 2.2
🔍 Run a Free WCAG 2.2 Scan
RatedWithAI's free scanner checks your site against WCAG 2.2 criteria and surfaces the violations most likely to create legal exposure. Get a prioritized report in minutes.
Sponsored
Also audit your site's full technical health
SEMrush Site Audit checks 130+ issues — missing alt text, broken links, slow pages. Free crawl up to 100 pages, no credit card required.
5. Frequently Asked Questions
When was WCAG 2.2 published?
WCAG 2.2 was published as a W3C Recommendation on October 5, 2023. It is the current stable version of WCAG. WCAG 3.0 is still in development and not expected to be finalized before 2028 at the earliest.
Do I need to meet WCAG 2.2 or is WCAG 2.1 enough?
Most legal frameworks (ADA, Section 508, EU EAA) reference WCAG 2.1 AA. Meeting WCAG 2.1 AA technically satisfies current legal requirements in most jurisdictions. However, upgrading to WCAG 2.2 AA provides a stronger defensible position and addresses real accessibility barriers that plaintiff attorneys are increasingly citing in demand letters, particularly around CAPTCHA barriers and touch target sizes.
Is 4.1.1 Parsing still required under WCAG 2.1?
Yes. If you're auditing against WCAG 2.1, criterion 4.1.1 Parsing still applies. It was only removed in WCAG 2.2. If you're auditing against WCAG 2.2, you do not need to test for 4.1.1.
What's the most impactful new WCAG 2.2 criterion for most websites?
For most modern websites, 2.4.11 (Focus Not Obscured) and 3.3.8 (Accessible Authentication) tend to be the most commonly failed. Sticky navigation covering focused elements is extremely common, and blocking password paste or using inaccessible CAPTCHAs is rampant across SaaS and e-commerce sites.
Does WCAG 2.2 apply to mobile apps?
WCAG 2.2 applies to web content. Mobile apps are addressed by the Mobile Accessibility guidance (an informative document from W3C) and by platform-specific accessibility guidelines (WCAG2ICT, Apple Accessibility Guidelines, Android Accessibility). However, many WCAG 2.2 criteria — especially 2.5.7, 2.5.8, and 3.3.8 — are directly relevant to mobile web experiences and native apps use them as design references.
Does Your Site Meet WCAG 2.2 Level AA?
Run a free scan to find WCAG 2.2 violations — including the new criteria around focus visibility, touch targets, and authentication. Get a prioritized fix list in minutes.