Automated checks catch a useful slice of accessibility issues quickly. Manual testing with assistive technologies catches the rest — the flows, the judgment calls, and the failures that only show up when a real person tries to use the product.
Most engagements need both. We start with automation to map the surface, then spend the bulk of the audit where people actually get stuck.
What the scanners actually see
Scanners are excellent at spotting missing alt text, empty links, low-contrast hex values, and a long list of other deterministic failures. They run fast, they do not get tired, and they give you a backlog you can triage on day one.
What they cannot see is whether a custom date picker is usable with VoiceOver, whether a modal traps focus in a way that makes sense, or whether the error message next to a form field is announced when it appears. Those are judgment calls, and judgment is still a human job.
The quarter that matters
On a typical product surface, automation might surface roughly three-quarters of the issues that show up in a full audit — the easy quarter for machines. The remaining quarter is where real users get stuck: keyboard traps, broken focus order, unlabeled controls that look fine in the DOM until a screen reader hits them.
That last quarter is also where procurement conversations get serious. Buyers do not ask whether you ran a scanner; they ask whether someone who uses assistive technology can complete the critical paths.
Where a person is irreplaceable
We test with the same tools your users rely on — VoiceOver, TalkBack, JAWS, ZoomText, braille displays — because those sessions surface failures no rule engine has encoded yet. A person notices when a flow is merely “technically accessible” but still exhausting.
So we keep the scanners. We just refuse to let them be the whole story. Automation maps the surface; people find the places that matter.