UX glossary
Screen Reader
A screen reader is software that reads screen content aloud or outputs it on a braille display. Many blind and low-vision people use one to operate their computer and phone.
Imagine closing your eyes and trying to book a doctor’s appointment on a website. All you hear is a voice reading out what’s on the page, one item after another: “Link. Link. Image. Link. Button.” Where do those links go? What does the image show? And which button books the appointment?
That’s how many blind people experience poorly built websites. The tool they use is called a screen reader.
Explained simply
A screen reader is software that translates what’s happening on the screen into speech or braille. The speech output reads text, controls and status messages aloud. Alternatively, the screen reader sends the content to a braille display, a device with small moving pins that form raised dots you can feel.
Think of a screen reader as someone describing a website to you over the phone. But they can only tell you what’s in the code. If a button isn’t marked up as a button, or an image has no description, they’re stuck too.
How people use a screen reader
Hardly anyone listens to a website from top to bottom. Instead, people use keyboard shortcuts or swipe gestures to jump around: from heading to heading, through a list of all links, or straight to areas like the navigation and main content. In WebAIM’s Screen Reader User Survey (2023/24, 1,539 responses), 71.6 percent said that on a long page they first navigate by headings. Many experienced users also turn the speech rate way up, often to 300 words per minute or more.
The best-known programs are JAWS and the free, open-source NVDA on Windows, VoiceOver on Apple devices and TalkBack on Android. According to the same survey, 91.3 percent of respondents also use a screen reader on a phone or tablet.
An example
Here’s an example: an online cooking magazine has a recipe page with bold lines instead of real headings, links that say “click here” and a magnifying glass icon for search with no label. The screen reader just says “button,” nothing more. Anyone who wants to jump to the ingredients can’t find a heading for them.
After the fix, “Ingredients” and “Method” are real H2 headings, the links read “Open lentil soup recipe,” and the icon is announced as “Search.” The page looks exactly the same. But for screen reader users, it can now be scanned in seconds.
Why it matters
Screen readers depend on clean semantics, meaning every element in the code is what it appears to be. Those are exactly the requirements WCAG describes: alt text for images, labeled form fields, a logical heading structure and meaningful link text. Good structure helps everyone, including search engines and people who just skim. To learn how to set up your content that way, read How to Structure Content the Right Way.
In practice
- Try a screen reader yourself. VoiceOver comes built into every Mac and iPhone, and NVDA is free for Windows. Just ten minutes on your own homepage will reveal the biggest gaps. For more testing methods, see Accessibility Testing: Tools and Methods for UX Designers.
- Build a clear heading structure. One H1 per page, with H2 and H3 below it in a logical order. For many screen reader users, headings are the page’s table of contents.
- Write links and buttons that make sense on their own. “Learn more” ten times in a row helps nobody. Use text that names the destination.
Related terms
Accessibility, WCAG, Microcopy