Accessibility Testing Is Not a Checklist You Run Once

Automated accessibility scanners are a good first pass. They flag missing alt text, low contrast, and unlabeled form fields in seconds.

The problem is that they catch roughly a third of real issues. The rest need a person actually using the interface without a mouse.

What automated scans miss

A scanner can tell you an image has no alt attribute. It can't tell you whether the alt text you wrote is actually useful, or whether a modal traps keyboard focus once it opens.

• Focus order that jumps illogically around the page.
• Custom components (dropdowns, date pickers, tabs) that look right visually but don't expose the correct role or state to assistive tech.
• Content that updates dynamically without announcing the change to a screen reader.

Axe and Lighthouse are built around WCAG's automatable success criteria, things a script can check by inspecting the DOM: contrast ratios, missing labels, invalid ARIA attributes. Most of WCAG's criteria that touch actual usability, focus order, meaningful sequence, error identification, require a human judgment call a scanner has no way to make.

The manual pass that actually catches these

1. Unplug the mouse. Tab through the entire flow. Every interactive element should be reachable, and focus should be visible at every step.
2. Turn on a screen reader (VoiceOver, NVDA, or TalkBack) and complete the core user flow, not just the homepage. Forms, checkout, and search are where a user actually has to act, not just read.
3. Zoom to 200% and check that content reflows instead of clipping or overlapping.

A cadence that fits a normal sprint cycle

Running the full manual pass on every PR isn't realistic for most teams, and it doesn't need to be. A workable split looks like this:

• Every build: automated scans (axe, Lighthouse) in CI. Fast, cheap, and good at catching regressions on things that were already fixed once.
• Every new component: one manual keyboard pass before it merges, focused on that component alone, not the whole app.
• Before a major release: a full screen reader run through the core user flows, not the homepage. This is the pass that catches the issues that actually block someone from completing a task.

That split keeps the expensive check reserved for the moments it matters most, instead of either skipping it entirely or trying to run it on everything and quietly letting it slip.

Where this fits in a QA process

Treat WCAG conformance as a baseline, not the finish line. The standard tells you the minimum a page must support, not whether the experience is actually usable for someone relying on a screen reader every day. Passing an automated scan means a page cleared the bar a script can check. It says nothing about the bar a person clears.

We run both passes as part of accessibility testing engagements, usually starting with a scan-and-triage pass to clear the easy fixes before spending manual time on the issues only a person can find.