What WCAG 2.2 AA Actually Requires, Beyond Alt Text

October 27, 2026

Accessibility is a specific standard, not a vibe

"We care about accessibility" is a sentiment. WCAG 2.2 AA is a specific, published standard with 86 testable success criteria, published by the W3C in October 2023 as the current version of the Web Content Accessibility Guidelines. The AA level is also the one named in most accessibility laws and procurement requirements worldwide, which is why it is the practical target for most products, not the stricter AAA level, which even fully accessible sites often cannot meet for every criterion.

The gap between "we tested with a screen reader once" and actually meeting this standard is usually bigger than teams expect, because most of it is not about assistive technology at all. It is about interaction design decisions that get made without anyone checking them against the spec.

What WCAG 2.2 added that 2.1 did not cover

WCAG 2.2 introduced nine new success criteria on top of 2.1, several of which catch real, common problems that a basic accessibility pass misses entirely.

Target size

Interactive elements, buttons, links, form controls, need to be large enough to actually tap accurately, particularly for anyone with limited fine motor control. A row of small icon buttons packed tightly together, common in admin dashboards and mobile interfaces, is exactly the pattern this criterion exists to catch.

Dragging movements

Any interaction that requires a drag gesture, a slider, a reorderable list, needs a non-dragging alternative. If the only way to reorder a list is to drag an item, anyone who cannot perform a precise drag gesture is locked out of that feature entirely.

Focus visibility

When a user navigates by keyboard, the current focus indicator needs to actually be visible, not hidden behind a sticky header, a modal, or removed by a CSS reset that strips the default outline without replacing it. This is one of the most common real failures: focus outlines get removed for aesthetic reasons and never properly replaced.

Redundant entry

If a user already provided a piece of information earlier in a process, a multi-step form should not make them enter it again in a later step, unless there is a genuine reason to ask twice. This sounds like a UX nicety; it is a real accessibility requirement because re-entering information is disproportionately harder for users relying on assistive technology.

Accessible authentication

Login and account-recovery flows should not rely purely on cognitive tests, remembering a password with specific character rules, solving a puzzle CAPTCHA, as the only path to authenticate. Alternatives like password managers, email links, or other mechanisms need to be genuinely supported, not blocked by the interface.

Why this gets missed even on well-designed sites

Visual design and accessibility compliance are not the same discipline, and a site can look polished, pass a basic color-contrast check, and still fail WCAG 2.2 AA on several of these newer criteria, because they are about interaction behavior, not visual appearance. A custom-styled slider that looks great and has no keyboard alternative, a modal with a focus indicator that is technically present but rendered invisible by a shadow DOM quirk, a sign-up flow that silently requires solving an image puzzle, none of these show up in a glance at the design, only in direct testing against the actual criteria.

What this looks like in practice

This is why accessibility is part of how we approach UI/UX design as a testable requirement, not a design principle stated once and left unverified: real user research, design systems built with these criteria in mind from the start, and interactive prototypes checked against the actual WCAG 2.2 AA criteria before a line of production code is written. Our own accessibility statement states this as a goal with the same honesty we'd expect from any claim we make: automated tools catch a meaningful subset of issues, not everything, and manual testing against the real criteria is what closes the gap.

Frequently asked questions

Does passing an automated accessibility scanner mean a site is WCAG 2.2 AA compliant?
No. Automated tools reliably catch a subset of issues, missing alt text, insufficient color contrast, missing form labels, but cannot verify most of the newer interaction-based criteria like dragging alternatives or focus visibility, which need a person to actually test them.

Is WCAG 2.2 AA a legal requirement?
It depends on jurisdiction and industry; many accessibility laws and public-sector procurement standards reference WCAG 2.1 or 2.2 AA specifically. Whether a given law requires it for a specific business is a legal question outside what a design or engineering team can answer on its own, worth confirming with counsel for anything regulated.

What's the difference between AA and AAA?
AAA is the strictest level and includes criteria that are often genuinely difficult or situationally impossible to meet for every piece of content, sign language interpretation for all video, for example. AA is the level most real products target, and the level most accessibility requirements actually reference.