What's New in WCAG 2.2

A practical guide to the 9 new success criteria in WCAG 2.2, with links to relevant examples

Maintained by Martin KrugerLast reviewed August 8, 2026

Overview

WCAG 2.2 became a W3C Recommendation on 5 October 2023, the first update to the Web Content Accessibility Guidelines since WCAG 2.1 in 2018. It adds 9 new success criteria and removes 1 (4.1.1 Parsing). All of the new criteria address common real-world barriers that existing guidelines did not adequately cover — particularly around focus visibility, touch target sizing, cognitive load during authentication, and drag-based interactions.

The criteria are spread across three conformance levels:

Level	New Criteria
A	3.2.6 Consistent Help, 3.3.7 Redundant Entry
AA	2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.3.8 Accessible Authentication (Minimum)
AAA	2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 3.3.9 Accessible Authentication (Enhanced)

If your organization targets WCAG 2.2 Level AA compliance (the most common target for legal and policy requirements), you need to address the 6 criteria at Level A and AA. The 3 AAA criteria are recommended best practices but not typically required.

New Success Criteria

2.4.11 Focus Not Obscured (Minimum) — Level AA

When a keyboard user tabs to an interactive element, that element must not be entirely hidden behind other content. This criterion targets a widespread problem: sticky headers, cookie banners, floating chat widgets, and fixed-position footers that cover the focused element so the user cannot see where they are on the page.

What passes:

A sticky navigation bar partially overlaps a focused link, but at least part of the focused element and its focus indicator remain visible.
A cookie consent banner is dismissed or repositioned when it would cover the currently focused element.
Scroll padding (scroll-padding-top in CSS) is used so that elements scrolled into view by anchor links or focus() calls appear below a fixed header.

What fails:

A chat widget floats over the bottom-right corner and completely covers a “Submit” button when the user tabs to it, with no way to see or tell that the button has focus.
A sticky footer banner fully obscures focused links in the page content behind it.

Practical tip: Add scroll-padding-top and scroll-padding-bottom to your <html> element equal to the height of your sticky header and footer. This single CSS property solves the most common violations.

2.4.12 Focus Not Obscured (Enhanced) — Level AAA

This is the stricter version of 2.4.11. At the Enhanced level, no part of the focused element may be hidden by author-created content. Where the Minimum criterion allows partial obscuring, this criterion requires that the focused component is fully visible — not covered at all.

What passes:

All sticky and fixed-position elements are designed so they never overlap with any focusable element in any scroll position, or they dynamically reposition when focus moves near them.

What fails:

A sticky header partially covers a focused element. (This passes 2.4.11 but fails 2.4.12.)

This is a AAA criterion, so it is not typically required. However, aiming for it produces a noticeably better experience for all keyboard users.

2.4.13 Focus Appearance — Level AAA

When an element receives keyboard focus, the focus indicator must meet minimum size and contrast requirements. Specifically, the focus indicator area must be at least as large as a 2 CSS pixel thick perimeter around the element, and it must have a contrast ratio of at least 3:1 between its focused and unfocused states.

What passes:

A 2px solid outline with a color that has at least 3:1 contrast against both the background and the unfocused state of the element.
A thick underline or background color change that covers enough area and provides sufficient contrast.

What fails:

A 1px dotted outline in a low-contrast color (the default in some browsers).
A focus indicator that relies solely on a subtle box-shadow with poor contrast.
Removing the default focus indicator (outline: none) and providing no replacement.

Practical tip: A 2px solid outline using a bold color that contrasts with your page background is usually the simplest way to meet this criterion. Many design systems use a combination of outline and outline-offset for a clean look that satisfies the requirements.

2.5.7 Dragging Movements — Level AA

Any functionality that uses dragging (click-hold-move-release) must also be operable with a single pointer action that does not require dragging — for example, tapping or clicking individual points.

This criterion matters because dragging requires fine motor control and sustained pointer contact, which many users cannot perform. People with hand tremors, limited dexterity, or those using head pointers, mouth sticks, or eye-tracking cannot reliably drag.

What passes:

A sortable list that supports drag-and-drop reordering and also provides “Move up” / “Move down” buttons for each item.
A slider that can be dragged and also allows clicking at a specific point on the track to set the value, or provides increment/decrement buttons.
A kanban board with drag-and-drop columns that also offers a dropdown menu on each card with “Move to [Column]” options.

