WCAG 2.2 AA in practice, past what the scanner finds

A clean axe or Lighthouse report is a useful signal and a weak guarantee. How much a scanner finds depends on how you count. Deque, which makes axe, reports that axe-core finds 57% of issues across more than 2,000 audits — counted by volume, so a failure repeated across a page counts every time it appears. Counted by distinct barrier, GOV.UK's 2017 test of ten tools left 29% of 143 known barriers undetected by any of them. Either way, the gap is not obscure edge cases; it is the parts of accessibility that require understanding intent.

What tools catch, and what they cannot

The keyboard pass: five minutes, highest yield

Put the mouse down and tab through the page. This single exercise surfaces more real problems than any scan, because keyboard operability is a prerequisite for screen-reader, switch-device and voice-control users alike.

1. 01Tab from the top. Does focus move in the order the page reads? A visually reordered grid often tabs in DOM order, which is not the same thing.
2. 02Can you see where focus is, at every single stop? An invisible focus ring makes the page unusable, and outline: none without a replacement is the most common cause.
3. 03Can you reach every interactive control, including ones inside carousels, modals and custom dropdowns?
4. 04Can you operate each one — Enter and Space on buttons, arrow keys within a tab list or menu?
5. 05Open a modal. Is focus moved into it, trapped inside it, and returned to the trigger on close?
6. 06Is there a skip link, and does it actually move focus rather than only scrolling?

/* Never remove focus indication without replacing it. */
:focus-visible {
  outline: 2px solid var(--ring);
  outline-offset: 2px;
}

/* :focus-visible gives keyboard users a ring without showing one on
   mouse click — which is the reason people reach for outline: none
   in the first place. */
:focus:not(:focus-visible) {
  outline: none;
}

/* WCAG 2.2 added focus-appearance requirements: the indicator needs
   at least 3:1 contrast against the adjacent background. Test the ring
   colour against every surface it can appear on, both themes. */

What 2.2 added that 2.1 did not require

If your last accessibility review predates WCAG 2.2, these are the criteria most likely to be newly failing.

• Focus not obscured — a sticky header or cookie bar must not cover the focused element. Common with position: sticky and no scroll-margin.
• Dragging movements — anything draggable needs a non-drag alternative, such as buttons to move an item up or down.
• Target size (minimum) — interactive targets need 24×24 CSS pixels, or adequate spacing. Icon-only buttons frequently fail.
• Consistent help — if a help mechanism appears on multiple pages, it appears in the same relative place.
• Redundant entry — do not ask for the same information twice in one process without prefilling it.
• Accessible authentication — no cognitive test (like remembering a password unaided) without an alternative; password managers must not be blocked.

A screen-reader pass without becoming an expert

You do not need fluency to find real problems. Turn one on, navigate by headings and landmarks, and listen for whether the page makes sense.

1. 01Navigate by heading. Does the outline describe the page, with no skipped levels and exactly one h1?
2. 02Navigate by landmark. Are there header, nav, main and footer regions?
3. 03Navigate by link. Do link texts make sense in isolation? A list of six "read more" links is a failure.
4. 04Tab to each form field. Is the label announced, and is the error announced when validation fails?
5. 05Trigger something dynamic. Is the change announced, or does it happen silently?

Dynamic content and live regions

Content that appears after an action is the most common silent failure in modern applications. A toast notification, a validation error or a filtered result count that updates visually and announces nothing leaves a screen-reader user with no idea anything happened.

// A status message that is actually announced. The live region must
// exist in the DOM before the text changes — inserting the region and
// its content together is frequently not announced at all.
<div role="status" aria-live="polite">
  {message}
</div>

// Errors that block progress warrant assertive, and must be tied to
// the field so the association is announced on focus.
<input
  id="email"
  aria-invalid={error ? true : undefined}
  aria-describedby={error ? "email-error" : undefined}
/>
{error ? <p id="email-error" role="alert">{error}</p> : null}

Motion, and honouring the preference

Vestibular disorders make large parallax and scroll-triggered movement genuinely unpleasant. Respecting the operating-system preference is a two-line CSS change, and it should cover ambient loops as well as entrance animations.

The rule that matters: layout must never depend on an animation having run. A scroll-reveal that starts at opacity: 0 and relies on an observer leaves content permanently invisible for anyone whose reduced-motion preference disables the transition — unless the reduced-motion rule explicitly resets it to visible.

A realistic cadence

• Every pull request: automated scan in CI, plus a keyboard pass on anything with new interaction
• Every new component: keyboard and focus review before it ships, since it will be reused
• Quarterly: a screen-reader pass over primary journeys
• Before launch: contrast verification in both themes, and a 200% zoom check at 320px width

The honest framing is that accessibility is not a phase that completes. It is a set of checks cheap enough to run continuously and expensive to retrofit — which is the same economics as testing.