Automated accessibility checkers are fast, free and easy to run. It’s tempting to run one, fix what it finds and call your website accessible. The problem is that automated tools can only test part of what WCAG asks for, and a clean result doesn’t mean your site works for people with disability.
What automated testing is
Automated testing means using software to scan a page’s code and flag problems. Popular tools include WAVE, axe and Google Lighthouse. They’re excellent for catching certain kinds of issues quickly, across many pages, and we recommend using them. Our guide to free accessibility testing tools covers the main options.
What automated tools are good at
Tools can reliably catch issues that can be measured from the code, such as:
- images with no alt attribute at all
- text that fails colour contrast ratios
- form fields with no label
- missing page language or page title
- empty links and buttons
- some heading and ARIA errors
What automated tools miss
Many WCAG success criteria need human judgement. Studies by accessibility organisations and government digital teams have consistently found that automated tools catch only a minority of real accessibility barriers. Some common examples of what they can’t judge:
- Whether alt text is meaningful. A tool can see that alt text exists, but “image123.jpg” or “photo” passes the check.
- Whether the page works with a keyboard. A tool can’t tell if focus gets trapped in a menu, jumps around the page in a confusing order, or disappears from view.
- Whether a screen reader user can complete a task. Forms, pop-ups, carousels and booking tools often look fine in code but are confusing or impossible to use with JAWS, NVDA or VoiceOver.
- Whether headings and link text make sense. A tool can’t tell that ten links all saying “read more” are useless out of context.
- Whether content still works at 400 percent zoom or on a small screen.
- Whether error messages are clear and tell people how to fix the problem.
- Whether video has accurate captions, not just auto-generated ones.
Tools can also get it wrong
Automated tools sometimes report false positives, flagging things that aren’t real problems. Teams can spend hours fixing the wrong things while real barriers go unnoticed. A score of 100 in Lighthouse doesn’t mean your site meets WCAG 2.2 AA.
What manual testing involves
Manual testing means a person uses the website the way people with disability do. That includes:
- navigating every page and task with only a keyboard
- using screen readers to listen to how content is announced
- zooming in and resizing text
- checking content, headings, links and instructions for clarity
- testing on mobile devices
- reviewing linked documents such as PDFs and Word files
You can try part of this yourself with our step-by-step guide to testing your website using only a keyboard.
The best approach uses both
Automated tools are a great first pass and a useful way to catch new issues between audits. Manual testing finds the barriers that actually stop people from using your site. Used together, they give you an accurate picture.
How we test
Every accessibility audit we do is 100% human tested. We use tools to support our work, but every issue is checked by a person, and every finding comes with clear fix instructions. See what that looks like in our sample audit report.