If your accessibility program stops at an automated scan, you are catching roughly a third of the problems and shipping the rest. The failures that most affect real users — illogical focus order, meaningless alt text, unlabeled controls, dynamic updates that go unannounced — are precisely the ones a scanner can't judge. Manual testing is where those live. Here is how to do it without being an expert.
Why automated tools aren't enough
Scanners are excellent at the mechanical, yes/no checks: is there an alt attribute, is the contrast ratio a number above 4.5:1, does this input have a programmatic label. They are useless at the judgment calls that make up most of WCAG: is the alt text meaningful? Does the focus order make sense? Is this custom dropdown operable and correctly announced? Studies consistently put automated coverage around a third of all failures. The other two-thirds are found by people.
Keyboard-only testing (start here)
It requires no software — just put your mouse away. Using only the keyboard, work through each page:
- Tab through everything. Every link, button, field, and widget should be reachable and operable. Anything you can click with a mouse but can't reach with Tab is a failure.
- Watch the focus indicator. You must always be able to see which element has focus. An invisible focus ring is one of the most common — and most disabling — defects.
- Check the order. Focus should move in a logical order that matches the visual layout, not jump around unpredictably.
- Escape every trap. Open a menu, a modal, a date picker — can you get back out with the keyboard, or are you stuck? Keyboard traps strand users completely.
- Find the skip link. Pressing Tab on a fresh page load should reveal a “skip to main content” link so keyboard users don't tab through the whole nav on every page.
Screen-reader testing (the deeper pass)
You do not need to be a daily screen-reader user to catch the big problems. Install NVDA (free on Windows) or turn on VoiceOver (Cmd+F5 on Mac); JAWS is the paid enterprise standard. Then listen your way through the page:
- Headings: pull up the heading list — is there a logical H1→H2→H3 outline, or are headings missing or out of order?
- Links: do they make sense out of context, or is it a wall of “click here” and “read more”?
- Images: is each meaningful image described usefully, and are decorative images silent?
- Forms: is every field announced with its label and its required state? Are errors read aloud and tied to the field?
- Dynamic content: when something changes without a page reload — a search result, an error, a “saved” confirmation — is it announced, or does it happen silently? This usually requires correct ARIA live regions.
No screen-reader expertise on the team? Our testers run full manual keyboard and screen-reader audits against WCAG 2.1 AA and hand you findings mapped to each success criterion — not just a scanner printout.
The failures manual testing reliably finds
Across real audits, the same human-only defects recur: focus indicators removed in CSS; custom “buttons” built from <div>s that a screen reader never announces as buttons; modals that don't move focus or trap it; form errors shown only in red with no text and no announcement; carousels and dropdowns that can't be operated by keyboard; and alt text that reads “DSC_0421.jpg.” None of these reliably trip an automated scan — all of them stop a real user cold.
Build it into your workflow
You do not need a full audit for every change. Adopt a lightweight habit: for any new template or interactive component, do a five-minute keyboard pass and a quick screen-reader listen before it ships. Reserve the deep, documented audit for launches, redesigns, and your periodic compliance review. The combination — automated scans for coverage, manual testing for truth — is what actually keeps a site accessible over time, and what stands up as good-faith effort if anyone asks.