Website Accessibility Audit Checklist: 30 Checks for WCAG 2.2 AA (Free PDF)

If you run a business website, then you know you are supposed to make it accessible. The hard part is finding out whether it already is, before you pay someone to tell you.

The good news is that the most common problems are easy to find yourself, with free tools and one afternoon. Most checklists online do not help with that. They give you 80 or more rules copied from WCAG, but they never tell you how to test them.

I audit 25 to 30 local business websites every month, most of them in Los Angeles, and I write the fix for every finding myself. So I know how many hours a real audit takes, and what a report has to contain to be useful.

In this guide, I’ll give you a 30 point accessibility audit checklist for WCAG 2.2 AA. Every check names a free tool and tells you how to test it. You can tick the boxes on this page, or download the checklist as a free PDF.

What Is an Accessibility Audit Checklist?

An accessibility audit checklist is a list of the things a website must do so that people with disabilities can use it. Each line stands for a rule in WCAG, the standard that US courts and the Department of Justice point to. You go through the list, test each item, and mark it Pass or Fail.

A checklist is not the same as a full audit. A full audit tests every page in scope and writes up every finding with a fix. For a 15 page site, that takes 24 to 30 hours. I explain what that looks like in my guide on what an accessibility audit is. A checklist is the fast first pass you can do yourself in an afternoon.

Most checklists leave out the test. WCAG 2.2 has 86 success criteria, and reading all of them does not tell you how to check a contact form. So every check below says what to look at, which tool to use, and what a pass looks like.

What You Need Before You Start

You need four free tools and about two hours. Install the tools first, because the checks below refer to them by name.

• The WAVE browser extension. WAVE is free from WebAIM and works in Chrome, Firefox and Edge. It marks contrast errors, missing alt text, empty links and missing form labels right on the page.
• The WebAIM Contrast Checker. This free page takes a text color and a background color and tells you whether they pass.
• A screen reader. NVDA is free on Windows. VoiceOver is built into every Mac and iPhone. You only need the basics: start it, read a page, and move through a form.
• Your keyboard. About a third of the checks are done by putting the mouse away and pressing Tab.

Then pick the pages to test. Start with your homepage, your contact page, and every page where a customer books, orders or pays. Those are the pages your visitors use most.

How to Use This Checklist

Each check has three parts: what to look for, how to test it, and the WCAG rule it covers. Read the check, run the test, and tick one box: Pass, Fail or Not sure.

If you cannot tell whether a video has correct captions, mark it Not sure and move on. A tester can settle it later.

The checks are in order of how often they fail. Section A covers the six errors that make up 96 percent of all the errors WebAIM found. Sections B to F cover the problems a scanner cannot see.

Automated tools find fewer than half of all barriers. The UK government tested ten tools on one page with 143 known problems, and the best tool found 41 percent. Deque measured 57 percent across 13,000 pages. So a scanner that reports zero errors has only done part of the work. Sections C to F cover the rest.

A. The six problems that cause most errors on the web

These six problems made up 96 percent of the errors in the WebAIM Million study. WAVE finds most of them in one click, so start here.

• 1. Color contrast passes.

  Text has to stand out from its background, or people with weak eyesight cannot read it. Normal text needs a contrast ratio of at least 4.5:1, and large text needs 3:1. To test it, paste the text color and the background color into the WebAIM Contrast Checker.

  WCAG 1.4.3

• 2. Every informative image has alt text.

  Alt text is the short description a screen reader speaks instead of showing the picture. “Three tacos on a plate” tells a blind visitor what is there, and “image1” tells them nothing. To test it, run WAVE and read every alt text it shows you.

  WCAG 1.1.1

• 3. Decorative images have empty alt text.

  A line, a shape or a background photo carries no information, so a screen reader should skip it. The code for this is alt="". To test it, run WAVE and look for the grey icons that mark these images.

  WCAG 1.1.1

• 4. Every form field has a form label joined to it.

  The label is the word next to the box, such as “Email”. If the label is not joined to the field, a screen reader says “edit text, blank” and the visitor has to guess. To test it, click the label text and see whether the cursor jumps into the field.

  WCAG 1.3.1, 3.3.2

• 5. No empty links.

  A link that holds only an icon, such as a Facebook logo, needs a name like “Visit us on Facebook”. Without a name, a screen reader says only “link”. To test it, run WAVE and look for “empty link”.

  WCAG 2.4.4

• 6. No empty buttons.

  The menu button, the search button and the close button all need a name. Without one, a screen reader says only “button”. To test it, run WAVE and look for “empty button”.

  WCAG 4.1.2

