Web Development
Website Accessibility Checklist: 25 WCAG 2.2 AA Checks You Can Run Yourself
Accessibility can feel like a huge standard to read, but most failures on real business websites come from the same short list of problems. This checklist turns WCAG 2.2 Level AA into 25 checks you can run on your own site with a browser, a keyboard and free tools, and tells you which WCAG success criterion each one comes from so you can look up the detail. If you are in the US and want the legal background, read our guide to ADA website accessibility; for the EU, see our European Accessibility Act guide.
By WebsNexus · October 9, 2026 · 7 min read · Updated October 9, 2026
Website accessibility checklist (WCAG 2.2 Level AA)
| # | Check | WCAG criterion | How to test |
|---|---|---|---|
| 1 | Every page has a unique, descriptive title | 2.4.2 Page Titled | Read the browser tab on each template |
| 2 | The page language is set (for example lang="en") | 3.1.1 Language of Page | View source and check the <html> tag |
| 3 | One H1 per page, then H2/H3 in a logical order | 1.3.1 Info and Relationships | Use a headings browser extension or the axe DevTools outline |
| 4 | Header, navigation, main and footer landmarks exist | 1.3.1 Info and Relationships | Screen reader landmarks list, or inspect the HTML |
| 5 | A “skip to main content” link appears on the first Tab | 2.4.1 Bypass Blocks | Load the page and press Tab once |
| 6 | Meaningful images have alt text; decorative images have empty alt | 1.1.1 Non-text Content | Automated scan, then spot-check that alt text actually describes the image |
| 7 | Normal text has at least 4.5:1 contrast, large text 3:1 | 1.4.3 Contrast (Minimum) | Contrast checker in Chrome DevTools or the WebAIM checker |
| 8 | Icons, input borders and focus outlines have at least 3:1 contrast | 1.4.11 Non-text Contrast | Contrast checker on buttons, inputs and focus states |
| 9 | Colour is never the only way information is shown | 1.4.1 Use of Colour | Check error states, links in text and charts in greyscale |
| 10 | Text can be zoomed to 200% without losing content | 1.4.4 Resize Text | Browser zoom to 200% on key pages |
| 11 | Content reflows at 320px wide without horizontal scrolling | 1.4.10 Reflow | Zoom to 400% on a 1280px window, or use a 320px device view |
| 12 | Every link, button, menu and form works with the keyboard alone | 2.1.1 Keyboard | Unplug the mouse and use Tab, Shift+Tab, Enter, Space and arrows |
| 13 | Keyboard focus never gets trapped, and modals can be closed with Esc | 2.1.2 No Keyboard Trap | Tab into every widget, modal and embedded player and back out |
| 14 | Focus is always visible and not hidden behind sticky headers or banners | 2.4.7 Focus Visible; 2.4.11 Focus Not Obscured (Minimum) | Tab through the page with the cookie banner and sticky header showing |
| 15 | Focus order follows the visual order | 2.4.3 Focus Order | Tab through and watch that focus moves top to bottom, left to right |
| 16 | Link text makes sense out of context (no bare “click here”) | 2.4.4 Link Purpose (In Context) | Screen reader links list |
| 17 | Buttons and targets are at least 24×24 CSS pixels, or well spaced | 2.5.8 Target Size (Minimum) | Inspect small icon buttons, pagination and close icons |
| 18 | Anything done by dragging also works with a single click or tap | 2.5.7 Dragging Movements | Test sliders, sortable lists, maps and carousels |
| 19 | Form fields have visible labels tied to the input | 1.3.1 Info and Relationships; 3.3.2 Labels or Instructions | Click the label; the field should get focus |
| 20 | Name, email, phone and address fields use autocomplete attributes | 1.3.5 Identify Input Purpose | Inspect the form fields’ HTML |
| 21 | Errors are described in text and say how to fix them | 3.3.1 Error Identification; 3.3.3 Error Suggestion | Submit forms empty and with invalid data |
| 22 | Login doesn’t rely on memorising or solving a puzzle; paste and password managers work | 3.3.8 Accessible Authentication (Minimum) | Try pasting a password; check any CAPTCHA has an accessible alternative |
| 23 | Videos have captions; audio has a transcript | 1.2.2 Captions (Prerecorded) | Play each video with captions on and check accuracy |
| 24 | Moving, auto-playing or auto-updating content can be paused | 2.2.2 Pause, Stop, Hide | Check carousels, animated banners and tickers for a pause control |
| 25 | Custom widgets expose their name, role and state to assistive tech | 4.1.2 Name, Role, Value | Use VoiceOver or NVDA on menus, tabs, accordions and toggles |
What standard should a website accessibility checklist use?
Use WCAG 2.2 Level AA. The Web Content Accessibility Guidelines are published by the W3C and are the reference point for the ADA in the US (where courts and the Department of Justice commonly use WCAG 2.1 AA), the European Accessibility Act and EN 301 549 in the EU, and the Equality Act guidance in the UK. WCAG 2.2 became a W3C Recommendation in October 2023 and includes everything in 2.1, so a site that meets 2.2 AA also meets 2.1 AA.
Level A is the minimum and Level AAA is rarely required for a whole site. AA is the level laws, contracts and procurement teams ask for.
What changed in WCAG 2.2?
WCAG 2.2 added nine success criteria. The ones at Level A and AA that most often affect business websites are Focus Not Obscured (keyboard focus must not be hidden behind sticky headers, chat widgets or cookie banners), Dragging Movements (anything you drag must also work with a simple click), Target Size Minimum (small tap targets need to be at least 24 by 24 CSS pixels or have enough space around them), Accessible Authentication (no memory tests or puzzles to log in, and password managers must work), Consistent Help (help links appear in the same place on every page) and Redundant Entry (don’t make people type the same information twice in one process).
One criterion was removed: 4.1.1 Parsing is now obsolete, because modern browsers and assistive technology handle HTML errors consistently.
How do you test a website for accessibility?
Work in three passes. First, run an automated scanner such as axe DevTools, WAVE or Lighthouse on each page template. These quickly find missing alt text, low contrast, empty links and missing labels, but they cannot judge whether alt text is meaningful, whether focus order makes sense, or whether a custom widget actually works, so they only catch part of the problems.
Second, test with the keyboard only: put the mouse away and complete the main journeys, such as navigating the menu, submitting the contact form, adding to cart and checking out. Third, test with a screen reader, VoiceOver on Mac and iPhone or the free NVDA on Windows, on the same journeys. Most serious barriers show up in the second and third passes.
Which pages should you test first?
Test templates, not every URL. Most sites are built from a handful of templates: home page, service or product page, blog post, contact or booking form, cart and checkout, and account or login pages. Fixing a template fixes every page that uses it. Prioritise the journeys that make you money and the ones people with disabilities most need to complete, such as booking, buying and contacting you.
What are the most common accessibility failures?
Year after year, the same problems top large-scale audits of home pages: low-contrast text, missing alt text, empty links, missing form labels, empty buttons and a missing page language. All six are cheap to fix and covered in the checklist above. On business sites we also often find cookie banners that trap keyboard focus, menus that only open on mouse hover, and carousels with no pause control.
Will an accessibility overlay or plugin make my site compliant?
No. One-line overlay widgets don’t change the underlying code that screen readers and keyboards use, and many disabled users find they make sites harder to use. Businesses using them have continued to receive accessibility complaints and lawsuits. Fixing the templates is the reliable approach, and it usually improves search rankings and conversion at the same time, because accessible pages are better structured and easier to use.
How do you keep a site accessible after fixing it?
Accessibility drifts as new pages, plugins and campaigns are added. Add an automated accessibility check to your build or publishing process, include keyboard testing in QA for every new feature, train content editors to write alt text and use headings correctly, and repeat a manual audit of key templates once or twice a year. Publish an accessibility statement with a contact route so users can report problems they hit.
Frequently asked questions
What is the minimum level of accessibility a website should meet?
WCAG 2.2 Level AA. It is the level most accessibility laws and contracts reference, and it includes all Level A requirements.
Can I check website accessibility for free?
Yes. Free tools such as axe DevTools, WAVE and Lighthouse find many issues automatically, and keyboard testing plus the free NVDA or built-in VoiceOver screen readers cover the rest of this checklist.
How long does it take to make a website accessible?
A small brochure site can often be fixed in days because fixes are made once per template. Large sites with many templates and third-party widgets take longer, and new builds are far cheaper to make accessible from the start.
Is WCAG 2.1 or 2.2 required?
Many laws still cite WCAG 2.1 AA, but WCAG 2.2 AA includes all of 2.1, so building to 2.2 meets both and keeps you ahead of updated rules.