WCAG 2.2 checklist: every AA requirement in plain English
A practical WCAG 2.2 level A and AA checklist for websites, with what changed from 2.1, how to test each item, and which checks you can automate.
Short answer
WCAG 2.2 became a W3C Recommendation in October 2023. It has 55 success criteria at levels A and AA, including 6 new ones at those levels: Focus Not Obscured, Dragging Movements, Target Size (24×24 CSS pixels), Consistent Help, Redundant Entry, and Accessible Authentication. It removed 4.1.1 Parsing. Level AA is the usual target for the ADA, the European Accessibility Act, and most contracts.
This checklist covers the criteria that most often fail on real websites, not all 55 A and AA criteria word for word. The full list is in the W3C WCAG 2.2 specification.
What is new in WCAG 2.2
- 2.4.11 Focus Not Obscured (Minimum), AA: sticky elements must not fully cover the focused element.
- 2.5.7 Dragging Movements, AA: provide a non-drag alternative.
- 2.5.8 Target Size (Minimum), AA: 24×24 CSS pixel targets, or enough spacing.
- 3.2.6 Consistent Help, A: help links in a consistent place.
- 3.3.7 Redundant Entry, A: do not ask for the same information twice.
- 3.3.8 Accessible Authentication (Minimum), AA: no cognitive tests to log in.
- Three AAA criteria were also added (2.4.12, 2.4.13, 3.3.9), and 4.1.1 Parsing was removed.
Perceivable
People can see or hear the content, whatever their vision or hearing.
| Criterion | Level | How to check |
|---|---|---|
| 1.1.1 Non-text content | A | Every meaningful image has alt text that says what it shows or does; decorative images use alt="". |
| 1.2.2 Captions (prerecorded) | A | Videos with speech have accurate captions. |
| 1.2.5 Audio description (prerecorded) | AA | Important visual-only information in videos is described in audio or a text alternative. |
| 1.3.1 Info and relationships | A | Headings, lists, tables, and form labels use real HTML elements, not just styling. |
| 1.3.5 Identify input purpose | AA | Personal-data fields use the right autocomplete values (name, email, tel). |
| 1.4.1 Use of color | A | Color is never the only way to show an error, a link, or a state. |
| 1.4.3 Contrast (minimum) | AA | Text has at least 4.5:1 contrast; large text (24px, or 18.66px bold) at least 3:1. |
| 1.4.4 Resize text | AA | Text zoomed to 200% stays readable without loss of content. |
| 1.4.10 Reflow | AA | At 320 CSS pixels wide (400% zoom) content fits without horizontal scrolling. |
| 1.4.11 Non-text contrast | AA | Input borders, icons, and focus indicators have at least 3:1 contrast. |
| 1.4.12 Text spacing | AA | Increasing line, letter, and word spacing does not cut off text. |
Operable
Everything works with a keyboard, touch, and assistive technology.
| Criterion | Level | How to check |
|---|---|---|
| 2.1.1 Keyboard | A | Every link, button, menu, and form control works with Tab, Enter, Space, and arrow keys. |
| 2.1.2 No keyboard trap | A | You can Tab into and out of every widget, including modals and embeds. |
| 2.4.1 Bypass blocks | A | A skip link or landmarks let keyboard users jump past repeated navigation. |
| 2.4.2 Page titled | A | Each page has a unique, descriptive <title>. |
| 2.4.3 Focus order | A | Tab order follows the visual and logical order of the page. |
| 2.4.4 Link purpose (in context) | A | Link text says where it goes; avoid bare "click here" or "read more". |
| 2.4.6 Headings and labels | AA | Headings and labels describe their topic or purpose. |
| 2.4.7 Focus visible | AA | The focused element always has a visible focus indicator. |
| 2.4.11 Focus not obscured (minimum) | AA | New in 2.2. Sticky headers, cookie banners, and chat widgets do not fully hide the focused element. |
| 2.5.3 Label in name | A | A control's accessible name includes its visible label text. |
| 2.5.7 Dragging movements | AA | New in 2.2. Anything done by dragging (sliders, sortable lists) also works with single clicks or taps. |
| 2.5.8 Target size (minimum) | AA | New in 2.2. Click and touch targets are at least 24×24 CSS pixels or have enough spacing. |
Understandable
Content and forms are predictable and errors are easy to fix.
| Criterion | Level | How to check |
|---|---|---|
| 3.1.1 Language of page | A | The <html> element has the right lang attribute. |
| 3.2.2 On input | A | Changing a field or option does not unexpectedly submit a form or change the page. |
| 3.2.6 Consistent help | A | New in 2.2. Help options (contact link, chat, FAQ) appear in the same place on every page. |
| 3.3.1 Error identification | A | Form errors are described in text, next to the field. |
| 3.3.2 Labels or instructions | A | Every input has a visible label; required formats are explained. |
| 3.3.3 Error suggestion | AA | Error messages suggest how to fix the problem when possible. |
| 3.3.7 Redundant entry | A | New in 2.2. Users are not asked to re-enter information they already gave in the same process. |
| 3.3.8 Accessible authentication (minimum) | AA | New in 2.2. Login does not require a memory or puzzle test; allow paste and password managers. |
Robust
Assistive technology can read every control correctly.
| Criterion | Level | How to check |
|---|---|---|
| 4.1.2 Name, role, value | A | Custom controls expose a name and role; icon-only buttons have an aria-label. |
| 4.1.3 Status messages | AA | Messages like "Added to cart" or "3 results" are announced without moving focus. |
How to test
- Automated scan. Run axe-core based checks on each page template to catch contrast, labels, alt attributes, ARIA, and structure issues. Check text colors with the color contrast checker.
- Keyboard pass. Unplug the mouse. Tab through each page: can you see focus, reach everything, open and close menus and modals, and submit forms?
- Zoom and reflow. Zoom to 200% and 400% and narrow the window to 320px.
- Screen reader spot check. Use VoiceOver (Mac) or NVDA (Windows) on your key flows: navigation, signup, checkout.
- Document it. Publish an accessibility statement with the statement generator, including known issues and a contact for feedback.
Selling in the EU or the US? See the European Accessibility Act guide and the ADA guide.
Questions
What is the difference between WCAG 2.1 and 2.2?
WCAG 2.2 adds nine success criteria (six at levels A and AA) covering focus visibility, dragging, target size, consistent help, redundant entry, and accessible login. It also removes 4.1.1 Parsing, which modern browsers made unnecessary. A site that meets 2.2 AA also meets 2.1 AA.
Is WCAG 2.2 AA legally required?
It depends on where you operate. The European Accessibility Act points to EN 301 549, whose latest version moves to WCAG 2.2. In the US, ADA settlements usually reference WCAG 2.1 or 2.2 AA. Many contracts and procurement rules now ask for 2.2 AA. Check with a lawyer for your situation.
Can an automated tool check WCAG compliance?
Partly. Tools such as axe-core reliably catch issues like missing alt attributes, low contrast, missing form labels, and invalid ARIA. Many criteria need human judgment, such as whether alt text is meaningful or whether focus order makes sense. Use automation first, then test manually with a keyboard and a screen reader.
What does level AAA mean?
AAA is the strictest level. W3C does not recommend requiring AAA for entire sites, because some content cannot meet every AAA criterion. Most laws and contracts target AA.
How big must touch targets be under WCAG 2.2?
Success criterion 2.5.8 Target Size (Minimum), level AA, requires targets of at least 24 by 24 CSS pixels, or enough spacing that a 24 pixel circle around each target does not overlap another. Inline links in text and a few other cases are exempt.
Tools for this guide
Color contrast checker
Test text and UI colors against WCAG 2.2 AA and AAA and get the nearest passing color.
Open tool →Accessibility statement generator
Create an accessibility statement for the EAA and WCAG 2.2 in two minutes.
Open tool →Free website checker
Paste a URL for one report: SEO, share previews, security headers, AI crawler access, speed, and accessibility.
Open tool →More guides
Launch checklist for AI-built sites (Lovable, Bolt, v0, Cursor, Replit)
What sites built with AI app builders and coding agents usually get wrong before launch: SEO tags, share previews, client-only rendering, accessibility, broken links, security, and 404s.
Read · 9 min →ADA website accessibility for small businesses: a practical guide
Does the ADA apply to your website, what standard courts and the DOJ point to, why overlays are not a fix, and a step-by-step plan for small teams. Not legal advice.
Read · 9 min →Best Chrome extensions for website QA in 2026: SEO, accessibility, and speed
An honest roundup of the Chrome extensions web developers and agencies use to check SEO tags, accessibility, Core Web Vitals, and broken links before launch, with what each is best at.
Read · 8 min →