What's New in WCAG 2.2: A Complete Guide

What Is WCAG 2.2?

The Web Content Accessibility Guidelines (WCAG) 2.2 was published by the W3C as a stable recommendation on 5 October 2023. It builds directly on WCAG 2.1 — all existing criteria from 2.1 remain in effect, 9 new success criteria were added, and one criterion (4.1.1 Parsing) was deprecated.

WCAG 2.2 continues to use the same three conformance levels: A (minimum), AA (the most common legal and procurement target), and AAA (aspirational). The new criteria span all three levels.

If your product already meets WCAG 2.1 AA, reaching WCAG 2.2 AA requires addressing four new criteria: 2.4.11 Focus Not Obscured (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, and 3.3.8 Accessible Authentication (Minimum). The remaining five new criteria are Level AAA and not required for typical compliance targets, but understanding them helps you build better products.

The 9 New Success Criteria in Detail

2.4.11 Focus Not Obscured (Minimum) — Level AA

What changed: When a user interface component receives keyboard focus, it must not be entirely hidden by author-created content such as sticky headers, cookie banners, or chat widgets.

Why it matters: Users who navigate by keyboard must be able to see which element currently has focus. If a focused element is completely hidden behind a sticky navigation bar or a cookie consent banner, the user loses their place on the page and keyboard navigation effectively breaks.

Real-world example: A user tabs through a long product listing page. As they reach the items near the top of the visible area, a 60-pixel sticky header covers the focused product card entirely. The user can no longer see which card is active. To pass 2.4.11, the page must scroll or adjust so that at least part of the focused element remains visible.

How to test: Tab through every interactive element on the page — links, buttons, form fields, custom controls. Pay special attention to areas near sticky headers, sticky footers, cookie banners, and chat overlays. If any focused element disappears completely behind one of these layers, this criterion fails.

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

What changed: This is the stricter version of 2.4.11. The focused component must be fully visible — not just partially. No part of the focus indicator may be hidden by author-created content.

Real-world example: A footer link receives focus, but the bottom 10 pixels of its focus ring are clipped by a sticky cookie banner. Under 2.4.11 this passes (the element is partially visible), but under 2.4.12 it fails because the focus indicator is not entirely visible.

How to test: Repeat the same keyboard tabbing process as 2.4.11, but check that the focused element and its focus indicator are 100% visible — no partial overlap with any sticky or fixed-position content.

2.4.13 Focus Appearance — Level AAA

What changed: This criterion sets minimum visual requirements for custom focus indicators. Specifically: the focus indicator's area must be at least as large as a 2-CSS-pixel-thick perimeter around the unfocused component, and the contrast ratio between the focused and unfocused states must be at least 3:1.

Why it matters: Many websites remove the default browser focus outline (outline: none) and replace it with a custom style that is too subtle — a faint color change or a thin 1-pixel border that is nearly invisible. This criterion ensures that custom focus indicators are actually perceivable.

Real-world example: A design system uses a light gray box-shadow as the focus indicator on white-background buttons. The contrast between the shadow color and the surrounding background is only 1.5:1, falling below the 3:1 minimum. The team would need to switch to a darker focus ring or use the browser default.

How to test: Inspect the CSS of your custom focus styles. Measure the contrast ratio between the focus indicator color and the adjacent colors using a tool like the WebAIM Contrast Checker. Verify the indicator's area meets the minimum perimeter size.

2.5.7 Dragging Movements — Level AA

What changed: Any functionality that uses dragging (click-and-drag, touch-and-drag) must also be operable with a single pointer action without dragging — unless dragging is essential to the underlying activity.

Why it matters: Dragging requires fine motor control — holding a pointer button while moving. Users with tremors, limited dexterity, or those using alternative input devices (head pointers, eye trackers, switch devices) cannot reliably perform drag operations.

Real-world example: A project management board lets users drag cards between columns (e.g., "To Do" to "In Progress"). To pass 2.5.7, it must also offer an alternative — for instance, a context menu on each card with "Move to..." options, or a dropdown that lets the user select the target column.

How to test: Identify every draggable interaction on your site: sortable lists, drag-to-reorder interfaces, slider controls, drag-to-upload areas, canvas drawing tools. For each one, verify that an alternative single-click or tap mechanism achieves the same result.

2.5.8 Target Size (Minimum) — Level AA

What changed: Interactive targets (buttons, links, form controls) must have a minimum size of 24 by 24 CSS pixels — unless the target is inline within a sentence, the target size is determined by the user agent (e.g., default checkboxes), or a larger target for the same action exists elsewhere on the page.

Why it matters: Small touch targets are difficult or impossible to activate for users with motor impairments, users with large fingers on touchscreens, and users with tremors. The previous WCAG 2.1 criterion 2.5.5 Target Size (Enhanced) required 44x44 pixels at Level AAA, which few sites met. This new Level AA criterion sets a more achievable 24x24 pixel floor.

Real-world example: A data table has tiny 16x16 pixel "edit" icons in each row. These fail 2.5.8 because they are below the 24x24 minimum. The fix is to either enlarge the icons or add sufficient padding/margin so the clickable area reaches 24x24 pixels.

How to test: Use browser DevTools to inspect the computed size of interactive elements. Check buttons, icon-only links, form controls, and any clickable area. Elements below 24x24 CSS pixels fail unless they qualify for one of the exceptions (inline text links, user-agent-controlled elements, or a larger duplicate target exists).

3.2.6 Consistent Help — Level A

What changed: If a webpage offers help mechanisms — a phone number, email address, chat widget, contact form link, or FAQ link — those mechanisms must appear in the same relative order across pages within a set of web pages.

Why it matters: Users with cognitive disabilities rely on predictable page structure to find support when they get stuck. If "Contact Support" is in the footer on one page, in the header on another, and missing entirely on a third, users who need help the most cannot find it.

Real-world example: An e-commerce site has a "Help" link in the top navigation on product pages, but on the checkout page, the navigation is removed and the only help link is buried in the footer. This inconsistency fails 3.2.6. The fix is to ensure the help mechanism appears in the same location (e.g., always in the header or always in the footer) on every page.

How to test: Identify every help mechanism across your site — chatbot widgets, "Contact us" links, phone numbers, help center links. Navigate through at least 5-10 representative pages and verify these mechanisms appear in the same relative order. They do not need to be in the exact same pixel position, but their order within the page structure must be consistent.

3.3.7 Redundant Entry — Level A

What changed: Information that users previously entered in the same process must either be auto-populated or available for the user to select — unless re-entering the information is essential for security (e.g., re-typing a password for confirmation) or the previously entered data is no longer valid.

Why it matters: Re-entering data is a significant burden for users with cognitive disabilities, motor impairments, or memory difficulties. It increases error rates and abandonment, especially in multi-step processes.

Real-world example: A shipping checkout flow asks for the user's name and address on the "Shipping" step. On the "Billing" step, it asks for the billing name and address again from scratch, with empty fields. To pass 3.3.7, the billing step should pre-fill with the shipping data and offer a "Same as shipping" checkbox, or at minimum present the previously entered values for the user to confirm or change.

How to test: Walk through every multi-step form or workflow on your site — account creation, checkout, application forms, multi-page surveys. Note any field that requests the same information the user already provided in a previous step. Verify that the second instance is pre-filled or selectable.

3.3.8 Accessible Authentication (Minimum) — Level AA

What changed: Authentication processes must not require the user to solve a cognitive function test — such as a text CAPTCHA, image puzzle, or pattern recall — unless at least one alternative is provided: another authentication method that does not require a cognitive test, a mechanism to assist with the test (e.g., copy-paste support for a text CAPTCHA), or an option to bypass it.

Why it matters: CAPTCHAs and cognitive tests are a major barrier for users with dyslexia, cognitive disabilities, visual impairments, and certain motor impairments. They are often the single biggest accessibility barrier on the web, preventing affected users from logging in or creating accounts at all.

Real-world example: A banking site requires users to solve a distorted-text CAPTCHA on every login attempt with no alternative. This fails 3.3.8. Acceptable alternatives include: passkey/WebAuthn authentication, SMS or email one-time codes, OAuth login via a third-party provider, or allowing users to copy-paste the CAPTCHA text (which lets password managers and assistive tech handle it).

How to test: Attempt to log in, register, and reset your password. At each step, check whether a cognitive function test is required. If a CAPTCHA or puzzle is present, verify that at least one alternative path exists that does not require solving a cognitive test.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

What changed: This extends 3.3.8 further — no cognitive function tests are permitted at all during authentication, even if alternatives are provided. The authentication process must be completable without any cognitive test.

Real-world example: A site offers both a CAPTCHA login and a passkey login. This passes 3.3.8 (an alternative exists) but fails 3.3.9 because the CAPTCHA option still exists as a path. To meet 3.3.9, the site would need to remove the CAPTCHA entirely or replace it with a non-cognitive mechanism like a honeypot field.

How to test: Review all authentication flows and verify that none of them — not even optional ones — include cognitive function tests.

What Was Deprecated: 4.1.1 Parsing

4.1.1 Parsing was a Level A criterion in WCAG 2.0 and 2.1 that required valid HTML markup — no duplicate IDs, properly nested elements, no unclosed tags. In WCAG 2.2, this criterion is deprecated and always considered satisfied.

Why was it removed? When WCAG 2.0 was published in 2008, assistive technologies often parsed raw HTML directly. Malformed markup caused real problems — screen readers would skip content, duplicate IDs would cause ARIA references to break unpredictably. By 2023, the landscape changed completely. Modern assistive technologies rely on the browser's accessibility tree (built from the parsed DOM), not raw HTML source. Browsers handle malformed markup consistently through well-defined error-recovery algorithms in the HTML specification.

What this means for you: If your existing VPAT or audit report lists 4.1.1 failures, those findings are no longer relevant under WCAG 2.2. However, writing valid HTML remains a best practice — it reduces cross-browser inconsistencies and makes debugging easier. You simply cannot fail a WCAG 2.2 audit on 4.1.1 alone.

How Does WCAG 2.2 Compare to WCAG 2.1?

WCAG 2.2 is a superset of WCAG 2.1. Every criterion in 2.1 (except the deprecated 4.1.1) carries forward into 2.2 unchanged. Here is a summary of the differences:

| Aspect | WCAG 2.1 (June 2018) | WCAG 2.2 (October 2023) | |---|---|---| | Total criteria | 78 | 86 (78 - 1 deprecated + 9 new) | | New Level A criteria | — | 3.2.6, 3.3.7 | | New Level AA criteria | — | 2.4.11, 2.5.7, 2.5.8, 3.3.8 | | New Level AAA criteria | — | 2.4.12, 2.4.13, 3.3.9 | | Deprecated criteria | — | 4.1.1 Parsing | | Focus areas | Mobile, low vision, cognitive | Cognitive, authentication, focus visibility, motor |

The key theme of WCAG 2.2 is reducing cognitive burden and improving usability for people with cognitive and motor disabilities. WCAG 2.1 focused heavily on mobile accessibility and low-vision enhancements (like 1.4.10 Reflow and 1.4.13 Content on Hover or Focus). WCAG 2.2 shifts attention to authentication barriers, focus visibility, drag alternatives, and form re-entry — problems that affect a broad population.

When Should Organizations Transition to WCAG 2.2?

WCAG 2.2 became a W3C Recommendation on 5 October 2023. Since then, adoption has been accelerating:

Legal and procurement references are updating. The European Accessibility Act (EAA), which takes full effect in June 2025, references the harmonized standard EN 301 549, which is being updated to align with WCAG 2.2. Section 508 in the United States currently references WCAG 2.0 AA but the U.S. Access Board has signaled future updates. Organizations doing business internationally should target 2.2 now to stay ahead of regulatory changes.

If you are starting a new project, target WCAG 2.2 AA from day one. There is no reason to build against the older 2.1 standard when 2.2 is the current recommendation.

If you are maintaining an existing WCAG 2.1-compliant site, plan your transition over the next 6-12 months. The four new AA criteria (2.4.11, 2.5.7, 2.5.8, 3.3.8) are the only additions you need to address. Most sites find that 3.2.6 Consistent Help and 3.3.7 Redundant Entry (both Level A) are already satisfied if help placement and form design follow basic UX conventions.

If you publish VPATs or ACRs, update them to reference WCAG 2.2 and include the new criteria. Procurement reviewers increasingly expect the latest standard, and a VPAT referencing only WCAG 2.0 may raise questions about your commitment to accessibility.

How Does VPATify Test for WCAG 2.2 Criteria?

VPATify's accessibility scanner checks for WCAG 2.2 violations and maps every finding to a specific success criterion. Here is how the new 2.2 criteria are covered:

Automated detection — The scanner identifies potential 2.5.8 Target Size violations by measuring the computed dimensions of interactive elements and flagging any below 24x24 CSS pixels. It detects 3.2.6 Consistent Help patterns by comparing the DOM order of help-related elements across multiple pages during a full-site scan. It flags 3.3.7 Redundant Entry by analyzing multi-step form flows for repeated field labels without pre-fill attributes.

Guided manual checks — Some criteria require human judgment that no automated tool can fully replace. For 2.4.11 Focus Not Obscured, the scanner flags pages with sticky/fixed-position elements that overlap the viewport's scrollable area and recommends a manual keyboard walkthrough. For 3.3.8 Accessible Authentication, it detects CAPTCHA elements and flags them for review, noting whether alternative authentication paths exist.

VPAT mapping — Every finding maps directly to the relevant WCAG 2.2 criterion and conformance level. When you generate a VPAT from your scan results, the new 2.2 criteria are included automatically with per-criterion support status (Supports, Partially Supports, Does Not Support, Not Applicable).

Scan results include remediation guidance specific to each criterion — not just a generic "fix this issue" message, but concrete steps tied to the requirement. For example, a 2.5.7 finding will explain that the draggable component needs a single-pointer alternative and suggest implementation patterns.

Key Takeaways

WCAG 2.2 adds 9 criteria and deprecates 1. The additions focus on cognitive accessibility, focus visibility, motor accessibility, and authentication.
Four new AA criteria require attention if you already meet WCAG 2.1 AA: 2.4.11, 2.5.7, 2.5.8, and 3.3.8.
4.1.1 Parsing is deprecated — valid HTML is still best practice, but it is no longer a conformance requirement.
Transition now. WCAG 2.2 is the current W3C Recommendation and legal frameworks are updating to reference it.
Use automated scanning as a starting point — tools like VPATify catch target size, help consistency, and redundant entry issues, but focus visibility and authentication criteria require manual verification.

For the full specification, see the WCAG 2.2 W3C Recommendation. For a quick-reference view of all criteria, the WCAG 2.2 Quick Reference lets you filter by level and topic.