WCAG 2.2 New & Removed Criteria

The full lesson

WCAG 2.2 became a W3C Recommendation in October 2023. It closes gaps that practitioners had felt since WCAG 2.1 shipped in 2018. The update adds nine new success criteria, removes one outdated criterion, and sharpens a few existing definitions. The changes touch keyboard interaction, mobile touch targets, cognitive load during authentication, and focus behavior inside sticky headers.

If your team is still targeting WCAG 2.0 or treating 2.1 as the ceiling, you are behind the legal baseline in most jurisdictions — and behind the real needs of the users you are failing.

What Changed and Why It Matters

WCAG revisions respond to real failure modes: actual users, real assistive technologies, and real products that pass automated audits while still shutting people out. The 2.2 additions fall into three themes:

1. Keyboard and focus interaction — sticky headers and cookie banners were hiding focused elements behind fixed overlays, leaving keyboard users unable to see where they were on the page.
2. Cognitive and authentication barriers — CAPTCHAs and forms that demand repeated input create avoidable cognitive load, especially for users with memory or processing differences.
3. Mobile and pointer precision — touch targets sized for a designer’s young finger were excluding users with motor disabilities, tremors, or older devices.

Understanding the why behind each criterion helps you apply it beyond the letter of the rule.

New Criteria at a Glance

Success Criterion	Level	Theme	The Core Ask
2.4.11 Focus Not Obscured (Minimum)	AA	Focus	Focused component must not be entirely hidden by sticky content
2.4.12 Focus Not Obscured (Enhanced)	AAA	Focus	Focused component must be fully visible
2.4.13 Focus Appearance	AAA	Focus	Focus indicator meets area and contrast thresholds
2.5.7 Dragging Movements	AA	Pointer	All drag operations have a single-pointer alternative
2.5.8 Target Size (Minimum)	AA	Pointer	Touch targets at least 24×24 CSS pixels
3.2.6 Consistent Help	AA	Predictability	Help mechanisms appear in the same location across pages
3.3.7 Redundant Entry	AA	Cognitive	Previously entered info is auto-populated or available to select
3.3.8 Accessible Authentication (Minimum)	AA	Cognitive	No cognitive function test required to authenticate
3.3.9 Accessible Authentication (Enhanced)	AAA	Cognitive	No cognitive function test at all, including images of objects

Focus Not Obscured: 2.4.11 and 2.4.12

Here is the problem: sticky navigation bars, cookie consent banners, chat widgets, and fixed footers are everywhere. When a keyboard user tabs to a focusable element that sits underneath one of these sticky layers, the element receives focus — but the user cannot see it. The visual focus indicator is hidden behind the overlay. From the user’s perspective, focus has vanished.

2.4.11 (AA) requires that no focused component is entirely obscured by author-created content. Partial obscuring is allowed at AA. This is deliberately practical: fixing “entirely hidden” is straightforward. Requiring zero overlap would force layout changes across a huge number of existing interfaces.

2.4.12 (AAA) raises the bar. The focused element must not be obscured at all.

Implementation approaches

• Use scroll-margin-top (or scroll-padding-top on a scroll container) to create a buffer that accounts for the height of fixed headers. When a focused element scrolls into view, the browser automatically offsets it.
• Test by tabbing through a long page with a sticky header visible. If you ever lose the focus ring, you have a 2.4.11 failure.
• The inert attribute is the modern replacement for tabindex hacks when you need to remove content from the focus order temporarily — for example, an off-canvas navigation panel. Manually setting tabindex="-1" on every child element of a menu is error-prone and fragile.

/* Compensate for a 64px sticky header */
:target,
:focus {
  scroll-margin-top: 80px;
}

Focus Appearance: 2.4.13

WCAG 2.1 required a visible focus indicator but said almost nothing about how good it had to be. 2.4.13 (AAA) defines minimum perceptual thresholds:

• The focus indicator must enclose the focused component.
• It must have a minimum area equal to a 2 CSS pixel perimeter around the unfocused component.
• It must have a contrast ratio of at least 3:1 between the focused and unfocused states.
• If the indicator is a filled region that changes color, the fill must not reduce contrast with adjacent colors below 3:1.

This is an AAA criterion, but it is a useful engineering target even at AA. Browser defaults consistently fail this threshold on many backgrounds. Designing custom focus indicators is the pragmatic move.

Dragging Movements: 2.5.7

Drag-to-reorder, drag-to-pan a map, drag a slider thumb, drag to connect nodes in a diagram — these all create a barrier for users who cannot execute precise click-and-hold-and-move actions. 2.5.7 (AA) requires that every drag operation is also achievable with a single pointer action: a tap or a click, with no dragging needed.

Practical patterns:

• Sortable lists: provide “Move up” / “Move down” buttons alongside the drag handle, or a keyboard-accessible reorder mode where arrow keys change position.
• Map panning: support click-to-center or keyboard arrow navigation as an alternative to click-drag.
• Range sliders: the thumb must be controllable by arrow keys. This is also a Level A requirement under 2.1.1 (Keyboard), so if you have a custom slider without keyboard support, that was already a gap.
• Canvas-based drawing tools: provide a toolbar-driven mode that applies shapes via single clicks.

Target Size (Minimum): 2.5.8

2.5.8 (AA) requires that interactive targets are at least 24×24 CSS pixels. There is an important nuance: if the visible target is smaller than 24×24, its offset — the spacing around it before the next interactive element — can fill the gap to 24px. Two adjacent targets cannot both share the same buffer area.