• 7. The language attribute matches the language on the page.

  A screen reader uses this setting to pronounce words correctly. A Spanish page must say es, not en. To test it, right click the page, choose View page source, and read the lang value in the first line.

  WCAG 3.1.1

B. Heading structure and navigation

Screen reader users move through a page by its headings and links, not by scrolling. These three checks make sure the page has a map.

• 8. The page has one H1, and the headings go in order.

  The page title is the H1, big sections are H2, and the parts inside them are H3. Screen reader users jump through a page by its headings, so a page without them has no map. To test it, run WAVE and open the Structure tab.

  WCAG 1.3.1, 2.4.6

• 9. A skip link appears on the first Tab press.

  The skip link lets keyboard users jump past the menu straight to the content. To test it, click in the address bar, press Tab once, and look for the link at the top left of the page.

  WCAG 2.4.1

• 10. Every link says where it goes.

  “Book a table” tells the visitor what will happen, and “Click here” does not. To test it, run WAVE, open the list of links, and read them one by one.

  WCAG 2.4.4

C. Keyboard access and focus (a scanner cannot test these)

A scanner cannot press Tab. These seven checks are done with your keyboard, and they catch the problems that lock out people who cannot use a mouse.

• 11. Everything works with the keyboard alone.

  Many people cannot use a mouse. To test it, put the mouse away and press Tab again and again until every link, button and field has had its turn.

  WCAG 2.1.1

• 12. Focus is visible.

  As you press Tab, an outline should show which element is selected. Many themes remove this outline, which leaves keyboard users lost. To test it, press Tab through the page and watch for the outline on every element.

  WCAG 2.4.7

• 13. There are no keyboard traps, and Escape closes popups.

  A keyboard trap is a menu or popup you can get into but not out of. To test it, Tab into every menu and popup, Tab out again, and press Escape on every popup.

  WCAG 2.1.2

• 14. Focus is never hidden behind a sticky element.

  A sticky header, a cookie banner or a chat bubble must not cover the focused element. To test it, Tab down a long page and watch whether the outline disappears behind anything.

  WCAG 2.4.11, new in 2.2

• 15. Menus and dropdowns open with the keyboard.

  Enter or Space should open them, the arrow keys should move inside them, and Escape should close them. To test it, Tab to each menu and try those keys.

  WCAG 2.1.1

• 16. Nothing works only by dragging.

  A slider or a map must also work with clicks or with keys. To test it, try each dragging feature with the keyboard.

  WCAG 2.5.7, new in 2.2

• 17. Targets are big enough to hit.

  Buttons and links need to be at least 24 by 24 pixels, or have clear space around them. To test it, right click a small button, choose Inspect, and read its size.

  WCAG 2.5.8, new in 2.2

D. Forms

A form that does not work turns a customer away. Three of these checks are new in WCAG 2.2.

• 18. Required fields are marked with text, not only with color.

  A red border means nothing to someone who cannot see red. Write “required”, or use a star and explain what the star means. To test it, look at every form on the site.

  WCAG 1.4.1, 3.3.2

• 19. Error messages name the field and say how to fix it.

  “Please enter your email address” helps, and “Error” does not. To test it, submit an empty form and read the messages. Then turn on a screen reader and check that it reads them too.

  WCAG 3.3.1, 3.3.3

• 20. Nobody has to type the same information twice.

  If a visitor typed their address on step 1, step 2 should not ask for it again. To test it, go through your checkout or booking flow from start to finish.

  WCAG 3.3.7, new in 2.2

• 21. Logging in does not need a puzzle.

  A picture puzzle locks out people who cannot see it, and blocking password managers locks out people who rely on them. To test it, log in as a visitor would.

  WCAG 3.3.8, new in 2.2

• 22. Help is in the same place on every page.

  The phone number, the chat button and the contact link should sit in the same spot across the site. To test it, open five pages and compare.

  WCAG 3.2.6, new in 2.2

E. Video, audio and motion

Video, audio and moving content need text alternatives and a way to stop them. These four checks cover both.

• 23. Every video has captions.

  Captions let deaf visitors follow the video. Auto captions are a start, but someone has to check them for mistakes. To test it, play each video with the sound off.

  WCAG 1.2.2

• 24. Every video and audio file has a transcript.

  A transcript is the written version, placed on the page or one click away. To test it, look under each video and audio player.

  WCAG 1.2.1, 1.2.3

• 25. Carousels and sliders can be paused.

  Anything that moves by itself for more than 5 seconds needs a pause button. To test it, load the page and look for the button.

  WCAG 2.2.2

• 26. Nothing plays sound on its own.

  A video or a music track that starts by itself drowns out a screen reader. To test it, load each page with the sound on.

  WCAG 1.4.2

