WCAG 2.2 · React··8 min read

WCAG 2.2: The 9 New Criteria Developers Need to Know

WCAG 2.2 was published in October 2023 and is now the mandatory reference for RGAA 4.1.2 in France, EN 301 549 v3.2.1 in the EU, and the European Accessibility Act (EAA 2025). It introduced 9 new success criteria — some at Level A, most at Level AA — that directly affect how you build React components.

This article covers each criterion, what it means in practice, and the concrete impact on your component architecture.

What changed in WCAG 2.2

WCAG 2.2 adds 9 success criteria and removes one (4.1.1 Parsing, now considered obsolete for modern HTML). The new criteria focus on three areas: keyboard focus visibility, pointer and touch interactions, and authentication/form usability. All 9 are relevant to React component authors.

The 9 new criteria

2.4.11AAFocus Not Obscured (Minimum)

When a UI component receives keyboard focus, it must not be entirely hidden by author-created content such as sticky headers or cookie banners.

React impact

Your sticky navigation must account for scroll padding. Use CSS `scroll-margin-top` or `scroll-padding-top` on the root to ensure focused elements remain visible.

2.4.12AAAFocus Not Obscured (Enhanced)

Enhanced version of 2.4.11: no part of the focused component is hidden by author content. AAA level but signals best practice intent.

React impact

Aim for full visibility rather than just avoiding complete obscurance. Test with your actual sticky headers and modals.

2.4.13AAFocus Appearance

The keyboard focus indicator must meet minimum area and contrast requirements: at least a 2px perimeter, and a contrast ratio of 3:1 between focused and unfocused states.

React impact

Custom focus styles are now required. `outline: none` without a replacement violates this criterion. Design a visible focus ring that meets the 2px + 3:1 threshold.

2.5.7AADragging Movements

All functionality that uses dragging must also be achievable with a single pointer without dragging (e.g., click or tap).

React impact

Drag-and-drop components (sortable lists, kanban, sliders) must provide click/keyboard alternatives. For sliders, arrow key support is mandatory.

2.5.8AATarget Size (Minimum)

Interactive targets must be at least 24×24 CSS pixels, unless spacing between targets offsets the difference.

React impact

Icon buttons, checkboxes, and close buttons often fall below this threshold. Add `min-h-6 min-w-6` (24px) to all interactive elements, or better yet 44×44px for comfortable touch targets.

3.2.6AAConsistent Help

If a help mechanism (contact form, live chat, phone) appears on multiple pages, it must appear in the same relative order.

React impact

Ensure help links/widgets in your layout component (header or footer) maintain consistent position across all pages.

3.3.7ARedundant Entry

Information previously provided within the same process must not be requested again, unless re-entering is essential or for security purposes.

React impact

Multi-step forms must pre-fill known values. Store user data across form steps and auto-populate fields (shipping = billing address, etc.).

3.3.8AAAccessible Authentication (Minimum)

Authentication must not rely solely on cognitive function tests (puzzles, CAPTCHAs) unless an alternative is provided.

React impact

Standard text CAPTCHAs in login forms may violate this. Use alternatives: email magic links, passkeys, or audio CAPTCHA. Ensure copy-paste is enabled on OTP fields.

3.3.9AAAAccessible Authentication (Enhanced)

Enhanced version: no cognitive function test at all in the authentication process.

React impact

AAA level, but the direction is clear: move toward passkeys and magic links as your primary auth mechanisms.

Konform covers these criteria for you

Every Konform component ships with per-criterion audit documentation covering WCAG 2.2 AA, RGAA 4.1.2, and EN 301 549 v3.2.1. Instead of auditing each criterion yourself, you get documented compliance coverage with every component.

Related articles

Apply WCAG 2.2 changes to your component system