What's New in WCAG 2.2

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 (like an icon), padding extends the interactive area to meet the minimum.
A row of small icon buttons where each icon is 20x20 pixels but has 4px of spacing on each side (the spacing counts toward meeting the requirement if there is no adjacent target in that space).

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.
Checkbox or radio inputs at their browser default size (often 13x13 pixels) with no additional interactive area provided.

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

Authentication processes must not require users to perform a cognitive function test — such as memorizing a password, solving a puzzle, or performing arithmetic — unless the system provides at least one of the following alternatives:

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”).

The key practical implication is: never block paste in password fields. If users can paste, their password manager handles the cognitive burden and the criterion is met. Similarly, supporting browser autofill and third-party credential managers satisfies this requirement.

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 or one-time code to the user’s email or phone.
A CAPTCHA that uses image recognition (“select all traffic lights”) alongside an audio alternative.

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: The simplest fix is to ensure autocomplete attributes are correctly set on your login form fields and that you never prevent pasting. This allows password managers and browser autofill to handle authentication without requiring the user to remember anything.

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 browsers and assistive technologies have become exceptionally robust at handling malformed HTML. Every major browser engine uses the same HTML5 parsing algorithm, which defines exactly how to handle every type of markup error. Screen readers read the browser’s parsed DOM and accessibility tree, not the raw source code. As a result, HTML validity issues that would have caused real problems in 2008 are silently corrected by browsers today.

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, or provide assistive mechanism	Password Show/Hide
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