F. Screen reader testing and hidden places

The last four checks need a screen reader, a PDF checker and a Google search. They find the problems that hide in files and forgotten pages.

• 27. The page makes sense through a screen reader.

  NVDA is free on Windows, and VoiceOver is built into every Mac. To test it, turn one on, close your eyes, and listen to the homepage and the main form.

  WCAG 1.3.2

• 28. Every PDF is a tagged PDF.

  Tags are what let a screen reader read a PDF, and a scanned picture of a menu has none. To test it, open the PDF in Acrobat and look for Tags, or run the free PAC checker. If the PDF fails, publish the content as a web page instead.

  WCAG 1.1.1, 1.3.1

• 29. Third party widgets pass the keyboard checks.

  Chat boxes, booking tools, maps and payment forms come from outside, but they are still part of your site. To test it, run checks 11 to 13 on each one.

  Process

• 30. There are no forgotten pages or files.

  Old PDFs and test pages stay online long after everyone forgets them, and Google still finds them. To test it, search Google for site:yourdomain.com and open every result.

  Process

What to Do With Your Fails

Now that you have a list of Fails, fix them in order, worst first. Here is a sensible order.

1. Anything that blocks a task. A form that cannot be submitted, a menu that traps the keyboard, or a checkout that needs a mouse. Fix these first, because they stop a visitor from becoming a customer.
2. The section A errors. Contrast, alt text, form labels, empty links and buttons, and the language setting. Most of these take minutes each, and they are the errors a scanner reports first.
3. Headings, focus and captions. These take longer, but they decide whether the site makes sense to a screen reader user.
4. PDFs and forgotten pages. Rebuild the PDFs that matter as web pages, and delete the ones that do not.

If your list is long, or you marked many checks Not sure, that is the point to bring in a tester. A NexoBee Snapshot covers your three most important pages for $249 and gives you a two page summary in two business days. If you then buy a full audit within 30 days, the $249 is credited toward it. My guide on what an accessibility audit costs shows what the bigger jobs cost at four US firms.

And once the site passes, keep it that way. Every new page, new plugin and new PDF can bring a Fail back. Run this checklist on any page you change, and run the whole thing every three months. Our monitoring plans do this for you from $49 a month.

FAQs About Accessibility Audit Checklists

Is this checklist the same as a full accessibility audit?

No. This checklist is a first pass you can do yourself on a few pages in an afternoon. A full audit tests every page in scope with a keyboard and a screen reader, and writes up every finding with a fix. For a 15 page site, that takes 24 to 30 hours. Use the checklist to find out whether you have a problem, and an audit to find all of them.

How often should I run an accessibility audit checklist?

Run it on any page you change, as soon as you change it. Then run the full checklist on your key pages every three months. New plugins, new themes and new PDFs are the usual way a fixed site breaks again. A monitoring plan does the quarterly check for you.

My scanner says zero errors. Do I still need the checklist?

Yes. Scanners find fewer than half of all barriers. The UK government found that the best tool caught 41 percent of known problems, and Deque measured 57 percent. A scanner cannot press Tab, listen to a screen reader, or watch a video for captions. Sections C to F of this checklist cover what the scanner missed.

Does this checklist cover WCAG 2.2 or 2.1?

Both. WCAG 2.2 includes everything in 2.1 and adds nine new rules. Six of the new rules that apply to small business sites are in this checklist, and each one is marked new in 2.2. If a lawyer or a client asks for 2.1 AA, a site that passes this checklist is covered for that too.

Why only 30 checks when WCAG has 86 success criteria?

Because 30 checks catch most of the problems on a small business website. The six checks in section A alone cover 96 percent of the errors WebAIM found across one million home pages. The other 24 cover the keyboard, form, media and screen reader problems that scanners miss. The rest of WCAG mostly applies to web apps, live media and complex interactions.

I hope this checklist helped you find out where your website stands. You may also want to read our guide on what an accessibility audit is and our article on accessibility audit costs in 2026. If you have already received a letter about your website, start with our guide on what to do after an ADA demand letter.

Sources: WebAIM Million 2026 (95.9 percent of home pages with WCAG failures, six error types making up 96 percent of errors). GOV.UK accessibility blog, 24 February 2017 (best tool found 41 percent of 143 barriers). Deque, 10 March 2021 (automation found 57 percent of issues across 13,000 pages). WCAG 2.2 from the W3C. Tools: WAVE, WebAIM Contrast Checker, NVDA, VoiceOver and PAC. NexoBee prices are from our audit and monitoring pages, checked 3 October 2026.