WCAG 2.2 Checklist for Teams

WCAG 2.2 is the current version of the Web Content Accessibility Guidelines, the standard that laws, contracts, and procurement checklists point to. A Level AA claim means meeting 55 success criteria: every Level A and Level AA rule in the WCAG 2.2 specification, organized under four principles.

This checklist groups those rules by principle and tags each item with the person who owns it: design, content, development, or QA. WCAG 2.2 also added six rules at Levels A and AA, and W3C WAI (the group behind these guidelines) walks through what changed and why. For the full rulebook in a form you can filter by level and topic, keep the W3C WAI Quick Reference open next to this page.

Perceivable means the information is present in a form people can see, hear, or have read aloud by assistive technology (for example, screen readers).

• Content: meaningful images get alt text that says what the image is for. Decorative images get empty alt text so screen readers skip them.
• Content: recorded video gets captions, live video gets live captions, and audio gets a transcript.
• Design: normal text has contrast of at least 4.5 to 1 against its background, and large text at least 3 to 1. Icons, form borders, and chart lines get at least 3 to 1 too.
• Design: color never carries meaning by itself. A required field is labeled required, not just marked red.
• Design and development: every page works at 200 percent zoom, and reflows (the layout rearranges to fit) on a screen 320 pixels wide with no sideways scrolling and nothing cut off.
• Development: headings, lists, tables, and page landmarks (named regions such as header, navigation, and main) are real code in the right order, not big styled text, so assistive technology can map the page.

Operable means every control can be reached and used, whatever the person is navigating with.

• Development: everything a mouse can do, a keyboard can do, in an order that makes sense, and focus never gets trapped (the keyboard highlight never gets stuck).
• Design and development: the keyboard focus indicator is always visible, and a sticky header or footer never fully covers the item in focus.
• Development: anything that works by dragging also works with a single pointer click or tap. No drag path required.
• Design: buttons, links, and other targets are at least 24 by 24 pixels, so unsteady hands and large thumbs can hit them.
• Development: people get enough time. Time limits warn before they expire and can be extended, and moving or auto updating content can be paused.
• Design: every page has a clear title, and every link's purpose is clear from its text or the words around it.

Understandable means people can read it, predict what it will do, and fix mistakes without a fight.

• Content: write in plain language. Explain unusual words and abbreviations the first time they appear, and set the page language in code so screen readers pronounce it correctly.
• Content and development: every form field has a visible label and instructions before the person starts typing, not after an error.
• Development: when a form has an error, the message names the exact field, says what is wrong in plain words, and suggests how to fix it.
• Development: never ask for the same information twice in one session. Carry it forward, or let people pick from what they already entered.
• Development: logins cannot demand a memory test or a puzzle. Password managers, paste, and passkeys (signing in on your device instead of typing a password) all have to work.
• Design and development: navigation and help options, like contact details and chat, appear in the same place and the same order on every page.

Robust means the page holds up in the browsers and assistive technology people actually use, including next year's versions.

• Development: every control exposes its name, role, and state in code, so a screen reader can announce what it is and whether it is open, closed, on, or off.
• Development: status messages, like an item added to a cart or results appearing after a search, are announced to assistive technology without yanking the person's focus away.
• QA: run the top tasks with a screen reader, such as NVDA, JAWS, or VoiceOver, and with keyboard only navigation, on real devices where you can.
• QA: keep the code clean and valid. Sloppy markup is where assistive technology trips first, long before a human notices.

Split the list and the list gets done. Left as one vague accessibility task, it stalls. Here is the standing split we recommend:

• Design owns contrast, target size, focus visibility, and layouts that survive zoom.
• Content owns alt text, captions, transcripts, plain language, and link text that makes sense out of context.
• Development owns keyboard support, real page structure, form behavior, and error handling.
• QA owns the release pass: a keyboard only walk-through, a screen reader pass on the top tasks, and a zoom pass, before anything ships.
• Run the checklist on every new page, every template change, and every redesign, and keep the results with the release notes. Accessibility debt compounds quietly; a routine like this keeps it visible while it is still cheap to fix.

Be honest about the limit: a checked box is not a user. Scanners catch only part of the standard. Five of the six rules WCAG 2.2 added at Levels A and AA cannot be checked by automated tools at all, so they need a person looking at the page. Even a careful manual pass misses things that daily assistive technology users find in minutes, because they know exactly where the friction hides.

So treat this checklist as the floor, not the finish line. It reliably keeps the known barriers out. Then test with real people who use screen readers, magnification, switches (hardware buttons used instead of a mouse or keyboard), and voice control, and fix what they find. That is how we run it at Thanos Labs: our Web Accessibility AI agent works the checklist and drafts fixes, a human in the loop approves every change, and testing with real users decides what done means.