Screen Reader Testing
Operating a product with a screen reader to find what assistive technology actually announces — the half of accessibility no automated scanner reaches.
Screen reader testing means completing real tasks using the software people actually use: NVDA or JAWS with Chrome or Firefox on Windows, VoiceOver with Safari on macOS and iOS, TalkBack on Android. What you are checking is what gets announced and in what order — whether a button says what it does, whether a dynamic update is spoken at all, whether the reading order matches the visual one, whether a custom component communicates its state.
It is the only way to catch the most common serious defects: a custom dropdown built from divs that announces nothing, a toast with no live region, an icon-only button read as “button”, a modal that leaves focus on the page behind it. Every one of those passes an automated scan.
Testing yourself is not the same as testing with users
Developers testing with a screen reader catch broken semantics — worth doing every sprint. People who use screen readers daily navigate differently, at speed, by headings and landmarks, and find problems that a sighted tester tabbing slowly never will. Do both; do not substitute one for the other.
In practice
A banking app's transfer confirmation appeared as a toast with no live region. Screen-reader users heard nothing after pressing Send and pressed it again. The duplicate-transfer rate among those users was several times the average, and it read in the data as a backend retry bug for months.
Where teams get it wrong
- Testing only with VoiceOver on macOS, which is the least-used combination among people who rely on screen readers.
- Testing individual components instead of completing a whole task.
- Assuming a passing automated scan means anything about what is announced.
- Sighted testers tabbing slowly, which misses heading and landmark navigation entirely.
- Never testing with actual screen-reader users.
( Learn more )
Related terms
All terms- Accessibility AuditA structured evaluation of a product against WCAG, producing a list of failures with severity, location and a route to fixing each one.
- WCAGThe Web Content Accessibility Guidelines — the standard almost every accessibility law and procurement contract points at.
- Inclusive DesignDesigning for the full range of human variation, treating exclusion as a design outcome rather than an edge case.
- Usability TestingWatching real users attempt real tasks in a product or prototype to find where they struggle, without steering them.