Manual vs automated accessibility testing: Which one do you actually need?
Automated accessibility testing catches roughly a third of WCAG failures – the deterministic ones, like missing alt text, empty links, and contrast values that fail the math. Manual testing with a keyboard and a screen reader catches the other two thirds, including almost every failure that actually stops someone from finishing a task. If you can only afford one, buy the manual testing. If you’re doing this properly, you use both.
That’s the answer most vendors won’t give you straight, because most vendors sell one or the other. We built an automated tool and we sell manual audits, so we don’t have a side to protect here.
What scanners are genuinely good at
I want to be fair to automation, because we use it on every engagement. A scanner will find missing alt text, form fields with no labels, empty buttons, bad heading structure, and low-contrast text across your entire site in a few minutes. It doesn’t get tired, it doesn’t skip pages, and it hands you a backlog you can start triaging the same day.
For a team that has never tested anything, that first scan is the highest-value hour in the whole process. It also makes the manual audit cheaper – every scan-level issue you fix beforehand is an hour the auditor spends on judgment calls instead of cataloging missing labels.
So what does the scanner miss?
Everything that requires knowing what the page is for.
A scanner can confirm your date picker has an accessible name. It cannot tell you that the date picker traps keyboard focus, or that VoiceOver reads the calendar grid as a wall of unlabeled numbers, or that the error message appears visually but is never announced, so a blind user submits the form three times before giving up.
Take a checkout flow. Every field has a label, every button has a name, the contrast passes – the scan comes back nearly clean. Then a screen reader user tries to buy something: the coupon field steals focus on page load, the shipping options are announced in a different order than they appear, and the “order confirmed” message is a visual toast that assistive technology never sees. That checkout passes automation and fails every customer the ADA exists to protect. Nothing in that paragraph is hypothetical, by the way – it’s a composite of things we find weekly.
The pattern holds across components: modals, drag-and-drop, live-updating tables, multi-step forms. The DOM can look fine while the experience is broken. Judgment is still a human job.
The two thirds are where the consequences live
The failures automation misses aren’t a rounding error – they’re the ones with legal and commercial weight.
Roughly two thirds of digital accessibility lawsuits now target sites that were running an automated overlay when they got sued, which tells you how far scan-level compliance gets you in court. And in procurement, nobody asks whether you ran a scanner. They ask whether someone using JAWS or VoiceOver can complete your critical paths, and they expect a VPAT backed by testing that can answer that question honestly.
How we split the work
Automation goes first and maps the surface: every template, every page type, the full backlog of deterministic issues. Then the bulk of the audit hours go where people actually get stuck – a human working through your real flows with a keyboard, with JAWS, NVDA, and VoiceOver, at 200% zoom, on desktop and mobile where the audience calls for it.
The scanner tells us where to dig. The person does the digging, because the person is the only one who notices when a flow is technically passable but exhausting – twelve tab stops to reach the one control that matters, announcements that are accurate but useless. Those never appear in a scan report, and they’re the difference between a site that conforms and a site a disabled person would willingly use twice.
Frequently asked questions
What percentage of accessibility issues can automated testing find?
Roughly 30-40% of WCAG failures, depending on the site and the tool. The remainder – keyboard traps, focus order, meaningful alt text, announcement behavior – requires a person using assistive technology.
Is automated accessibility testing enough for ADA compliance?
No. Automated testing alone leaves the majority of WCAG failures undetected, and courts have not treated scan results or overlay widgets as evidence of compliance. Manual testing against WCAG 2.2 AA is the standard that holds up.
Should I run an automated scan before a manual audit?
Yes, and fix what it finds first. Teams that clean up scan-level issues before the audit pay less, because the auditor’s hours go into judgment calls instead of documenting missing alt text.
What tools do manual accessibility testers use?
The same ones your users rely on: NVDA, VoiceOver, and JAWS for screen reading, keyboard-only navigation, zoom up to 200%, and mobile screen readers like TalkBack where the audience calls for it.