Resource

A practical WCAG 2.2 AA checklist for product teams

Published 2025-09-02 · Updated 2026-01-20 · 11 min read · By the Europlabs team

The WCAG 2.2 level AA checks that catch the most real failures, in the order worth doing them, including the nine success criteria that were new in 2.2.

The forty-minute version

Before any tooling, do this on your most important journey — checkout, sign-up, or whatever produces revenue. Unplug the mouse.

1. Complete the entire journey with Tab, Shift+Tab, Enter, Space and arrow keys only.
2. Watch where focus goes. Can you always see it? Does it ever disappear behind a sticky header or into an off-screen element?
3. Open every modal, menu and date picker. Can you get out with Escape? Does focus return where it came from?
4. Submit a form with deliberate errors. Are the errors announced, associated with their fields, and reachable?
5. Set the browser to 400% zoom at 1280px wide. Does content disappear or require horizontal scrolling?

Teams that have never tested typically find two or three blockers in that forty minutes. Those are worth more than a scanner report of four hundred findings.

What 2.2 added

WCAG 2.2 added nine success criteria over 2.1 and removed one (4.1.1 Parsing, now obsolete). The AA-level additions worth knowing:

3.3.8 catches teams by surprise, because “block paste into the password field” was for years treated as a security best practice. It is now an accessibility failure, and it was never good security.

Keyboard and focus

• Every interactive element is reachable and operable by keyboard (2.1.1).
• No keyboard traps — focus can always move away (2.1.2).
• Focus order is meaningful and follows the visual reading order (2.4.3).
• Focus is visible and its indicator meets 3:1 contrast against adjacent colours (2.4.7, 1.4.11).
• Focus is not obscured by sticky elements (2.4.11).
• A skip link or equivalent bypasses repeated navigation (2.4.1).

The single most common root cause we find: <div onclick> used as a button. It is invisible to keyboards and screen readers, and it usually appears dozens of times because it is baked into a shared component. Fixing the component closes dozens of findings at once, which is why we group findings by root cause rather than listing them flat.

Forms and errors

• Every control has a programmatic label — a real <label for>, not just placeholder text (1.3.1, 3.3.2).
• Errors are identified in text, not by colour or a red border alone (3.3.1, 1.4.1).
• Errors are associated with their field via aria-describedby, and announced via a live region.
• Suggestions are offered where the system can infer the fix (3.3.3).
• Legal or financial submissions are reversible, checked or confirmed (3.3.4).
• Autocomplete attributes are set on personal-data fields (1.3.5).
• Nothing is retyped that was already entered in the same process (3.3.7).

Placeholder-as-label deserves its own warning. It fails contrast, it disappears the moment typing starts, and it leaves anyone who is interrupted mid-form with no way to recover what the field was for.

Colour and contrast

• Body text at 4.5:1; large text (18.66px bold or 24px regular) at 3:1 (1.4.3).
• UI components and graphical objects at 3:1 — input borders, icons, chart series, focus rings (1.4.11).
• Colour is never the only signal for state, error or meaning (1.4.1).
• Text can be resized to 200% without loss of content (1.4.4).
• Text spacing overrides do not break the layout (1.4.12).

Disabled states are the recurring argument. There is no contrast exemption for disabled controls in WCAG, but if a control is genuinely inert it is not a UI component that needs to meet 1.4.11. The pragmatic answer is to make disabled states legible anyway — users need to read what they cannot use in order to understand why.

Structure and semantics

• One <h1> per page, then a heading hierarchy with no skipped levels (1.3.1, 2.4.6).
• Landmarks: header, nav, main, footer, with accessible names where repeated (1.3.1).
• Page titles are unique and descriptive (2.4.2).
• Link text makes sense out of context — no bare “read more” repeated twelve times (2.4.4).
• Images have appropriate alternatives; decorative images have empty alt="" (1.1.1).
• lang is set on the document, and on any passage in another language (3.1.1, 3.1.2).
• Custom components expose name, role, value and state correctly (4.1.2).
• Status messages are announced without moving focus (4.1.3).

On ARIA: the first rule is not to use it. A native <button> beats a <div role="button" tabindex="0"> with hand-written key handling every time. Most of the broken ARIA we find is applied to elements that did not need it, and it actively makes those elements worse than plain markup would have been.

Zoom, reflow and motion

• Reflow at 320 CSS pixels wide with no two-dimensional scrolling, except for data tables and maps (1.4.10).
• Content on hover or focus is dismissible, hoverable and persistent (1.4.13).
• Nothing flashes more than three times per second (2.3.1).
• Motion animation from interactions can be disabled — respect prefers-reduced-motion (2.3.3, AAA but cheap).
• Time limits are adjustable or can be extended (2.2.1). Session timeouts in banking and checkout flows are the usual offender.
• Auto-updating content can be paused (2.2.2). Carousels.

What to automate in CI

Automated testing reliably catches roughly a third of WCAG failures. That third is still worth automating, because it is the third that regresses silently.

Put an axe-core check into your pipeline against a set of representative rendered pages and fail the build on new violations. Add a linter rule banning click handlers on non-interactive elements. Add a contrast check to your design tokens so the palette cannot drift.

Then accept the limit. No scanner detects a wrong-but-present alt text, an illogical focus order, a modal that does not return focus, or a checkout that is technically operable but practically impossible. Those need a person, roughly twice a year and before any significant redesign.

---