WCAG 2.2 Explained: The 9 New Success Criteria and How to Meet Them

WCAG 2.2 became a W3C Recommendation on October 5, 2023. It adds 9 new success criteria to the existing WCAG 2.1 framework — 2 at Level A, 4 at Level AA, and 3 at Level AAA — bringing the total to 87 success criteria.

WCAG 2.1 Level AA remains the current legal baseline for ADA Title II, the European Accessibility Act (via EN 301 549), and Section 508. But WCAG 2.2 is where the standard is heading. Getting ahead of these criteria now means one remediation round instead of two.

Here is what each of the 9 new success criteria requires.

The 2 New Level A Criteria

Level A criteria represent the minimum. Failing them typically means some users cannot access the content or functionality at all.

3.2.6 Consistent Help (Level A)

If your site or application offers help mechanisms — a phone number, a live chat widget, a link to a FAQ or support page — those mechanisms must appear in the same location across pages that have them.

The failure mode: a "Contact Support" link that appears in the footer on most pages but moves to the sidebar on checkout pages, or disappears entirely on mobile views. Users with cognitive disabilities or low literacy may depend on knowing where to find help, and inconsistency breaks that reliance.

What to do: Audit where help links appear across your templates. Ensure help mechanisms live in a consistent global component (navigation or footer) and that responsive layouts do not remove or relocate them.

3.3.7 Redundant Entry (Level A)

If a user has already entered information in one step of a multi-step process, they should not have to enter it again in a later step — unless re-entering serves a security purpose (like password confirmation) or the information might have changed.

This is most common in checkout flows, registration wizards, and multi-page forms. Asking for a shipping address on step 2 and a billing address on step 3 that defaults to empty — when they are often the same — is the violation pattern. Asking for an email on both the account creation step and the contact preferences step is another.

What to do: Review multi-step flows for duplicate data entry. Pre-populate fields from prior steps, or provide a "same as above" checkbox. PIN confirmation and password re-entry are explicitly exempt.

The 4 New Level AA Criteria

Level AA is the target for most legal and regulatory compliance. These 4 criteria are the ones your team needs to implement if you are targeting WCAG 2.2 conformance at AA.

2.4.11 Focus Not Obscured (Minimum) (Level AA)

When a user navigates to a focusable element using the keyboard, the focused element must not be entirely hidden by other content. Sticky headers, floating chat bubbles, cookie banners, and fixed navigation bars are the common offenders — they can obscure the focused element when it is scrolled to.

"Entirely hidden" is the failure threshold at AA minimum: the element just needs to be partially visible. The AAA criterion (2.4.12, below) requires that it be fully visible.

What to do: Test keyboard navigation on pages with sticky elements. Tab through interactive elements and check whether any are obscured. CSS scroll-margin-top or scroll-padding-top on the html element can offset scroll position to account for sticky headers.

2.4.13 Focus Appearance (Level AA)

The keyboard focus indicator — the visual outline that shows which element is focused — must meet minimum size and contrast requirements. Specifically: the focus indicator must have at least a 3px perimeter or cover a minimum area, and it must have at least a 3:1 contrast ratio against adjacent colors.

Many sites use outline: none in CSS and provide a custom focus style that either fails contrast or is too thin to be visible. This is one of the most commonly failed WCAG 2.2 AA criteria.

What to do: Never use outline: none without providing an equally visible replacement. Use browser developer tools to inspect focus styles on interactive elements. Check contrast of the focus ring color against the page background. The W3C provides a focus indicator calculation tool that can verify whether a given style meets the criterion.

2.5.7 Dragging Movements (Level AA)

Any functionality that uses dragging (sliders, drag-and-drop, map panning, resizable panels) must also be achievable with a single pointer action — a click or tap.

Users with motor disabilities who cannot perform precise dragging movements need an alternative. This does not require removing drag interactions — it requires that every draggable interface also has a non-drag equivalent.

What to do: For sliders, provide up/down arrow key support (which is also required for operability by keyboard). For drag-and-drop list reordering, provide arrow buttons or a "move to position" input. For resizable panels, provide a numeric input or snap positions selectable by click.

2.5.8 Target Size (Minimum) (Level AA)

Interactive targets — buttons, links, checkboxes, radio buttons — must have a minimum target size of 24x24 CSS pixels, or have adequate spacing around them so that the effective click area meets the minimum even if the visual element is smaller.

This criterion addresses the difficulty users with motor impairments have in activating small, closely spaced interactive controls. Small icon buttons with no padding, tightly packed navigation links, and checkbox inputs with labels that are not clickable all fail this criterion.

What to do: Ensure buttons and links have at least 24px of clickable area via padding. Use CSS min-height and min-width on interactive elements. Test with a touch device to confirm targets are easy to tap.

3.3.8 Accessible Authentication (Minimum) (Level AA)

If authentication requires solving a cognitive function test — a CAPTCHA, a text puzzle — there must be an alternative that does not require cognitive function testing, or the test must use object recognition rather than text transcription.

What to do: Replace text-based CAPTCHAs with passkeys, magic links, or SMS verification. If you must use a visual challenge, provide an audio alternative that does not require transcription.

The 3 New Level AAA Criteria

Level AAA criteria are aspirational — WCAG explicitly states that full AAA conformance is not achievable for all content. These are worth understanding for accessibility-focused teams.

2.4.12 Focus Not Obscured (Enhanced) (AAA): The focused element must be fully visible — not just partially visible as required at AA. Zero tolerance for any overlap.

2.4.13 Focus Appearance (Enhanced) (AAA): The focus indicator requirement is more stringent: 4.5:1 contrast and minimum size must enclose the entire component perimeter.

3.3.9 Accessible Authentication (Enhanced) (AAA): No cognitive function test at all — even object recognition tests are excluded. Authentication must use a passwordless or credential-based mechanism only.

What WCAG 2.2 Means for Your Pipeline

Several of the new criteria are detectable before deployment. ESLint and jest-axe can catch missing focus styles, draggable elements with no keyboard alternative, and authentication components relying on inaccessible CAPTCHAs.

Criteria like Consistent Help placement and Focus Not Obscured require integration testing against assembled pages — a scanner running axe-core against a PR preview environment can catch focus obscurance regressions introduced by a new sticky element.

The right time to build these checks in is now. The earlier in the development process a violation is caught, the cheaper it is to fix — and WCAG 2.2 gives your team a concrete new checklist to work from.