WCAG checklist
WCAG 2.2 AA Checklist: What Should You Check on Your Website?
This checklist walks through the most important requirements of WCAG 2.2 level AA, grouped by topic. For every point you read what it involves and how to approach it in practice.
How to use this checklist
The checklist is a practical summary and does not replace the official WCAG text. Not every success criterion applies to every website: a site without video, for example, has no use for the captioning requirements.
Go through the list per page type, such as the home page, a form, a product page and the login page, and note what deviates. The numbers in brackets refer to the success criterion in WCAG. Criteria that are new in WCAG 2.2 are marked as such.
Images, video and audio
Not everyone sees or hears your media. Alternatives make the content available to everyone.
Alternative text for images (1.1.1)
Every informative image has an alt text that conveys the same information or function. Decorative images get empty alt text, so that assistive technology skips them.
Tip: Describe what the image means in this place, not only what is in it. A button with only an icon needs a name, such as 'Search'.
Captions, transcripts and audio description (1.2.x)
Video with sound has captions and audio without video has a transcript. For pre-recorded video, level AA also requires audio description for what can only be seen.
Tip: Always check automatically generated captions manually, especially for names and jargon.
No text in images (1.4.5)
Use real text instead of text in an image, except for logos. Real text scales, can be selected and is read aloud.
Tip: Do not put headings and buttons in a banner image, but as real text on the page.
Text, colour and display
Easily readable text helps everyone, and is indispensable for people with low vision and colour blindness.
Colour contrast (1.4.3 and 1.4.11)
Regular text has at least 4.5:1 contrast with the background, large text at least 3:1. Icons, borders of input fields and other parts you need to operate the page also have at least 3:1.
Tip: Check your brand colours thoroughly once. That prevents problems on every page.
Colour is not the only cue (1.4.1)
Never use colour as the only way to convey something, such as a red border for an error or a coloured link in running text.
Tip: Add a symbol, an underline or text, such as 'Error:' for an error message.
Resize and reflow (1.4.4 and 1.4.10)
Text can be enlarged up to 200% without content disappearing. Even at 400% zoom, the page can be read without scrolling horizontally. Tables and maps may scroll.
Tip: Let blocks that sit side by side move below each other on a narrow screen.
Text spacing (1.4.12)
If visitors increase the line spacing, letter spacing or word spacing, no text may disappear or slide over other text.
Tip: Do not give text containers a fixed height.
Structure, titles and language
A clear structure helps screen reader users navigate quickly and also makes your pages easier to scan for everyone.
Headings and structure (1.3.1 and 2.4.6)
Use real headings in a logical order, from main heading to subheadings, that describe what a section is about. Build lists and tables as real lists and tables, not just with separate lines and formatting.
Tip: Choose headings based on the content, not on the font size.
Page title and language (2.4.2, 3.1.1 and 3.1.2)
Every page has a unique, descriptive title. The language of the page is set, and passages in another language are marked as such, so a screen reader pronounces them correctly.
Tip: Put the most important word first in the page title.
Understandable link text (2.4.4)
The link text, possibly together with the sentence around it, shows where a link leads. 'Click here' and 'read more' are unclear without context.
Tip: Write 'Read more about our services' instead of just 'Read more'.
Keyboard and focus
Not everyone uses a mouse. Many visitors work with the keyboard, a switch or voice control.
Everything works with the keyboard (2.1.1 and 2.1.2)
All functions can be operated without a mouse, and focus never gets stuck, for example in a pop-up or embedded video.
Tip: Test with Tab, Shift+Tab, Enter, the space bar and Escape. Use real buttons and links, not blocks that were made clickable for the mouse only.
Visible focus that is not obscured (2.4.7 and 2.4.11, new)
Anyone navigating with the keyboard can always see where the focus is. New in WCAG 2.2 is that the focused component must not be entirely hidden behind, for example, a sticky header or cookie banner.
Tip: Never remove the focus outline without a clear alternative. Check that a sticky header or cookie banner does not cover the focused component.
Blocks can be skipped (2.4.1)
Visitors can skip repeated parts such as the menu. This is usually done with a 'Skip to content' link.
Tip: Make the link visible as soon as it receives focus.
Logical focus order (2.4.3)
The order in which the keyboard moves through the components follows the meaning and the visual order of the page.
Tip: Build the page in the same order in which you read it, so the focus follows the order on screen.
Forms and error messages
Forms are often where a visit fails. Good labels and error messages make the difference.
Labels and instructions (1.3.1, 3.3.2 and 4.1.2)
Every input field has a visible label that is also technically linked to the field. Example text in the field (a placeholder) is not a substitute for a label.
Tip: Click the label: if the cursor moves into the field, it is linked correctly. State expected formats, such as a date, up front.
Helpful error messages (3.3.1 and 3.3.3)
Errors are named in text, appear next to the relevant field and, where possible, include a suggestion to fix them.
Tip: After submitting, move focus to an error summary or the first field with an error.
Autofill (1.3.5)
Fields for personal data, such as name and email address, are set up so browsers and assistive tools can fill them in automatically.
No redundant entry (3.3.7, new)
Within the same process, do not ask twice for the same information. Prefill information you already have or let the visitor choose it.
Tip: For the delivery address, offer the option 'Same as billing address'.
Touch, dragging and mobile use
WCAG 2.2 sets extra requirements for people with limited motor skills and for use on a phone or tablet.
Sufficiently large touch targets (2.5.8, new)
Buttons and links are at least 24 × 24 pixels or have enough space around them. There are exceptions, for example for links in running text.
Tip: Make buttons on mobile more generous. A target of 44 × 44 pixels is a common guideline.
Alternative to dragging (2.5.7, new)
Functions you operate by dragging, such as a slider or reordering a list, can also be operated with a single click or tap.
Tip: Add buttons such as 'Up' and 'Down'.
Logging in and help
Two criteria that are new in WCAG 2.2 make logging in and asking for help easier, especially for people with a cognitive disability.
Accessible authentication (3.3.8, new)
Logging in must not depend on a cognitive test, such as remembering a password or solving a puzzle, without an alternative. Pasting into password fields and using a password manager must work.
Tip: Allow pasting, make sure password managers recognise the fields and, where possible, offer an alternative such as a login link or passkey.
Consistent help (3.2.6, new)
If a help option, such as a contact link or chat, appears on several pages, it always appears in the same place relative to the rest of the page.
Tip: Put contact and help information in the fixed header or footer.
Dynamic components and notifications
Custom-built components, such as tabs and drop-down menus, and moving content need extra attention, because assistive technology does not understand them automatically.
Name, role and value (4.1.2)
Custom-built components such as tabs, pop-ups and menus tell assistive technology what they are, what they are called and whether they are open or closed.
Tip: Where possible, use the browser's standard components, such as ordinary buttons and select lists. They pass on this information automatically.
Status messages (4.1.3)
Messages such as 'Added to basket' or the number of search results are read aloud without moving focus.
Tip: Mark such messages as status messages, so a screen reader reads them aloud automatically.
Moving content (2.2.2)
Content that moves, blinks or scrolls automatically and lasts longer than five seconds can be paused, stopped or hidden.
Tip: Do not let carousels advance automatically, or add a clear pause button.
How AccessRadar helps with this checklist
AccessRadar's automatic tests check many of these points for you, for example missing alt text or too little contrast. AI content analysis also assesses whether texts are meaningful: does an alt text, link text, heading or label really say something, or is it 'image', 'click here' or 'Info'?
You see every week what is improving and what still needs attention. Complement the results with manual testing and feedback from people with a disability for a complete picture.
Automatic tests and AI content analysis
AccessRadar combines automatic tests with AI content analysis. You see not only technical errors, but also which texts truly help your visitors.
The AI analysis reads the text of your pages and gives suggestions, for example for:
- Alternative text: does the text say something meaningful, or is it 'image', a file name or 'click here'?
- Link text: do the link text and the text around it make clear where a link leads?
- Headings and labels: do they describe the topic or the field, or are they empty words such as 'Info' or 'Field 1'?
- Page titles and forms: is it clear what a page is about and what a field expects?
You get concrete suggestions for better texts, which you pick up directly in your weekly improvement plan. This way your website moves closer to WCAG 2.2 AA suitability every week and reaches more customers.
Read how tests and AI analysis work together in the improvement plan
Read also
Practical explanations of WCAG and digital accessibility.
Testing Website Accessibility: a Step-by-Step Approach
How to test your website's accessibility: step by step with an automatic scan, keyboard test, screen reader and the most common problems.
WCAG Colour Contrast: Requirements, Exceptions and a Contrast Checker
What colour contrast does WCAG 2.2 require? Read the requirements for text, buttons and icons, and test your colours right away with the free contrast checker.
Keyboard Accessibility: Make Your Website Work Without a Mouse
Does your website work without a mouse? Read which WCAG requirements apply to keyboard operation and focus, how to test yourself and how to fix common problems.
Check your website for WCAG for free
Request the free WCAG check from AccessRadar and receive the results of an automatic scan by email, as a starting point for your improvements.
Want to keep going every week afterwards? The WCAG improvement plan adds weekly scans and AI content analysis.
A WCAG scan supports your assessment. An automated WCAG scan cannot establish full WCAG 2.2 AA compliance. Combine regular WCAG scans with manual evaluation and feedback from people with disabilities.
Frequently Asked Questions About the WCAG Checklist
What is the difference between a WCAG checklist and a WCAG scan?
A checklist is a list of points you go through and assess yourself. A scan is an automated test that checks part of those points, supplemented at AccessRadar with AI content analysis for alt text and link text, among other things. Use them together: the scan quickly finds common errors, the checklist helps with what a person has to assess.
Which criteria do I need to meet for level AA?
Level AA includes all criteria of level A and level AA. You do not need to meet the level AAA criteria for AA, although you can apply them where they fit.
Does my whole website need to comply, or only the main pages?
Conformance applies per full page and to complete processes, such as a checkout process. A page only conforms if all of its parts conform. In practice, you start with the pages and processes visitors use most.
Is this checklist enough to comply with the law?
The checklist is a practical route to WCAG 2.2 AA. Legislation such as the European Accessibility Act refers to the European standard EN 301 549, which links web content to WCAG. For your situation, an accessibility expert or lawyer can help you further.
Do I meet WCAG 2.1 if I meet WCAG 2.2 AA?
In practice, yes. WCAG 2.2 builds on 2.1 and adds criteria, so anyone who meets 2.2 also meets 2.1.