WCAG 2.1 vs WCAG 2.2: What Changed and What It Means for Compliance

WCAG 2.1 vs WCAG 2.2: What Changed and What It Means

WCAG 2.2 was officially published by the W3C on October 5, 2023. As the latest version of the Web Content Accessibility Guidelines, understanding what changed — and what stayed the same — is essential for anyone working on digital accessibility compliance in 2026.

The good news: WCAG 2.2 is backwards compatible. If you conform to WCAG 2.2, you automatically conform to WCAG 2.1 and 2.0 at the same level. The European Accessibility Act currently mandates WCAG 2.1 Level AA, but EU standards bodies are actively tracking 2.2.

What Stayed the Same

WCAG 2.2 retains all success criteria from WCAG 2.1, with one exception (4.1.1 Parsing, which was removed). This means:

• All 50 WCAG 2.1 AA success criteria remain in 2.2
• The POUR framework (Perceivable, Operable, Understandable, Robust) is unchanged
• Conformance levels A, AA, and AAA remain the same
• Sites already conforming to WCAG 2.1 AA need only minimal additional work to meet 2.2

What's New in WCAG 2.2

2.4.11 Focus Appearance (Minimum) — Level AA

This new criterion requires that keyboard focus indicators be visible with a minimum size and contrast. Specifically, the focus indicator area must be at least as large as a 2px perimeter around the component and have a contrast ratio of at least 3:1 against adjacent colors.

Common fail: Outline-style focus indicators that are too thin or too low in contrast to be visible to users with low vision.

Fix: Use CSS to ensure focus styles have at least a 2px solid outline with 3:1 contrast against the background.

2.4.12 Focus Appearance (Enhanced) — Level AAA

A stricter version of 2.4.11 with higher contrast and size requirements.

2.4.13 Focus Appearance — Level AA (note: this was the original numbering)

The focus appearance requirement ensures that keyboard focus indicators are clearly visible to users who rely on keyboard navigation, particularly those with motor disabilities.

2.5.3 Label in Name — Clarified

Already in 2.1, but WCAG 2.2 clarified the requirement. The visible label for a control must be included in its accessible name. This ensures voice control users can activate controls by saying what they see on screen.

2.5.7 Dragging Movements — Level AA

Any functionality that can be operated by dragging must also be operable with a single pointer without dragging. This is critical for users with motor disabilities who cannot perform precise drag operations.

Common fail: Drag-to-reorder lists, sliders that require dragging, kanban boards.
Fix: Provide a keyboard alternative or a simple click/tap mechanism for the same functionality.

2.5.8 Target Size (Minimum) — Level AA

Interactive targets (buttons, links, form controls) must be at least 24x24 CSS pixels in size, or have sufficient spacing. This helps users with motor impairments who have difficulty clicking small targets.

Common fail: Small icon buttons, densely-packed navigation links, tiny checkboxes.
Fix: Ensure touch/click targets are at least 24x24px, or add padding to increase the effective clickable area.

3.2.6 Consistent Help — Level A

If a web page provides mechanisms for requesting help (help links, chat support, phone numbers), they must appear in a consistent location across pages within the same web presence.

Common fail: Help links appearing in different places on different pages of the same site.
Fix: Place help mechanisms in a consistent location — typically the header or footer.

3.3.7 Redundant Entry — Level A

When completing a multi-step process, information previously entered should not need to be re-entered unless it's for security reasons or the previous information is no longer valid.

Common fail: Multi-step checkout forms that ask for the same information twice.
Fix: Pre-fill information already provided. Offer auto-complete for repeated fields.

3.3.8 Accessible Authentication (Minimum) — Level AA

If a cognitive function test is required for authentication (like solving a puzzle, recognizing an image, or transcribing text), an alternative must be available unless it provides a security purpose that cannot be achieved another way.

Common fail: CAPTCHAs that require image recognition with no audio alternative.
Fix: Provide an audio CAPTCHA, or better yet, use more modern authentication approaches that don't rely on cognitive tests.

4.1.1 Parsing — Removed

WCAG 2.1's 4.1.1 Parsing criterion, which required HTML to be well-formed, was removed in 2.2. Modern browsers handle malformed HTML gracefully enough that this criterion was no longer useful in practice.

WCAG 2.2 and the EAA

The European Accessibility Act references EN 301 549, which in turn references WCAG 2.1 Level AA. As of 2026, WCAG 2.2 is not yet formally required by the EAA. However:

• EN 301 549 is being updated to reference WCAG 2.2
• Several EU national standards bodies recommend targeting 2.2 proactively
• The new criteria in 2.2 represent genuine accessibility improvements, particularly for motor-impaired users

EAAPass audits against WCAG 2.1 AA as required by the EAA, and we track 2.2 criteria as advisory recommendations. Run your free audit at eaapass.eu.

Summary: Should You Target 2.1 or 2.2?

For EU legal compliance: WCAG 2.1 AA. For future-proofing and best practice: WCAG 2.2 AA. The additional effort to meet 2.2 beyond 2.1 is relatively small — mainly focusing on focus indicators, minimum target sizes, and the new interaction criteria. We recommend targeting 2.2 now so you don't need to revisit this when EU standards catch up.