How to test accessibility: tools, manual checks and limits

Before you can fix barriers, you have to find them. Testing is the first and most important step towards an accessible website – and also the one where most mistakes are made. Because “checking a website for accessibility” is often reduced to a quick tool scan, and that is exactly what leads people astray: a tool sees only part of the picture.

This article shows what automated tests can and cannot do, how manual checks and assistive technology cover the rest, and how a test result becomes a real fix – instead of a green tick that proves nothing. It sits within our wider guide on how to make a website accessible.

Why testing comes first

You cannot fix what you do not know about. How big the problem typically is becomes clear from the WebAIM Million study: in 2024, automatically detectable WCAG errors were found on more than 96 % of the home pages examined. The problem is therefore almost universal – and the first step towards a solution is an honest inventory.

The mindset behind this matters: testing is not a one-off act but part of a cycle of checking, fixing and checking again.

Automated tests: fast, but limited

Automated tools are a good start. They reliably find errors that follow clear, programmable rules, and they do so across many pages: missing alternative text, insufficient contrast, missing form labels, structural problems.

But their limit is fundamental – and here honesty beats marketing figures. Measured against the WCAG success criteria, automated tools can only meaningfully check about one third, roughly 16 of the 50 criteria for Level AA. The rest requires human judgement.

An important nuance belongs here: if you instead measure the sheer volume of individual issues found, the rate is higher – Deque cites around 57 % for its axe-core tool – because common error types such as contrast occur in large numbers and are automatically detectable. But that does not mean “57 % conformant”. It only means that the tool finds many individual cases while missing entire categories of requirements.

The reason is simple: a tool cannot judge whether alternative text is meaningful in content, whether an image is decorative or informative, whether the focus order is logical, or whether a text is clearly worded. What tools can do and exactly where they stop is explored in more depth in automated accessibility testing

One more warning sign: badly applied ARIA does not make a page better but worse – pages with ARIA show on average more detected errors than those without. That is exactly what overlays and rushed quick fixes produce (more on this in do accessibility overlays make you compliant?).

Manual checks: what tools cannot see

Here a person checks what requires judgement – which is the larger part of the criteria:

• Is alternative text meaningful in content, not merely present?
• Is the focus order logical and easy to follow?
• Are content, labels and instructions easy to understand?
• Do interactive processes – forms, filters, menus – actually work for everyone?

This kind of check is not a “nice to have” but the part without which no reliable statement about conformance is possible.

Testing with assistive technology

You get the most realistic impression when you use the site the way affected people do:

• Keyboard test: Operate the entire site using only Tab, Enter and the arrow keys. Can you reach everything? Is the focus always visible? Are there places you cannot get out of again? More in keyboard accessibility.
• Screen reader test: Go through the site with a screen reader – NVDA is free on Windows, VoiceOver is built into macOS and iOS, TalkBack into Android. Is everything read out meaningfully? Do the headings and landmarks make sense?
• Real users: Where possible, testing with people with disabilities is the most meaningful check of all.

From test result to fix

Testing is not an end in itself. The result is a list of real problems – and those are fixed in the source code, not papered over. The cycle behind it: check, fix in the code, check again, and the demonstrable value rises step by step.

This is exactly where an honest scanner comes in: it shows the real source-code problems and makes progress measurable through repeat scans – instead of simulating a green tick that would not survive scrutiny. Welcoma’s upcoming WCAG scanner is built for this: to reveal what is really there, so you can fix it.

Tools at a glance

• For a quick first assessment: axe (Deque), WAVE (WebAIM), Lighthouse (built into Chrome) and Pa11y (for automated pipelines). They deliver a first list of errors within minutes.
• For manual checks with assistive technology: NVDA, VoiceOver, TalkBack.

The crucial point: none of these tools replaces the others. A tool gives you the quick overview, manual checking gives you the depth, assistive technology gives you the reality. And a single “green” tool result is not proof of conformance – anyone who claims otherwise is selling appearance instead of substance.