What a screen reader finds that an accessibility scanner does not

January 21, 2026 · 5 min read · HQT

Automated scanners catch what can be stated as a rule about markup: missing alternative text, low contrast, an unlabeled form field. They do not catch most of what stops a resident from finishing a task. Those defects surface when a person drives the site with a screen reader and finds that the confirmation message was never announced, or the address lookup field traps the keyboard.

Basic screen reader testing does not require a specialist. We run these sessions on our own reference builds and internal tools, and a developer or content editor can learn the commands and start finding real defects.

NVDA with Firefox or Chrome on Windows is a free and practical starting point. VoiceOver ships with macOS and iOS and pairs with Safari. TalkBack covers Android. JAWS is commercial and widely used; add it later. Treat the screen reader and browser as a pair, because the same page behaves differently across pairings.

Few commands are needed: start and stop speech, move to the next element, list headings, links, and form fields, and switch between reading and form entry modes. Turn on the feature that shows spoken output as text, such as NVDA's speech viewer, so you can paste it into a ticket.

Test workflows, not pages

Page-by-page sweeps produce long lists of low-value findings. Pick the tasks residents come to do: find a service and its hours, submit an application, pay a bill, check a permit or case status. Run each one end to end without looking at the screen.

The point is not to simulate someone's experience of disability. It is that anything carried only by layout, color, or position disappears, and you hear what is left.

What breaks most often

Unlabeled controls. Icon-only buttons announce as "button" or read out a file name. Search, close, and menu icons are the usual offenders.
Headings chosen for size. No level-one heading, skipped levels, or bold paragraphs standing in for headings. Screen reader users navigate by heading, so a broken outline removes the main way to skim.
Link text with no meaning. A links list full of "read more" and "click here" tells the user nothing.
Custom widgets rebuilt from scratch. Accordions, tabs, modals, date pickers, address autocompletes. Focus is not moved into the dialog, not kept there, and not returned to the trigger on close. Expanded and collapsed states go unannounced.
Form errors. A summary appears at the top of the page, focus stays where it was, and nothing is spoken. Inline messages are not tied programmatically to their field.
Silent dynamic updates. Result counts, added rows, save confirmations, and timeout warnings that change the page silently.

Widget defects usually trace back to rebuilding a control the browser already provides. Before reaching for ARIA, check whether a native button, select, or label would do the job. ARIA can describe a custom control, but it cannot supply behavior that was never implemented.

Pay attention to what you did not build

Agency pages are assembled from third-party pieces: payment processors, chat widgets, map and GIS viewers, agenda platforms, translation bars. In our runs these are a frequent stopping point, often a keyboard trap inside an iframe. Test the embed as it appears on your page rather than relying on a vendor's conformance report, and ask for that report and a remediation date before renewal.

How to prioritize the fixes

Sort by whether the defect stops a task, not by how many instances a scanner counted.

Blockers on core services. Cannot submit, cannot sign in, cannot escape a component.
Silent failures. An unannounced error leaves the user no way to know what went wrong.
Template and component defects. One fix in a shared header, navigation, or form field corrects every page that uses it.
Content defects on high-traffic pages. Alternative text, heading structure, and link text, worked in traffic order.
The document backlog. Untagged and scanned PDFs are often the largest remaining item. Work newest and most requested first, and publish nothing new untagged.

Write each finding with the page address, the screen reader and browser versions, the steps, what was spoken, and what should have been spoken. "Not accessible" is not a ticket a developer can close.

What this means for an agency

Put a screen reader on one workstation, name the workflows that matter most, and budget a manual pass before each significant release. Keep automated scans in the pipeline to catch regressions; they are a minimum check, not evidence of conformance. Require a manual screen reader review in acceptance criteria for vendor-delivered software.

The Department of Justice rule under Title II of the Americans with Disabilities Act sets WCAG 2.1 Level AA for the web content and mobile applications of state and local governments, on compliance dates that depend on the size of the entity. It reaches content the entity provides or makes available, including vendor-supplied content, with limited exceptions. Federal agencies have a parallel obligation under Section 508. Neither can be demonstrated by automated testing alone.

Testing by sighted staff finds real defects, but it does not replace feedback from people who use assistive technology daily. Involve those users where you can. Progress is measured in tasks that can be finished, not in scanner scores.