WCAG 2.2 Checklist for Designers and Developers

What does WCAG 2.2 Level AA require?

WCAG 2.2 Level AA requires that every page passes all Level A and Level AA success criteria in the W3C's Web Content Accessibility Guidelines. In plain terms: people can perceive the content, operate everything with a keyboard, understand what's going on, and use the page with assistive technology. Level AAA is optional and rarely required by law or contracts.

WCAG 2.2 AA is the version to target in 2026. It contains everything from 2.1 except one criterion the W3C retired, so meeting 2.2 also meets the 2.1 references in many laws and procurement documents. If you need the legal background first, start with our overview of website accessibility compliance.

Most WCAG checklists follow the W3C's numbered order. This one groups the WCAG 2.2 requirements by who usually fixes them, so each role can take its part.

What's new in WCAG 2.2?

WCAG 2.2 adds nine success criteria, six of them at Levels A and AA, and removes 4.1.1 Parsing as obsolete. The new criteria focus on people with low vision, motor impairments and cognitive disabilities, and several of them change how common UI patterns should be built. The W3C's own What's new in WCAG 2.2 page explains each one with examples.

Three more new criteria sit at AAA: enhanced focus not obscured, focus appearance and enhanced accessible authentication. They're good practice but not needed for AA.

What should writers check on a WCAG checklist?

Writers own the words that assistive technology reads aloud: alternative text, link text, headings, labels and error messages. Many failures that scanners flag as code issues are really copy issues, like an image with no description or a link that just says 'learn more'.

1. Alt text (1.1.1, A). Every meaningful image has a short description of what it shows or does. Decorative images get empty alt text so screen readers skip them.
2. Captions and transcripts (1.2.2, A; 1.2.5, AA). Videos with speech have accurate captions. Videos where visuals carry meaning have audio description or a text alternative.
3. Page titles (2.4.2, A). Each page has a unique title that says what it is, like 'Pricing | Brand name'.
4. Link purpose (2.4.4, A). Link text makes sense on its own or with its sentence. Replace 'click here' with what the link leads to.
5. Headings and labels (2.4.6, AA). Headings describe the section below them, and form labels describe the input.
6. Instructions don't rely on shape or position (1.3.3, A). Avoid 'click the round button on the right' as the only instruction.
7. Error messages (3.3.1, A; 3.3.3, AA). Errors say what went wrong and how to fix it, in text.
8. Language (3.1.1, A; 3.1.2, AA). The page declares its language, and passages in another language are marked.

What should designers check for WCAG 2.2 AA?

Designers own contrast, sizes, spacing, focus styles and layout behavior. These are the decisions that are cheap to get right in Figma and expensive to fix once components are built. For the visual techniques, see accessible design basics: color contrast, type and focus states.

1. Text contrast (1.4.3, AA). Body text at least 4.5:1 against its background; large text at least 3:1.
2. Non-text contrast (1.4.11, AA). Input borders, icons and focus indicators at least 3:1 against what's next to them.
3. Color isn't the only signal (1.4.1, A). Errors, links in text and chart series also use an icon, underline, label or pattern.
4. Visible focus (2.4.7, AA). Every interactive element has a clearly visible focus style. Design it, don't leave it to the browser default.
5. Focus not obscured (2.4.11, AA, new). Check sticky headers, cookie banners and chat bubbles don't hide the focused item.
6. Target size (2.5.8, AA, new). Buttons, icon buttons and pagination dots at least 24 by 24 CSS pixels, or spaced apart enough.
7. Reflow and zoom (1.4.10, 1.4.4, AA). Layouts work at 320 CSS pixels wide and at 200% text size without horizontal scrolling or cut-off text.
8. Text spacing (1.4.12, AA). Text stays readable when users increase line height and letter spacing.
9. Consistency (3.2.3, 3.2.4, AA; 3.2.6, A, new). Navigation, component names and help links stay in the same place and order across pages.
10. No flashing (2.3.1, A). Nothing flashes more than three times a second.

What should developers check on a WCAG 2.2 checklist?

Developers own keyboard behavior, semantics and how components talk to assistive technology. These issues are the hardest for automated tools to catch and the most likely to block a user completely, so they deserve the most testing time.

1. Keyboard access (2.1.1, A) and no traps (2.1.2, A). Every control works with Tab, Enter, Space and arrow keys, and focus can always leave a component.
2. Skip link (2.4.1, A). A 'skip to content' link or landmarks let users bypass repeated navigation.
3. Focus order (2.4.3, A). Tab order follows the visual order. Modals move focus in and return it on close.
4. Semantics (1.3.1, A). Use real headings, lists, tables, buttons and landmarks, not styled divs.
5. Name, role, value (4.1.2, A). Custom controls expose their name, role and state, such as expanded or selected, to screen readers.
6. Status messages (4.1.3, AA). Confirmations and errors that appear without a page load are announced.
7. Input purpose (1.3.5, AA). Personal-data fields use the right autocomplete attributes.
8. Hover and focus content (1.4.13, AA). Tooltips and menus can be dismissed, hovered and don't vanish unexpectedly.
9. Pause, stop, hide (2.2.2, A). Carousels and auto-playing content that runs longer than five seconds can be paused.
10. Dragging and pointer gestures (2.5.7, AA, new; 2.5.1, A). Sliders, sortable lists and maps have single-pointer alternatives.
11. Accessible authentication (3.3.8, AA, new). Allow paste and password managers, and offer an alternative to puzzle CAPTCHAs.
12. Redundant entry (3.3.7, A, new). Carry data forward in multi-step flows, or let people select what they entered before.

How do you check a site against this WCAG 2.2 checklist?

Check a site against the WCAG 2.2 checklist in layers: automated scans first, then manual keyboard and screen-reader passes on your key templates, then a review of anything custom. Each layer catches problems the previous one misses. Our guide to testing website accessibility covers tools and a 15-minute manual routine.

1. 1

   Pick the templates and flows

   List every page template and every task that matters: homepage, pricing, blog post, signup, checkout, contact. Checking templates covers every page built from them.

2. 2

   Run a scanner on each

   Use axe DevTools or Lighthouse to clear the mechanical failures: contrast, missing alt text, missing labels, empty links.

3. 3

   Do a keyboard pass

   Tab through each flow. Note any place focus disappears, gets trapped, jumps out of order or hides behind a sticky element.

4. 4

   Do a screen-reader pass

   Use VoiceOver on Mac or NVDA on Windows on the key flows. Listen for unlabeled buttons, missing announcements and confusing headings.

5. 5

   Check zoom and reflow

   Zoom to 200% and narrow the window to phone width. Look for overlapping or cut-off content.

6. 6

   Log and assign by owner

   Record each failure with its criterion and give it to copy, design or development, using the groups above.

Where does the WCAG checklist fit in a website project?

The WCAG checklist works best when it shows up at three points: when you write requirements, when you design components and when you QA before launch. Put 'WCAG 2.2 AA' in your website requirements checklist so every agency quotes against it, and add the developer items to your launch QA next to the technical SEO checklist for new websites.

After launch, accessibility drifts as content and features change. Add a quick keyboard pass and a scan to your website maintenance checklist each month. If you also run a product, the in-app side of this list is covered in accessible web app UI for product designers. And skip the shortcut: as we explain in do accessibility overlays work?, a widget can't tick these boxes for you.