WCAG 2.2 for Developers: What Changed and What It Means

WCAG 2.2 was published by the W3C as an official recommendation in October 2023. It extends 2.1 with nine new or modified success criteria, removes one that was already redundant in practice, and quietly subsumes another into a stronger version. For developers working toward compliance — whether for legal reasons, procurement requirements, or genuine inclusion — the changes are meaningful and, in most cases, implementable without framework gymnastics.

This guide translates the spec language into what you actually need to build.

What Was Removed (and Why It Matters)

4.1.1 Parsing — Removed

The old 4.1.1 required valid, well-formed markup so that assistive technologies could reliably parse the DOM. When it was written (2008), browser behavior was less consistent, and screen readers had to parse raw HTML themselves. Today, browsers normalize malformed markup before handing a cleaned DOM to the accessibility tree. Assistive technologies consume that tree, not the raw source.

In WCAG 2.2, 4.1.1 is officially removed. The W3C published updated guidance making the criterion obsolete and setting it to “always satisfied” in 2.1 contexts for most content. If you’re maintaining a 2.1 audit checklist, you can note it as moot for modern browsers. If you’re auditing against 2.2 directly, it simply doesn’t exist.

2.4.7 Focus Visible — Absorbed

2.4.7 (Level AA) required that keyboard focus indicators be visible. It isn’t removed, but it’s effectively superseded. WCAG 2.2 introduces stricter focus appearance criteria (2.4.11 at AA) that set specific geometric requirements. A component satisfying 2.4.11 necessarily satisfies 2.4.7. Audits targeting 2.2 AA should test against 2.4.11 rather than 2.4.7 — 2.4.7 remains in the spec for backward compatibility, but it’s the floor, not the standard.

The Nine New Criteria

2.4.11 Focus Appearance (Minimum) — Level AA

This is the replacement for the vague old “focus visible” requirement. Rather than just requiring that focus be detectable, 2.4.11 defines a minimum geometric specification for focus indicators.

What it requires: The focus indicator must enclose the focused component (or its text). The indicator area must have at least a 3:1 contrast ratio against the unfocused state, and the focused area must cover an area at least as large as a 2 CSS pixel perimeter around the component. There’s a carve-out: if the unfocused component already has a sufficient contrast ratio of 3:1 against its surroundings, the contrast requirement for the focus change is relaxed.

Implementation notes: Browser default focus outlines often fail this criterion, particularly on buttons and links styled to remove the outline. Use outline rather than box-shadow where possible — outlines follow component geometry more reliably and are not clipped by overflow: hidden. A 2px solid outline with 3:1 contrast against the background (not the element itself) is a reasonable starting point:

:focus-visible {
  outline: 2px solid #005fcc;
  outline-offset: 2px;
}

Avoid removing outlines globally with outline: none on the * selector — this is still one of the most common causes of focus-visibility failures in production codebases.

2.4.12 Focus Appearance (Enhanced) — Level AAA

This is the stricter version of 2.4.11. It requires a higher-contrast focus area (at least 4.5:1) and mandates that the focus indicator not be fully enclosed by the component (i.e., it must be external or at least partially external).

Level AAA is not required for most compliance targets, but it sets a useful benchmark for design systems that want to go beyond minimum compliance. If your focus ring extends outward from the element boundary with high contrast, you’re likely meeting AAA.

2.4.13 Focus Appearance — Renumbering Note

The criteria numbering shifted during the drafting process. Earlier Working Drafts had a different numbering scheme. In the final published WCAG 2.2, the focus appearance criteria are 2.4.11 (AA) and 2.4.12 (AAA). If you’re referencing pre-publication documentation or draft audits, verify the criterion numbers against the final W3C recommendation.

2.5.7 Dragging Movements — Level AA

Some interfaces rely on drag operations — sliders, kanban boards, sortable lists, map panning. 2.5.7 requires that any functionality implemented via dragging also be operable via a single pointer without dragging. That means a click, tap, or press must be sufficient.

What it requires: Every dragging-based interaction must have an alternative that doesn’t require dragging. This applies to touch and mouse. A scrubber bar that can also be clicked to a position satisfies this. A sortable list that only supports drag-to-reorder does not.

Implementation notes: Adding keyboard support often solves this implicitly — if a user can reorder items with arrow keys after focusing a drag handle, you’ve provided a non-drag alternative. For pointer-only contexts, add click targets at relevant positions (e.g., up/down buttons alongside draggable rows). The criterion doesn’t prohibit drag — it requires an alternative.

Sliders (<input type="range">) are natively compliant as long as they respond to click-to-position. Custom slider implementations that only respond to pointermove events during a drag sequence are non-compliant.

2.5.8 Target Size (Minimum) — Level AA

Target size requirements have been a Level AAA criterion since 2.1 (2.5.5, requiring 44×44 CSS pixels). 2.5.8 introduces a lower-threshold AA requirement.

What it requires: Interactive targets must be at least 24×24 CSS pixels, with one important nuance: the criterion is about the target’s size or its offset from adjacent targets. If a target is smaller than 24×24, there must be sufficient spacing around it so the total “activation area” — the target plus its spacing — reaches 24×24. Inline text links are exempt.

Implementation notes: This primarily affects icon-only buttons, close buttons in modals, and small interactive elements in dense UIs. A 16×16 icon in a button is still compliant if the button itself has padding that brings the total clickable area to 24×24:

