Skip to content
Blog10 min read

WCAG 2.2 Compliance Checklist for Product Teams

A practical WCAG 2.2 AA checklist: the nine new success criteria, what to test on every release, and how to keep evidence that you did.

WCAG 2.2accessibilitycompliance checklistADAEuropean Accessibility Act
An accessible keyboard close-up, representing WCAG accessibility testing

WCAG 2.2 became a W3C Recommendation on 5 October 2023. It keeps everything in WCAG 2.1 except one criterion, 4.1.1 Parsing, which was removed as obsolete, and adds nine new success criteria. Most teams target Level AA. This checklist covers what changed, what to test on every release, and how to keep the evidence that you did.

The nine new success criteria in WCAG 2.2

  • 2.4.11 Focus Not Obscured (Minimum) — AA: a focused element must not be completely hidden by sticky headers, cookie banners, or chat widgets
  • 2.4.12 Focus Not Obscured (Enhanced) — AAA: no part of the focused element is hidden
  • 2.4.13 Focus Appearance — AAA: the focus indicator meets minimum size and contrast
  • 2.5.7 Dragging Movements — AA: anything done by dragging can also be done with a single pointer, such as clicking
  • 2.5.8 Target Size (Minimum) — AA: pointer targets are at least 24 by 24 CSS pixels, or have enough spacing, with listed exceptions
  • 3.2.6 Consistent Help — A: help options such as contact details or chat appear in the same place across pages
  • 3.3.7 Redundant Entry — A: don't make people re-enter information they already gave in the same process
  • 3.3.8 Accessible Authentication (Minimum) — AA: login doesn't depend on a cognitive test like remembering or transcribing, unless an alternative or aid is offered
  • 3.3.9 Accessible Authentication (Enhanced) — AAA: a stricter version of 3.3.8 with fewer exceptions

WCAG 2.2 AA checklist: what to test on every release

  • Keyboard: every interactive element is reachable and usable with the keyboard alone, in a logical order, with no traps
  • Focus: the focus indicator is visible and never fully covered by sticky or floating elements
  • Names and roles: buttons, links, and form fields have accessible names that match what is shown
  • Forms: labels, instructions, and error messages are programmatically tied to fields, and errors say how to fix them
  • Contrast: text meets 4.5:1 (3:1 for large text) and interface components meet 3:1
  • Targets: small icons and links meet the 24 by 24 pixel minimum or are spaced apart
  • Dragging: sliders, sortable lists, and maps have a non-dragging alternative
  • Authentication: password managers and paste work in login fields; no puzzle-only challenges
  • Images and media: meaningful images have text alternatives; video has captions
  • Structure: headings, landmarks, and lists reflect the real structure of the page
  • Zoom and reflow: content works at 200% zoom and at narrow widths without horizontal scrolling
  • Motion: animations can be paused or respect reduced-motion preferences

What automation catches, and what it doesn't

Automated tools such as axe-core reliably find a share of issues — missing names, contrast failures, invalid ARIA, missing labels. They cannot judge whether alternative text is meaningful, whether focus order makes sense, or whether an error message is helpful. A complete programme uses automation on every change and manual testing with a keyboard and a screen reader on key journeys.

The legal context in brief

  • United States: the Department of Justice's ADA Title II rule adopts WCAG 2.1 Level AA for state and local government websites and apps; an April 2026 interim final rule moved compliance dates to April 26, 2027 and April 26, 2028 depending on population
  • European Union: the European Accessibility Act (Directive (EU) 2019/882) applies to many consumer products and services, including e-commerce and banking
  • Meeting WCAG 2.2 AA also meets WCAG 2.1 AA, because 2.2 is a superset apart from the removed Parsing criterion

This is general information, not legal advice. Your obligations depend on where you operate and who your customers are.

Keep evidence, not just a score

When someone asks whether your site is accessible, a percentage score doesn't answer the question. A dated record of what was tested, what failed, and when it was fixed does. Scan on every deploy, keep the results, and treat a new accessibility failure like any other failing test: it blocks the pull request.

That is how Clearpath works. It scans every deploy against WCAG 2.2 AA in CI, files findings as issues with the selector, the rule violated, and the fix, and keeps a dated, exportable record of every scan. There is a free plan with unlimited CI scans; paid plans start at $39 a month.

Have the problem this post describes? The AI Architect will match it to a product or practice — with a price.

Run the AI Architect