Screen reader.
A screen reader is assistive technology that turns on-screen content into speech or braille output and lets the user navigate by keyboard.
A screen reader does not read the page as it looks; it reads the accessibility tree the browser produces. That distinction is the foundation the whole of accessibility work rests on — what governs is the meaning derived from the markup, not the visual presentation.
The reading is linear, but the navigation is not. A user can listen to the page from start to finish, or jump from heading to heading, link to link, region to region or form field to form field. These shortcuts are the counterpart of a sighted user’s ability to scan at a glance — and they only work if the structure is marked up correctly.
A common misconception is that everyone using a screen reader is blind. The user base is wider: people with low vision use it alongside magnification, people with dyslexia follow the text by listening, and people experiencing cognitive fatigue may prefer to hear long texts read aloud.
- NVDA — Windows, free and open source; the easiest place to start testing.
- JAWS — Windows, commercial; common in corporate environments.
- VoiceOver — built into macOS and iOS; needs no additional installation.
- TalkBack — built into Android; the counterpart for mobile web testing.
- Narrator — built into Windows.
Screen readers behave differently from one another, and the same page can sound different in different ones. So working in one reader does not mean working everywhere — but breaking in one reader is almost always a real defect.
When using one for testing, the habit that helps most is turning off the screen or closing your eyes. Listening while looking leads you to complete what you hear with what you see, and you do not notice the missing information. Once the picture is cut off, what the page really says comes out.
Another practical point is the speech rate: the default is set for experienced users and is incomprehensibly fast for a beginner. Slowing it down markedly reduces the chance of giving up on the first try.
And having a reference point matters: listen to a well-built site before listening to your own. Otherwise you cannot tell whether the confusion you hear is a fault of your site or the normal behaviour of the technology.
The practical answer to how often screen reader testing should be done comes with its scope: conversion paths — form, search, sign-in, payment — should be listened to whenever they change. A flawed information page is annoying; a flawed form ends the business.