What fails:

A file upload area where the only way to reorder uploaded files is by dragging them, with no alternative.
A map widget that can only be panned by dragging, with no keyboard or button-based navigation.
A slider that only responds to drag gestures and has no click-to-set or arrow key support.

See also: Drag & Drop | Sliders & Ratings

2.5.8 Target Size (Minimum) — Level AA

Interactive targets must be at least 24 by 24 CSS pixels in size, unless one of several exceptions applies (the target is inline text, the user agent controls its size, the target has an equivalent larger target elsewhere, or sufficient spacing makes up the difference).

Small touch and click targets are one of the most common usability and accessibility failures on the web. They disproportionately affect people with motor impairments, older adults, and anyone using a mobile device in a bumpy environment.

What passes:

Buttons and links with a minimum clickable area of 24x24 CSS pixels. Even if the visible element is smaller, padding can extend the interactive area.
A smaller target whose surrounding spacing is sufficient: a 24 CSS pixel diameter circle centered on the target’s bounding box does not intersect another target or another undersized target’s circle.

What fails:

A compact toolbar with 16x16 pixel icon buttons placed directly adjacent to each other with no spacing.
A set of tightly packed pagination links at 12px font size with minimal padding.
A custom 16x16 checkbox whose only clickable area is tightly packed beside other undersized targets. Native user-agent controls have an exception when their size is not modified by the author; a correctly associated label also enlarges the clickable target.

Practical tip: Set a minimum min-height and min-width of 24px on all interactive elements, or use padding to extend the tap target. For inline links within paragraphs of text, the exception applies — you do not need to make every word-link 24px tall.

3.2.6 Consistent Help — Level A

If a website provides help mechanisms — such as contact information, a help chat, a FAQ link, or a self-help option — those mechanisms must appear in the same relative order on every page where they exist. The criterion does not require you to provide help. It requires that whatever help you do provide is consistently located.

What passes:

A footer on every page that always contains, in the same order: a “Help Center” link, a “Contact Us” link, and a phone number.
A floating help chat button that always appears in the bottom-right corner of every page.
A support page link that always appears as the last item in the main navigation on every page where it is present.

What fails:

A “Contact Us” link that appears in the header on the homepage, in the footer on product pages, and in a sidebar on the checkout page.
A help phone number that appears before the FAQ link on some pages and after it on others.

Practical tip: Put all help mechanisms in a shared layout component (like a global footer or header) so they are automatically consistent across pages. This is typically already the case in well-structured applications.

3.3.7 Redundant Entry — Level A

When a user has already provided information in a multi-step process, the system must not ask them to re-enter that same information in a later step. Instead, the information should be auto-populated, available for selection, or otherwise not required a second time. Exceptions exist when re-entry is essential for security (like confirming a password or email) or when previously entered data is no longer valid.

This criterion reduces cognitive load and effort, particularly for users with memory difficulties, motor impairments (who find typing effortful), and anyone filling out long forms.

What passes:

A checkout flow that asks for a billing address and then auto-populates the shipping address with the same values, allowing the user to change it if needed.
A multi-step application form that carries forward the user’s name, email, and phone number from step 1 to later steps where it is needed again.
A “same as above” checkbox that copies previously entered data to a second set of fields.

What fails:

A two-page form where the user enters their name and address on page 1, and page 2 asks them to type the same name and address again for a different purpose.
A booking system that asks for passenger details on one page and then asks the user to retype those details on a confirmation page.

3.3.8 Accessible Authentication (Minimum) — Level AA

For each step in an authentication process, users must not be required to perform a cognitive function test — such as memorizing a password, solving a puzzle, or transcribing content — unless an allowed alternative, assistance mechanism, or exception applies:

Another method that does not rely on a cognitive function test (such as a passkey, security key, or email magic link).
A mechanism to assist the user (such as allowing paste into password fields so password managers work, or supporting autofill).
Object recognition or personal content identification is allowed at the Minimum level (such as “select all images with traffic lights”).

Do not block paste, and use correct autocomplete tokens so password managers and browser autofill can work. Those mechanisms can satisfy a password-entry step, but conformance is evaluated across the complete authentication flow: a later CAPTCHA or forced memory challenge can still fail.

What passes:

