WCAG 2.2 Explained: Levels, New Criteria and a Practical Review Plan

Start an accessibility review by naming the target: for example, WCAG 2.2 Level AA for the complete checkout process. Then test the pages, components and states needed to finish that task. A clear target gives designers, developers and reviewers the same basis for deciding what needs work.

WCAG organizes web-accessibility requirements into testable success criteria. The four principles are perceivable, operable, understandable and robust. In practical terms, people need to get the information, operate the interface, understand what happens and use it with their browser and assistive technology.

What A, AA and AAA mean

The levels are cumulative. A Level AA target includes applicable Level A and Level AA criteria; Level AAA includes all three levels. Record the version as well as the level, because a report for WCAG 2.1 AA does not address every criterion added in 2.2.

WCAG 2.2 first became a W3C Recommendation on October 5, 2023. It adds nine success criteria compared with 2.1 and removes the obsolete 4.1.1 Parsing criterion. Existing work on keyboard operation, text alternatives, captions, contrast and other established requirements remains relevant.

Use the standard’s conformance requirements when defining the review scope. Include complete processes and full pages, including components supplied by other teams or vendors. A payment step or authentication screen can block a task even when the surrounding pages work well. Record any exclusions and their consequences in the report rather than letting the reader assume they were evaluated.

The nine additions at a glance

Criterion	Level	A useful review question
2.4.11 Focus Not Obscured (Minimum)	AA	Does a sticky element entirely hide the focused control?
2.4.12 Focus Not Obscured (Enhanced)	AAA	Is any part of the focused control hidden by author-created content?
2.4.13 Focus Appearance	AAA	Does the focus indicator meet the required area and contrast?
2.5.7 Dragging Movements	AA	Can a pointer user complete the action without dragging?
2.5.8 Target Size (Minimum)	AA	Do targets meet the size or exception conditions?
3.2.6 Consistent Help	A	Is repeated help in a consistent relative order?
3.3.7 Redundant Entry	A	Can previously supplied information be reused within the process?
3.3.8 Accessible Authentication (Minimum)	AA	Does each authentication step meet the cognitive-test conditions?
3.3.9 Accessible Authentication (Enhanced)	AAA	Does authentication meet the enhanced conditions?

Use this table to assign review work. Read each criterion and its Understanding document for the exact scope and exceptions before recording a pass or failure. The questions make the work approachable; the criterion determines the result.

Review focus with real overlays present

Tab through a page with its sticky header, cookie notice, chat launcher and fixed footer in the states users encounter. Under 2.4.11, a focused component must not be entirely hidden by author-created content. Under 2.4.12, the enhanced criterion, no part may be hidden in that way.

Focus Appearance, 2.4.13, is Level AAA. It concerns an indicator area at least as large as a 2 CSS pixel perimeter and at least 3:1 contrast between the same pixels in the focused and unfocused states, subject to the stated exceptions. This is a different check from whether focus is visible at all.

Make a small test page containing the actual buttons, links and form controls on their real backgrounds. Include error, selected and expanded states. Review the focus treatment in context before turning it into a shared design-system rule. A ring that works on a white card may disappear on a dark navigation bar.

Give pointer users an alternative to dragging

For a sortable list, offer controls to move an item or select its destination. For a value controlled by a draggable slider, an adjacent value field can give users a precise alternative. The Dragging Movements criterion concerns a single-pointer method that does not require a drag; keyboard support should also be implemented under the keyboard requirements.

Test the alternative by completing the same task from beginning to end. If a user can select an item but cannot place it, the alternative is incomplete. Keep the item identity visible and announce the resulting position where appropriate so the change is understandable.

For targets, 2.5.8 uses 24 by 24 CSS pixels with specified exceptions, including spacing, equivalent controls, inline targets, user-agent controls and essential presentations. Measure the actual interactive area and its neighbors. The target-size guide shows how to apply that check without assuming every icon has the same hit area as its visible drawing.

Reduce repeated work in forms

If a checkout asks for an address twice in the same process, populate the later field or provide a way to select the earlier information, subject to the criterion’s exceptions. A “billing address is the same as shipping” control is one familiar implementation. Test the behavior when the user goes back and changes the first address.

Keep repeated help mechanisms in the same order relative to other page content for the same page variation. Compare several pages at the same breakpoint and zoom level. The criterion applies when those help mechanisms are provided repeatedly; it does not require adding a new support service to every page.

These changes work best when specified in the process design. Record where information is first collected, where it is reused and which team owns each step. That map makes it easier to find a third-party screen that unnecessarily asks the user to start over.

Test the whole authentication path

Accessible Authentication (Minimum) allows specified alternatives or assistance for cognitive function tests. Password-manager support and allowing copy and paste are examples of mechanisms that reduce the need to remember or transcribe information. The AA criterion also contains object-recognition and personal-content exceptions; the enhanced AAA criterion has tighter conditions.

Test sign-in, a one-time-code step, recovery and any timeout that interrupts the process. Confirm that pasted codes and password-manager entries work in the actual fields. A usable first screen does not help if the recovery step blocks the same user.

Write expected behavior for each state before implementation. Include an unsuccessful attempt and the path back to the task. This catches interfaces that technically accept input but erase it, move focus unpredictably or leave the next step unclear.

Turn findings into repairs that can be retested

For each issue, record the page, component state, environment, steps, expected behavior, actual behavior and relevant criterion. Include the effect on the user’s task. Assign an owner and a verification step that another person can repeat.

For example: open the cookie notice, tab to the footer’s submit button, and observe whether the focused button is entirely hidden. After the layout changes, repeat those steps at the reported viewport and at other supported sizes. Retest shared components wherever the repaired behavior could differ.

Use automated tools to find detectable problems, then add keyboard, visual and assistive-technology evaluation. Close the review with a record of the scope, remaining issues and evidence. That gives the next release a concrete starting point and keeps the accessibility work tied to tasks people need to complete.