Accessibility is often handed to developers as an implementation problem. WCAG 2.2 makes that harder to justify, because most of what it added is decided long before anyone writes code: how large a target is, whether focus is visible, whether a user has to remember something, whether a task can be completed without dragging.
Here are the nine new criteria, what each one is protecting against, and how to handle it in a design.
Focus Not Obscured (Minimum) - AA
When an element receives keyboard focus, it must not be entirely hidden by other content.
The usual culprit is a sticky header. A keyboard user tabs down the page, focus moves to a link that has scrolled under the header, and they are now operating a control they cannot see. Design sticky elements with scroll-padding-top in mind, and check the tab order against every fixed element in the layout, including cookie banners and chat bubbles.
Focus Not Obscured (Enhanced) - AAA
The stricter version: no part of the focused element may be hidden. Worth targeting where you can.
Focus Appearance - AAA
Specifies how visible a focus indicator must be: at least a 2 CSS pixel perimeter with a contrast ratio of at least 3:1 against adjacent colours.
This is the criterion that should end the practice of removing default focus rings for aesthetic reasons. If the browser default does not suit the design, replace it with something better, not with nothing.
Dragging Movements - AA
Any function using a dragging movement must have a single-pointer alternative that does not require dragging.
Sliders, drag-to-reorder lists, map panning and image comparison controls all need another route: buttons, a numeric input, tap-to-select then tap-to-place. This affects people with tremors or limited dexterity, and anyone using a touchpad in a moving vehicle.
Target Size (Minimum) - AA
Interactive targets must be at least 24 by 24 CSS pixels, unless adequately spaced or presented inline in a sentence.
Note that 24 pixels is the accessibility floor, not a usability recommendation. Most platform guidelines suggest 44 to 48 pixels for primary actions, and that remains good advice. The criterion catches the genuinely small: icon-only buttons, close controls, dense pagination, tightly packed carousel arrows.
Consistent Help - A
If help is available - contact details, a chat widget, a help link - it must appear in the same relative position on every page where it is offered.
Moving support links between header, footer and floating bubble across a site creates real difficulty for users with cognitive disabilities. Pick a position and hold it.
Redundant Entry - A
Information already provided in a process must not be requested again in the same process, unless it is essential to re-enter it.
Design multi-step forms so previously entered data is either carried forward automatically or offered for selection. Password confirmation fields remain acceptable because re-entry is essential there. Retyping an address is not.
Accessible Authentication (Minimum) - AA
No cognitive function test may be the only way to authenticate. Remembering a password is a cognitive function test, so an alternative must exist: password manager support, a passkey, a magic link, biometrics.
Practically: never block paste into password fields, never disable autofill, and stop using puzzle-based CAPTCHAs as the sole gate. Transcribing distorted text is precisely the barrier this criterion targets.
Accessible Authentication (Enhanced) - AAA
The stricter version, which also disallows object recognition and personal content identification as the only method.
Also Worth Knowing: One Criterion Was Removed
WCAG 2.2 removed 4.1.1 Parsing, which required valid HTML parsing. Modern browsers and assistive technologies handle malformed markup consistently enough that the criterion no longer described a real barrier. Valid HTML is still a good idea; it is simply no longer a conformance requirement.
How to Build This Into Design Work
The practical shift is to treat these as design system decisions rather than per-screen checks.
- Set minimum target sizes in your component library so every icon button inherits a compliant hit area.
- Define a focus state as a first-class state in every interactive component, alongside hover and active.
- Fix the position of help affordances in your layout templates.
- Design multi-step flows with carried-forward data as the default pattern.
- For every drag interaction, specify the non-drag alternative in the same file.
Handled at the system level, this is close to free. Handled screen by screen after the fact, it is an audit and a remediation project. For how the same criteria apply to a purchase flow specifically, see our guide to accessible checkout.
