The other 60% require a human tester — and often, a person who uses assistive technology every day. Here's what falls through the gap when you ship a Lighthouse report and call it done.
Automated tools find
The obvious 30%
Missing alt text on images
Colour contrast values below AA
Empty links or buttons
Missing form labels
Duplicate ARIA IDs
Basic HTML structure errors
These matter — but they're the floor, not the ceiling. Passing an automated scan does not mean you conform to WCAG 2.2 AA.
Only manual + PWD testing finds
The critical 60%
Screen reader announcement order
Focus traps in modals & menus
Keyboard-only flow completion
ARIA that reads correctly (not just exists)
Cognitive load & error recovery
Alt text that actually describes context
Colour used as the only cue
Meaningful reading order for AT users
Live region announcement timing
Real completion of tasks with AT
This is the difference between "our scanner says we're good" and "a person using a screen reader can actually complete checkout."
Real example
The checkout that passes every scanner — and fails every screen reader.
A recent SaaS checkout scored 100 on Lighthouse. Manual testing found:
The credit-card error announced silently — screen reader users didn't know their payment failed.
Tab order jumped from the coupon field to the footer, skipping the submit button entirely.
The 'processing' spinner had no live-region announcement — users assumed the page had frozen.
The confirmation modal trapped focus behind an off-screen close button.
None of these are automation-detectable. All of them are lawsuit-grade WCAG failures. This is why every ComplyPath plan layers manual testing — and why Plan B and C add real users with assistive tech.