Quick answer
A screen reader is software that converts on-screen content into speech or braille output, letting people who can't see a screen use a computer, phone, or website. It reads a page's underlying structure — headings, links, buttons, form fields — rather than its visual appearance, and is operated entirely through the keyboard or, on mobile, touch gestures.
What is a screen reader?
A screen reader doesn't "see" the screen the way a sighted person does. It reads the underlying structure of a page instead — headings, links, buttons, form fields — and announces that structure item by item. This is why a screen reader depends on how a page is built, not just how it looks. A visually polished page with no real structure underneath it can still be unusable for a screen reader user.
Screen readers are controlled entirely through the keyboard. There's no mouse involved. This single fact shapes almost everything else about how they work and how websites need to be built to support them.
Who uses a screen reader?
Blind users
The group most people picture first. For them, a screen reader isn't optional — it's the only way to use a computer or phone independently.
People with low vision
Often pair a screen reader with screen magnification. The combination lets them zoom into part of a screen while the screen reader fills in what's happening elsewhere.
People with cognitive or reading disabilities
Some use a screen reader to have text read aloud, even though they can see the screen fine. Hearing content alongside reading it can make dense text easier to process.
People with temporary or situational impairments
Someone recovering from eye surgery, or driving and needing a phone read aloud, relies on the same technology for a limited stretch of time.
Developers, QA testers, and accessibility auditors
Use screen readers too — not because they need one, but because it's the most direct way to find out whether a site actually works for the people who do.
How does a screen reader work?
A screen reader doesn't read pixels off the screen. It talks to the operating system's accessibility layer — services like UI Automation on Windows, NSAccessibility on macOS, or AT-SPI on Linux — which exposes an "accessibility tree" built from the page or app's underlying code.
On a website, that tree comes from the HTML. A properly marked-up heading, button, or form label becomes a labeled node in the tree. A <div> styled to look like a button but coded with no semantic meaning becomes an unlabeled, unusable node — the screen reader has nothing to announce.
Once the tree exists, the screen reader moves through it using a virtual cursor, separate from the page's visual layout. That's why screen reader navigation order follows the order elements appear in the code, not how they're positioned on screen with CSS. A sidebar that's coded first but displayed last will still be read first.
The practical result: fixing a screen reader problem is rarely about the screen reader itself. It's almost always about tightening up the HTML or ARIA underneath.
How do screen readers provide audio output and braille support?
Audio
A screen reader passes text to a text-to-speech engine, which speaks it aloud through the device's speakers or headphones. Users can adjust rate, pitch, and voice. Many experienced screen reader users set speech rates far faster than a new listener could follow, since they've trained their ears to it over years of daily use.
Braille
The screen reader sends the same text to a refreshable braille display instead of, or alongside, the audio output. The display is a physical device with pins that rise and fall to form braille characters, updating as the user moves through the page. The screen reader translates standard text into braille — usually contracted "Grade 2" braille, which shortens common letter combinations — before sending it to the display.
Braille support matters most in situations where audio isn't practical: a quiet office, a public space, or a deafblind user who can't rely on audio at all. Most screen readers support both audio and braille output at the same time, and a user can rely on either one depending on the situation.
How do you use a screen reader?
The biggest adjustment for anyone new to a screen reader isn't learning a tool — it's unlearning the mouse. Every action has to happen through the keyboard, and most screen readers use two distinct modes to make that possible.
In browse mode, the screen reader treats the whole page as a document to explore: jumping between headings, listing all links on a page, or moving line by line through text. In forms or interaction mode, keystrokes stop navigating the page and start typing into whatever field currently has focus, the same way they would for a sighted keyboard user.
Common keyboard shortcuts let a user jump straight to the next heading, skip to the main content, or pull up a list of every link on a page — all without reading through everything in between. This is exactly why heading structure and landmark regions matter so much for accessibility: they're not decoration, they're the map a screen reader user actually navigates with.
Testing a site this way — mouse unplugged, screen reader on — tends to surface problems a visual review never would, because it exposes exactly what the underlying structure does and doesn't communicate.
Which are the most popular screen readers?
Screen reader choice usually comes down to platform first and cost second. A handful of names come up again and again, each tied closely to a specific operating system.
NVDA
A free, open-source screen reader for Windows, developed by NV Access. Its no-cost, no-license model makes it one of the most widely used screen readers among individual users and a common baseline for accessibility testing.
JAWS
A paid, Windows-only screen reader developed by Freedom Scientific, part of Vispero. One of the oldest screen readers still in active use, and common in workplaces and enterprise environments.
VoiceOver
Apple's built-in screen reader, included at no extra cost on every Mac, iPhone, and iPad. On iOS, it relies heavily on touch gestures rather than external keys, since the device has no physical keyboard by default.
TalkBack
Google's built-in screen reader for Android. Free and preinstalled, though its exact behavior can vary slightly between phone manufacturers.
Narrator
Microsoft's built-in screen reader for Windows, included with every copy of the OS. Historically less feature-complete than JAWS or NVDA, though Microsoft has steadily closed that gap.
Orca
The default screen reader for the GNOME desktop environment on Linux. Free and open source, maintained as part of the broader GNOME accessibility project.
ChromeVox
The built-in screen reader for ChromeOS, developed by Google. Ships on every Chromebook, often the first screen reader a student encounters.
Which devices and operating systems include screen readers?
Every major operating system now ships with a screen reader built in. None of them require a separate purchase to turn on.
| Windows | Includes Narrator by default. Most Windows users who need more advanced features add NVDA or JAWS on top of it, since both are widely compatible with Windows software. |
|---|---|
| macOS | Includes VoiceOver by default, accessible through System Settings or a keyboard shortcut. There's no separate screen reader to install for most Mac users. |
| Android | Includes TalkBack by default, though it may be labeled slightly differently depending on the phone manufacturer's version of the settings menu. |
| iOS / iPadOS | Include VoiceOver by default. It's deeply integrated with the touchscreen, using gestures like swipes and taps instead of the keyboard shortcuts used on desktop screen readers. |
| ChromeOS | Includes ChromeVox by default, available on any Chromebook through the device's accessibility settings. |
Why is screen reader compatibility important?
Screen reader compatibility isn't a single feature to check off. It's a direct measure of whether a site's underlying code actually carries meaning, or just visual styling.
For a business, the stakes break down into a few distinct pieces. There's audience reach: a meaningful share of any customer base has a disability that affects how they browse, and that share grows as a population ages. There's legal exposure: accessibility complaints and lawsuits over inaccessible websites have become common enough in some markets that compatibility is now treated as a baseline risk-management issue, not just a nice-to-have. And there's cost: fixing a missing label or broken heading structure before launch is far cheaper than retrofitting an entire site after it's built.
There's also a quieter overlap worth knowing about: the same semantic structure that makes a page work for a screen reader — clear headings, descriptive links, properly labeled content — is largely the same structure search engines rely on to understand what a page is about. A site built to be screen reader compatible tends to have cleaner, more parseable markup as a side effect, which is one of the few places where accessibility work and SEO work point in the same direction rather than competing for time.
Frequently asked questions
No — but developers, testers, and content creators often use one anyway, purely to check whether a site or app is actually usable for someone who does need it.
Only if the image has alt text. A screen reader reads whatever alt text is attached to an image; if there's none, it either skips the image silently or announces it as "image" with no further information.
Yes, but only if the PDF was built or tagged with accessibility in mind. An untagged PDF — most PDFs by default — behaves like a flat image of text, with little or no structure for a screen reader to read.
No. A screen reader reads content aloud to the user; voice control lets the user operate a device by speaking commands. Some users combine both, but they solve different problems.
