What's New in WCAG 2.2: 9 New Success Criteria Explained

WCAG 2.2 adds nine success criteria covering focus visibility, pointer interaction, help, forms, and authentication. Six are at Level A or AA; three are AAA. For teams maintaining a WCAG 2.1 AA product, the immediate task is to test the six additions without dropping existing requirements.

Establish the baseline before changing components

Start with a component inventory, not a redesign. Identify sticky headers, cookie banners, draggable controls, compact buttons, support links, repeated form fields, and sign-in flows. These are the places where the additions most often change implementation decisions.

Use the contrast checker to compare focus-ring colors against adjacent surfaces while reviewing focus states. It supports one part of that review; a passing ratio cannot prove that focus remains visible when a banner or sticky footer appears. The broader accessible interface guide provides context for requirements carried forward from earlier versions.

Read the normative WCAG 2.2 recommendation alongside implementation advice. Conformance levels accumulate: AA includes every applicable A and AA requirement, not just the criteria introduced in this version. WCAG 2.2 also removes 4.1.1 Parsing; semantic correctness and accessible names still matter under other criteria.

Focus visibility: distinguish AA from AAA

2.4.11 Focus Not Obscured (Minimum), AA, requires that a keyboard-focused component is not entirely hidden by author-created content. A sticky navigation bar must not completely cover a link reached with Tab. Partial obstruction can still pass this minimum, although it can remain frustrating.

2.4.12 Focus Not Obscured (Enhanced), AAA, raises the requirement: no part of the focused component may be hidden by author-created content. Test with expanded banners, open panels, and different viewport heights, not only the default page state. Where users can reposition content, the criterion considers its initial position; user-opened content also has specific provisions for revealing focus without advancing it.

2.4.13 Focus Appearance, AAA, concerns the focus indicator itself. Subject to its exceptions, the indicator needs an area at least equivalent to a two-CSS-pixel perimeter of the unfocused component, and a 3:1 contrast change between the same pixels in focused and unfocused states. This is not simply a rule that every outline needs 3:1 against its background.

A practical starting point is an explicit outline plus room for browser scrolling:

:root {
scroll-padding-block-start: 5rem;
scroll-padding-block-end: 6rem;
}

:focus-visible {
outline: 3px solid #123b75;
outline-offset: 3px;
}

main :is(a, button, input, select, textarea) {
scroll-margin-block: 1rem;
}

This is a candidate implementation, not automatic compliance. Check the outline on every surface, including dark panels, and adjust scroll padding for actual overlays. Do not remove native focus indicators unless the replacement is demonstrably usable. Test programmatic focus after validation as well as ordinary tabbing.

Pointer interaction: dragging and target size

2.5.7 Dragging Movements, AA, requires a single-pointer alternative that does not involve dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author. Keyboard support alone does not satisfy this pointer-specific requirement.

For a sortable list, provide Move up and Move down buttons or a menu that chooses a destination. For a map, consider buttons or selectable destinations that provide the same functionality without a sustained drag. Confirm that the alternative remains available on touch devices rather than appearing only on hover.

2.5.8 Target Size (Minimum), AA, sets a 24 by 24 CSS pixel minimum for pointer targets, with exceptions. An undersized target can qualify through spacing if a 24-CSS-pixel-diameter circle centered on its bounding box intersects neither another target nor the equivalent circle around another undersized target.

Other exceptions cover equivalent controls, inline targets, unmodified user-agent controls, and essential presentation. Read the precise target-size explanation before treating an entire toolbar as exempt. A small icon can sit inside a large button; measure the interactive rectangle rather than the painted glyph.

Prefer comfortable target sizes over exception-driven layouts. A 44-pixel button is often a useful design starting point, but that value belongs to the separate AAA enhanced target-size criterion, with its own conditions. It is not the new AA threshold.

Help and repeated information in workflows

3.2.6 Consistent Help, A, applies when pages in a set contain specified help mechanisms: human contact details, a human contact mechanism, a self-help option, or a fully automated contact mechanism. Their order relative to other page content must stay consistent unless the user initiates a change.

This does not require every site to add live chat. It asks teams to stop moving available help unpredictably between pages. Review desktop and mobile presentations separately where responsive layouts legitimately differ. Look particularly at checkout steps that use different templates and accidentally move support into unrelated menus.

3.3.7 Redundant Entry, A, requires information already entered by, or provided to, the user in the same process to be auto-populated or available for selection when needed again. Exceptions include essential re-entry, security needs, or information that is no longer valid.

A shipping-to-billing checkbox is one implementation. A selectable address summary is another. Do not require memory work merely because separate teams built successive screens. Define where a process begins and ends, and test error recovery, back navigation, and session transitions rather than judging isolated fields.

Authentication without unnecessary cognitive tests

3.3.8 Accessible Authentication (Minimum), AA, restricts cognitive-function tests during authentication unless an allowed alternative, assistance mechanism, or specified exception exists. Memorizing a password and transcribing a verification code are relevant examples. Supporting password managers and paste is therefore operationally important.

The AA exceptions include object recognition and identifying personal content the user supplied. 3.3.9 Accessible Authentication (Enhanced), AAA, does not retain those two exceptions. Both levels still allow an alternative authentication method or a mechanism that assists completion of the cognitive test.

Follow the accessible authentication explanation when evaluating multi-step login. A good password field does not compensate for an inaccessible recovery screen. Test account recovery, one-time codes, and secondary verification using real password-manager and paste workflows.

Turn these criteria into acceptance tests with an owner, representative states, and evidence. Keep criteria separate from preferences: record an AA failure differently from a recommended AAA improvement. Store reusable patterns with your design-system documentation, then add regression checks when shared components change.

Key takeaways

• Six new A/AA criteria affect a typical AA migration; three additional criteria are AAA.
• Check focus under overlays, not just on an empty page.
• Provide non-dragging pointer alternatives and measure actual target bounds.
• Keep help predictable and avoid unnecessary repeated entry.
• Test authentication end to end, including recovery and verification.
• Treat automated checks as support for manual, criterion-specific review.