Guide
WCAG 2.2 AA checklist, grouped by principle
A working checklist for a design and build team, organised the way WCAG is organised: perceivable, operable, understandable, robust. It paraphrases the checks rather than reproducing the success criteria, and it flags the nine criteria that WCAG 2.2 added.
WCAG 2.2 became a W3C Recommendation on 5 October 2023. The normative text is the specification; the Understanding documents explain it. This page is a testing aid, not a substitute for either.
How to use this checklist
Test a representative sample, not every URL. Cover each template, each interactive component and the journeys that matter most. For every item below, record one of three outcomes: pass, fail, or not applicable with a reason. A checklist with only failures recorded cannot show what was covered.
Work in two passes. The automated pass finds the cheap defects and gives you a baseline. The manual pass finds the rest, and it is where most of the real problems are. Test with a keyboard before you test with a mouse, and test at 200% zoom before you judge a layout.
1. Perceivable
Information must be presentable in ways people can perceive.
- Every meaningful image has alternative text that conveys its purpose; decorative images are ignored by assistive technology.
- Complex images such as charts have a short description plus a longer explanation nearby.
- Pre-recorded video has captions; audio-only content has a transcript; video that carries visual information has audio description or a described alternative.
- Colour is never the only way to convey meaning: errors, required fields, status and links all have a second cue.
- Body text meets 4.5:1 contrast; large text meets 3:1; icons, focus rings, borders and chart lines meet 3:1 non-text contrast.
- Text resizes to 200% without loss of content, and the page reflows to a 320 CSS pixel wide viewport without two-dimensional scrolling.
- Text spacing can be increased without clipping, and content that appears on hover or focus can be dismissed, hovered over and persisted.
- Real text is used instead of images of text, except for logos.
2. Operable
Every function must work without a mouse, and without causing harm.
- Every interactive element is reachable and operable by keyboard, in an order that matches the visual order.
- There are no keyboard traps: focus can always leave a component, including modals, embedded players and rich text editors.
- Focus is always visible, and a sticky header, cookie banner or chat widget never completely covers the focused element.
- A skip link or landmark structure lets a keyboard user bypass repeated navigation.
- Each page has a unique, descriptive title, and headings describe the content beneath them.
- Link text makes sense out of context; “read more” repeated ten times does not.
- Any drag interaction has a single-pointer alternative: reorder buttons, a menu, or a numeric input.
- Pointer targets are at least 24 by 24 CSS pixels, or are spaced so a 24 pixel circle centred on each does not overlap another target.
- Nothing flashes more than three times per second, and motion triggered by interaction can be disabled.
- Time limits can be extended or turned off, and sessions warn before they expire.
3. Understandable
Content and behaviour should be predictable and errors should be recoverable.
- The page language is declared, and passages in another language are marked up.
- Navigation, help mechanisms and component behaviour stay in the same relative order across pages.
- Nothing changes context merely because a field received focus or a value changed, unless the user was warned.
- Every form control has a visible, persistent label; placeholder text is not a label.
- Errors are identified in text, described in plain language, and suggest a correction.
- Legal, financial and data-deleting submissions can be reviewed, corrected or reversed.
- Information already entered in a process is not requested again unless re-entry is essential or required for security.
- Login does not require a cognitive function test unless an alternative, a mechanism, object recognition or personal content is offered; password managers and paste must work.
4. Robust
Markup must be understood by browsers and assistive technology, today and as they change.
- Custom widgets expose a name, a role, a state and a value, and update those states when they change.
- ARIA is used to fill gaps in native semantics, not to replace a working native element.
- Status messages such as “item added” or “3 results” are announced without moving focus.
- The accessibility tree is checked in at least one browser, not inferred from the DOM.
WCAG 2.2 removed success criterion 4.1.1 Parsing and marks it obsolete. Do not report it as a result. Keep writing valid markup, because other criteria and other tools still depend on a well-formed document.
What is new in 2.2
Nine criteria were added. Six are relevant to a Level AA target; the other three are AAA and useful as design guidance.
| Criterion | Level | Practical check |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Tab through the page with banners and sticky footers present; the focused item is at least partly visible. |
| 2.4.12 Focus Not Obscured (Enhanced) | AAA | The focused item is fully visible, with no part covered. |
| 2.4.13 Focus Appearance | AAA | The focus ring is large enough and reaches 3:1 contrast against its surroundings. |
| 2.5.7 Dragging Movements | AA | Sliders, sortable lists, maps and canvas tools offer a click or keyboard alternative to dragging. |
| 2.5.8 Target Size (Minimum) | AA | Controls are 24 by 24 CSS pixels or adequately spaced; check icon buttons in dense toolbars. |
| 3.2.6 Consistent Help | A | Contact, chat and self-help links sit in the same relative position on every page. |
| 3.3.7 Redundant Entry | A | Multi-step forms prefill or offer previously entered data instead of asking twice. |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login accepts paste and password managers, and offers a non-puzzle route such as an email link. |
| 3.3.9 Accessible Authentication (Enhanced) | AAA | No object-recognition or personal-content puzzle at any authentication step. |
What automation will miss
A scanner can tell you an image has no alt attribute. It cannot tell you the alt text is wrong. It can flag a contrast ratio; it cannot tell you the low-contrast element is the only indication that a field is in error. It cannot judge whether the reading order makes sense, whether an error message is understandable, or whether a custom combobox announces its selection.
That is why the audit method matters more than the tool. Thereport guide covers how to record what was tested and what was excluded, and theaudit service runs the manual pass alongside the automated one.
Publishing the result? A checklist is internal evidence. Visitors need a statement: use the free statement generator to turn your conformance status into a public page.
Frequently asked questions
Is WCAG 2.2 AA the same as Section 508 or EN 301 549?
No, but they overlap. Section 508 incorporates WCAG 2.0 through the Revised 508 Standards, and EN 301 549 v3.2.1 incorporates WCAG 2.1. WCAG 2.2 is backwards compatible, so meeting 2.2 AA means meeting the 2.0 and 2.1 criteria as well, apart from 4.1.1 Parsing, which 2.2 removed.
How many success criteria are in WCAG 2.2?
WCAG 2.2 adds nine success criteria to WCAG 2.1 and removes one, 4.1.1 Parsing. The exact count depends on whether you include the AAA criteria, so this checklist groups the AA-relevant work by principle instead of quoting a total.
Can I pass WCAG 2.2 with an automated scanner?
No. Automated tools reliably catch a subset: missing alternative text, contrast failures, unlabelled form fields, duplicate IDs, some heading order problems. Keyboard operation, focus visibility, reading order, error handling and screen-reader output need manual testing.
Do I need to meet AAA to be compliant?
Almost never. The EAA, the UK public sector regulations and the US Section 508 rule all point at Level AA. AAA criteria are useful as design guidance but are not the usual legal target, and some cannot apply to all content.
What changed in WCAG 2.2 that affects designers most?
Target Size (Minimum) at AA, Focus Not Obscured (Minimum) at AA, Dragging Movements at AA and Accessible Authentication (Minimum) at AA. The first two change layout and sticky-header decisions; the last two change component and login design.
Where do I record the result of this checklist?
In an accessibility report: scope, standard, method, a result per criterion, findings with severity, and a retest date. The report guide on this site sets out the structure.
More general questions are answered on the AccessProof FAQ.
Sources and last checked
Links opened on 24 October 2026. The Understanding documents are informative; the normative requirements are in the WCAG 2.2 Recommendation.
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2:w3.org - checked 24 October 2026.
- W3C WAI, What’s New in WCAG 2.2:w3.org - checked 24 October 2026.
- W3C WAI, all WCAG 2.2 Understanding documents:w3.org - checked 24 October 2026.
- W3C WAI, How to Meet WCAG 2.2 quick reference:w3.org - checked 24 October 2026.