Accessibility testing is not a scan, it is a person at a keyboard

Most teams treat accessibility testing as something a scanner does before a release ships. We treat it as something a person does, because a scanner can confirm an image has alt text but cannot tell you if that text means anything. The gap between those two checks is where real users get locked out.

Automated accessibility tools are pattern matchers. They flag a missing label, a missing alt attribute, or a contrast ratio below the WCAG threshold of 4.5:1 for normal text and 3:1 for large text. What they cannot do is judge context: whether that alt text actually describes the image's purpose, whether tab order matches the visual layout on the page, or whether a screen reader announcement reads as sense rather than noise. Those judgments need a human tester working through the product with the same tools a real user relies on, not a linter reading the DOM.

What a scanner cannot judge

Effective manual testing covers three areas where automation runs out of judgment: keyboard-only navigation, screen reader behavior, and visual design under real constraints like low vision or color blindness. Each one means walking through the product the way an actual user would, with a keyboard alone, a screen reader such as NVDA, JAWS, or VoiceOver, or a color contrast analyzer, not a linter reading markup. None of those checks are quick, but skipping them is how obvious barriers survive all the way to production.

• Keyboard-only navigation, so every interactive element works without a mouse.
• Screen reader walkthroughs with NVDA, JAWS, or VoiceOver, so announcements make sense, not just exist.
• Color contrast and motion checks against WCAG thresholds, so low vision and motion-sensitive users are covered.
• Findings documented and prioritized by user impact, so fixes land where they matter most.

A scanner can confirm a rule was followed. Only a person can confirm it worked.

Test for people, not policy

Preparation is what keeps a testing session from turning into ad hoc clicking. We define scope before a single test begins: which pages or flows, which standard (commonly WCAG 2.1 Level AA), which assistive technologies and browsers. Testers then step through personas that stand in for real constraints, a blind user on a screen reader, a low vision user with screen magnification, a motor-impaired user on keyboard or voice control, a user with a cognitive disability who needs a simpler interface. That is what keeps a test session honest: it is measured against a person, not a checkbox.