A login form that allows pasting into both the username and password fields, enabling password manager use.
A login form that supports WebAuthn / passkeys as an alternative to password entry.
An authentication flow that sends a magic link, provided the link does not lead to another required cognitive test.
An image-recognition challenge at Level AA only where object recognition is the cognitive test; an audio transcription is not automatically an equivalent accessible solution.

What fails:

A login form with autocomplete="off" on the password field and JavaScript that blocks paste events, forcing users to manually type their password from memory.
A CAPTCHA that requires transcribing distorted text with no alternative method.
A custom PIN entry using individual single-digit fields that break autofill and paste functionality.

Practical tip: Map every step in sign-in, account recovery, and multi-factor authentication. Support password managers, paste, and autocomplete; offer a non-cognitive route such as a passkey; and verify that no later step reintroduces a prohibited test.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

This is the stricter version of 3.3.8. At the Enhanced level, object recognition and personal content identification are no longer acceptable as cognitive function tests. This means image-based CAPTCHAs (“select all traffic lights”) fail this criterion even though they pass 3.3.8.

What passes:

A login form with paste support and password manager compatibility (no cognitive test at all).
WebAuthn / passkey authentication.
Email magic links or one-time codes sent to a registered device.
A CAPTCHA alternative that uses a checkbox (“I am not a robot”) backed by behavioral analysis rather than a visual or cognitive puzzle.

What fails:

An image selection CAPTCHA as the only authentication verification step with no alternative.
A security question like “What is the name of your first pet?” (requires recall of personal content).

This is a AAA criterion and not typically required, but designing authentication without cognitive tests benefits all users — especially those with cognitive disabilities, memory impairments, and older adults.

Removed Criterion

4.1.1 Parsing — Removed

WCAG 2.0 and 2.1 included 4.1.1 Parsing, which required that HTML content have no significant parsing errors — elements had to have complete start and end tags, be nested correctly, not contain duplicate attributes, and have unique IDs.

Why it was removed: Modern HTML defines parsing and error-recovery rules, and assistive technologies consume the browser’s resulting DOM and accessibility tree rather than raw source. This does not mean every browser and assistive-technology combination produces identical results, or that malformed markup is harmless.

This does not mean HTML quality doesn’t matter. Duplicate IDs can still break aria-labelledby references, label associations, and JavaScript functionality. Malformed markup can still cause unexpected layouts. The removal simply means that HTML parsing errors are no longer a WCAG conformance failure in their own right — they are addressed by other criteria (like 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value) when they cause actual accessibility problems.

Practical tip: Continue using an HTML validator and linting tools. Clean markup is easier to maintain, debug, and make accessible. The removal of 4.1.1 just means you no longer need to claim every validation warning is an accessibility violation.

Summary Table

Criterion	Level	Key Requirement	Related Example
2.4.11 Focus Not Obscured (Minimum)	AA	Focused element not entirely hidden by sticky/fixed content	Focus Indicators
2.4.12 Focus Not Obscured (Enhanced)	AAA	Focused element fully visible, no partial obscuring	Focus Indicators
2.4.13 Focus Appearance	AAA	Focus indicator meets minimum size and contrast	Focus Indicators
2.5.7 Dragging Movements	AA	Single-pointer alternative for all drag operations	Drag & Drop, Sliders & Ratings
2.5.8 Target Size (Minimum)	AA	Interactive targets at least 24x24 CSS pixels	Target Sizing
3.2.6 Consistent Help	A	Help mechanisms in same relative order across pages	—
3.3.7 Redundant Entry	A	Don’t ask users to re-enter previously provided info	Multi-Step Forms
3.3.8 Accessible Authentication (Minimum)	AA	No cognitive function tests unless an alternative, assistance, or exception applies	Accessible Authentication
3.3.9 Accessible Authentication (Enhanced)	AAA	No object recognition or personal content tests	Password Show/Hide
4.1.1 Parsing	Removed	Previously required valid HTML; now handled by browsers	—

Resources

WCAG 2.2 Specification — the full normative text
What’s New in WCAG 2.2 (W3C) — official summary of changes
Understanding WCAG 2.2 — detailed explanations and intent for each criterion
WCAG 2.2 Quick Reference — filterable list of all criteria with techniques and failures
WebAIM WCAG 2.2 Checklist — practical checklist format