.icon-button {
  width: 24px;
  height: 24px;
  /* or padding the icon to reach 24px total */
  padding: 4px;
}

Note that 2.5.8 is more lenient than Apple’s Human Interface Guidelines (44pt minimum) and Google’s Material Design (48dp target). Meeting 2.5.8 alone does not guarantee good mobile usability — it’s a minimum, not a recommendation. The spacing offset calculation is explained in the Understanding document if you need to handle edge cases.

3.2.6 Consistent Help — Level A

If a help mechanism appears across multiple pages — a chat widget, a help link, a phone number, a self-service portal link — it must appear in a consistent location across those pages.

What it requires: Help mechanisms that repeat across a set of pages must appear in a consistent relative position. The mechanism doesn’t have to exist on every page, but when it does appear, it should be in the same place. This criterion is Level A, making it a baseline requirement rather than an enhancement.

Implementation notes: This is largely an information architecture and template concern rather than a component-level coding issue. If your layout puts a “Chat with us” widget in the lower-right on 40 pages but moves it to the footer on 10 others, that’s a 3.2.6 failure. Consistent placement is typically enforced at the layout or template level. Document the placement rule in your design system so it doesn’t drift. See also UI consistency patterns and layout components for design system approaches.

3.3.7 Redundant Entry — Level A

When a multi-step process asks a user to enter the same information more than once, the previously entered data must be auto-populated or made available for selection — unless re-entering is essential (e.g., confirming a password) or security requires it.

What it requires: Information entered in one step of a process must not need to be re-entered in a later step without auto-population or an option to select the previous entry.

Implementation notes: This surfaces most often in checkout flows, multi-page forms, and onboarding sequences. A billing address that defaults to the shipping address (with a checkbox) satisfies 3.3.7. A registration flow that asks for an email on step 1 and then again on step 4 does not. The fix is usually session storage or form state management — retain values across steps and inject them into subsequent fields.

For multi-page form libraries, confirm that your state management layer persists field values between route transitions. Frameworks like React with URL-parameter state or server-side session storage both work. The important thing is that the user isn’t penalized for the interface’s lack of memory.

3.3.8 Accessible Authentication (Minimum) — Level AA

Cognitive tests during authentication — solving puzzles, remembering passwords without help, transcribing distorted text — present barriers for users with cognitive disabilities. 3.3.8 requires that authentication not rely solely on a cognitive function test.

What it requires: Authentication steps that use a cognitive test must provide at least one of: a mechanism to assist the user (e.g., a password manager-compatible form), an alternative method that doesn’t require the cognitive test, or the cognitive test involves recognizing objects or identifying personally-provided content (e.g., “click the photo you uploaded”). CAPTCHAs that require transcription of distorted text are explicitly problematic under this criterion unless an alternative is available.

Implementation notes: The most common implementation failures are:

• CAPTCHA-only authentication with no audio or object-recognition alternative
• Password fields that block paste (preventing password manager use)
• Login flows that require a time-sensitive code without allowing copy-paste

Supporting paste in password fields is required — setting onpaste="return false" violates this criterion. Use autocomplete attributes correctly so password managers can fill credentials:

<input type="email" name="email" autocomplete="username" />
<input type="password" name="password" autocomplete="current-password" />

For CAPTCHA, consider hCaptcha’s accessibility mode, Cloudflare Turnstile (which replaces the challenge with behavioral analysis for most users), or object-recognition challenges. See form accessibility and autocomplete patterns for implementation depth.

3.3.9 Accessible Authentication (Enhanced) — Level AAA

This is the no-exceptions version of 3.3.8. Where 3.3.8 allows cognitive tests if objects or user-provided content are used, 3.3.9 removes even those exceptions. No cognitive function test is permitted in the authentication path.

What it requires: Authentication must be achievable without any cognitive test whatsoever. That means passkeys, magic links, and password-manager-compatible credential fields are the compliant path. The criterion accepts two-factor authentication as long as neither factor is a cognitive test (e.g., a hardware key or biometric is fine; a CAPTCHA is not).

Level AAA is aspirational for most production systems, but it points toward where authentication should be heading. Passkeys (the WebAuthn API) satisfy 3.3.9 entirely and are broadly supported as of 2024 across all major browsers and platforms.

Adoption and Legal Context

WCAG 2.2 is the basis for EN 301 549 v4, the European accessibility standard referenced by the European Accessibility Act (EAA). The EAA requires certain digital products and services to be accessible by June 2025. Procurement requirements in the EU, UK, and increasingly US federal contexts are beginning to reference 2.2 rather than 2.1.

For teams in the US, Section 508 currently references WCAG 2.0, but the ADA enforcement landscape has pushed courts and agencies toward 2.1 and now 2.2 as the practical standard. Auditing to 2.2 AA is a defensible baseline for most commercial web properties.

WCAG 3.0 is in active development and will introduce a substantially different conformance model (outcomes and measurements rather than binary pass/fail), but a stable recommendation is years away. WCAG 2.2 is the operative standard for the foreseeable future.

Audit Checklist Summary

For teams moving from 2.1 to 2.2 compliance, the incremental work is:

The W3C’s What’s New in WCAG 2.2 page is the canonical starting point for any team building a gap analysis between their 2.1 audit and 2.2 compliance.