Compare this to the existing 2.5.5 (AAA), which requires 44×44 CSS pixels with no offset exception. The 2.5.8 minimum is achievable in dense interfaces like toolbars and data tables, while 2.5.5 remains the gold standard.

Criterion	Level	Requirement	Offset counts?
2.5.5 Target Size	AAA	44×44 CSS px	No
2.5.8 Target Size (Minimum)	AA	24×24 CSS px	Yes — offset from adjacent targets

Exceptions in 2.5.8: inline text links (where target size follows line height and content flow), targets whose size is essential (such as a piano keyboard where key width carries meaning), and browser-native controls.

The lesson for product design: give icon buttons a 40–44px hit area minimum, even if the visible icon is only 20px. Use padding rather than enlarging the visible element. This practice predates 2.5.8 — Apple’s Human Interface Guidelines and Google’s Material Design have both recommended it since their early versions.

Consistent Help: 3.2.6

If your product has a help mechanism — a contact link, a live chat button, a ”?” tooltip, a support phone number — and it appears on more than one page, it must appear in the same relative location on each page. Consistent Help (AA) follows the logic of 3.2.3 (Consistent Navigation). Users build a mental map of where help lives. Breaking that map causes disorientation, especially for users with cognitive disabilities.

“Same relative location” means the same position in the page template, not pixel-identical placement. A help link in the footer is fine. A help link in the footer on some pages and the header on others is not.

Redundant Entry: 3.3.7

Multi-step flows that ask users to re-enter information they already provided — name, address, email — add cognitive and motor load with no benefit to the user. 3.3.7 (AA) requires that previously entered information is either:

• Auto-populated in the field where it is needed again, or
• Available for the user to select from a list, so they can confirm rather than retype.

Re-entry is acceptable when it serves a real purpose, like confirming a password or preventing accidental duplication. This criterion directly targets checkout flows that ask for billing information identical to shipping information but offer no “same as shipping” checkbox, and forms that ask for date of birth in one step and age in another.

From a cognitive load perspective, this criterion codifies what good UX designers were already doing: don’t make users remember and repeat themselves.

Accessible Authentication: 3.3.8 and 3.3.9

This criterion has the most direct impact on login and registration flows.

3.3.8 (AA) prohibits cognitive function tests as the sole way to complete an authentication step, unless:

• An alternative is provided that does not rely on a cognitive function test, or
• An assistive mechanism — copy-paste, a password manager, autofill — is available to help complete the test.

A cognitive function test is any task that requires the user to remember, transcribe, or calculate something. Classic CAPTCHAs that ask you to transcribe distorted text are the most obvious target. So are authentication flows that deliberately disable paste in password fields. That practice frustrates password manager users and directly conflicts with this criterion.

3.3.9 (AAA) goes further. It eliminates even image-based object recognition tests — the “click all the traffic lights” CAPTCHA — regardless of whether alternatives exist.

Compliant authentication designs:

• Magic links or passkeys with no transcription required.
• Biometric authentication (fingerprint, face ID) as an alternative.
• CAPTCHA with an audio alternative — still compliant at AA because the audio track provides the alternative, though AAA requires eliminating the CAPTCHA entirely.
• Email or SMS OTP where the user can copy-paste the code from their notification — compliant because copy-paste is the assistive mechanism.

The Removed Criterion: 4.1.1 Parsing

WCAG 2.2 officially removed 4.1.1 Parsing. This criterion required that HTML be free of duplicate IDs, properly nested elements, and correctly matched opening and closing tags. It was written in 2008, when browser behavior for malformed markup was wildly inconsistent and could cause assistive technologies to misread the accessibility tree.

Modern browsers now standardize their HTML parsing engines to recover gracefully from most markup errors. More importantly, assistive technologies interact with the post-parse browser DOM and accessibility tree — not the raw HTML source. A duplicate id attribute still creates real problems (it breaks aria-labelledby and for/id label associations), but that is now addressed under 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value).

What this means in practice

Stop: auditing specifically for 4.1.1 Parsing violations and treating all HTML validation errors as accessibility failures. A W3C validation error is not automatically an accessibility failure.

Continue: validating HTML, because correct markup makes aria-labelledby, for/id associations, and heading hierarchy work correctly. The quality rationale stands — only the WCAG criterion has been removed.

Putting It All Together: An Audit Checklist

Here is how to translate nine new criteria into a practical design review.

Focus and keyboard (2.4.11, 2.4.12, 2.4.13)

• Tab through every page with a fixed header or sticky element. No element should be entirely obscured when it receives focus.
• Verify custom focus indicators meet 3:1 contrast against both the focused component and the background.
• Replace all tabindex workarounds for modal/drawer focus trapping with the inert attribute.

Pointer and touch (2.5.7, 2.5.8)

• Audit icon-only buttons and toolbar controls for a 24×24 CSS pixel minimum target area, including offset.
• Identify every drag-only interaction and provide a single-pointer or keyboard alternative.

Cognitive and form (3.2.6, 3.3.7, 3.3.8)

• Audit multi-step forms for re-entered fields. Add auto-population or “same as above” affordances.
• Verify all help UI appears in the same location across page templates.
• Remove paste-blocking from password and code fields. Audit login flows for CAPTCHA types.

Removed criterion (4.1.1)

• Update your accessibility criteria documentation and team training to reflect 4.1.1 removal.
• Keep HTML validation in your CI pipeline for code quality — not as a WCAG enforcement mechanism.