Screen Readers: How Blind and Low-Vision Users Browse

Everything in this section so far has led here. You know about roles, names, headings, and landmarks. But what does that really sound like? How does a person who cannot see the screen read your page, find the button, and fill in the form?

The answer is a screen reader: software that reads out what is on the screen, and lets the user move around and act with the keyboard, a touch screen, or a braille device. In this lesson you will learn how they work, which ones people use, and how to try one yourself. There is no better way to understand accessibility than to listen to your own page.

What You Will Learn

• What a screen reader is, and who uses it
• How it gets information from your HTML: name, role, state, value
• The main screen readers and the browsers they pair with
• Modes and navigation commands
• What gets announced for common elements
• How to try one yourself, and how to test
• The common mistakes that make pages hard to hear

The Big Idea

HTML Code

index.html

<nav aria-label="Main">
  <ul>
    <li><a href="/recipes">Recipes</a></li>
    <li><a href="/shop" aria-current="page">Shop</a></li>
  </ul>
</nav>

<main>
  <h1>Join The Bread Bin</h1>
  <label for="email">Email address</label>
  <input id="email" type="email" required>
  <button type="submit">Subscribe</button>
</main>

Hear a Page

http://127.0.0.1:5500/index.html

Load the faulty sample first, and press Next item a few times with your sound on. Then try the good sample. Pay attention to what is missing in the first one: names, roles, and a way to know what is a button.

What Is a Screen Reader?

A screen reader converts what is on the screen into speech or braille. It does not read pixels. It talks to the browser, and reads the accessibility tree, with a role, a name, a state, and a value for each element, as you learned in the introduction.

Who uses one?

• People who are blind.
• People with low vision, who use speech alongside magnification.
• People with reading difficulties, such as dyslexia, who hear text read aloud.
• People with cognitive or attention differences who find listening easier.
• Developers and testers, to check their work.
• People who simply prefer to listen, for example while driving or cooking, in simple forms of read-aloud.

Many experienced users listen at very high speeds, far faster than most sighted people expect. They also depend on navigation shortcuts, not on listening to everything in order. This is why structure matters so much.

The Main Screen Readers

Screen reader	Platform	Cost	Notes
NVDA	Windows	Free and open source	Very widely used, and a good first choice for testing
JAWS	Windows	Paid	Long established, and common in workplaces
Narrator	Windows	Built in	Improving, and always there
VoiceOver	macOS and iOS	Built in	Used with Safari. The main screen reader on iPhones
TalkBack	Android	Built in	The main screen reader on Android phones
Orca	Linux	Free	For Linux desktops
ChromeVox	ChromeOS	Built in	For Chromebooks

Which screen reader and browser people use together varies, and surveys change from year to year. As a start, many people use NVDA or JAWS with Chrome, Firefox, or Edge, and VoiceOver with Safari. Phone screen readers are very widely used, so do not forget mobile. Check recent surveys, such as the WebAIM screen reader user survey, for current numbers.

What a Screen Reader Announces

The usual pattern is: name, role, state, and (sometimes) extra help.

Element	Example of what you may hear
Heading	"Ingredients, heading level 2"
Link	"Recipes, link". A link to the current page may add "current page"
Button	"Subscribe, button". With a state: "More options, button, collapsed"
Text field	"Email address, edit text, required"
Checkbox	"Send me the newsletter, checkbox, not checked"
Image	"A golden sourdough loaf, graphic". An empty alt is skipped
Landmark	"Main, navigation landmark"
List	"List with 5 items"
Table cell	"Price, column 2, row 3, 4 dollars" (with the right header cells)

The exact words, the order of name and role, and the amount of detail vary between screen readers, and users can change their settings. What does not vary is the information they rely on. If your HTML does not supply it, they cannot hear it.

Try It: Match the Code to the Sound

HTML Code

announcements.html

<!-- "Save draft, button" -->
<button type="button">Save draft</button>

<!-- Skipped: decoration -->
<img src="swirl.svg" alt="">

<!-- "Shopping cart, link" -->
<a href="/cart"><img src="cart.svg" alt="Shopping cart"></a>

<!-- Only plain text: no role, no keyboard access -->
<div onclick="buy()">Buy now</div>

Announcement Drill

http://127.0.0.1:5500/index.html

Question 1 of 6

<button type="button">Save draft</button>

What does a screen reader say?

Exact wording varies between screen readers and settings. The idea (name, then role, then state) is the same.

Two Ways of Moving Around

On desktop screen readers such as NVDA and JAWS, there are two main modes:

Mode	What it is for	How it feels
Browse mode (also called virtual cursor)	Reading and exploring a page	Arrow keys and letter keys move through the content. You can press H for the next heading
Focus mode (also called forms mode)	Typing into a field	Keys go to the page, so you can type letters, even ones that are shortcuts in browse mode

The screen reader usually switches automatically when you reach a text field. This is one reason why real form controls are so important. A made-up control may not trigger the switch. On Mac and iPhone, VoiceOver uses different ideas (such as the rotor, which lets you choose to move by headings, links, form controls, and so on), and phone screen readers use touch gestures: swipe right or left to move through items, and double-tap to activate.

Common Shortcuts

These are only a few examples. They differ by screen reader and settings, and keyboard layouts differ too, so check the documentation of the one you use.

Task	NVDA and JAWS (browse mode)	VoiceOver on Mac
Start or stop the screen reader	Run the program	Command + F5
Stop speech	Control	Control
Next heading	H (Shift + H for previous)	VO + Command + H
Next landmark	D	Use the rotor (VO + U)
Next link	K	Use the rotor
Next form field	F	VO + Command + J
Next button	B	Use the rotor
Next table	T	Use the rotor
Next list	L	Use the rotor
List headings, links, or landmarks	Insert + F7 (NVDA)	VO + U (rotor)

On a phone, turn the screen reader on in the accessibility settings, then swipe to move and double-tap to press. On iPhone, it is called VoiceOver. On Android, it is TalkBack.

What Makes a Page Hard to Hear

These problems come up again and again in real testing:

Problem	What the user hears	Fix
Image with no alt	The file name, such as "IMG 4032 dot jpg"	Add a meaningful alt, or alt="" for decoration
Icon-only button with no name	"Button"	Add an accessible name
Link text "click here"	"Click here, link" (and a list of 20 identical links)	Descriptive link text
Input with no label	"Edit text"	Add a real label
div made into a button	Plain text	Use button
Heading used only for size	Wrong outline	Use the right level
Updates that do not announce	Silence, or a stale page	Use a live region, or move focus
Page jumps when a dialog opens	Lost in the page	Move focus into the dialog
Auto-playing audio	Competes with the screen reader's voice	Do not autoplay. Offer a control
Everything is read twice	Duplicated text	Remove redundant hidden text and labels
Table without headers	Cells with no context	Use th and scope

Try It Yourself: Your First Ten Minutes

You do not need to be an expert. Spend ten minutes on each of these, and you will learn a great deal.

1. Choose one. NVDA (free) on Windows, VoiceOver on a Mac or an iPhone, or TalkBack on Android.
2. Learn how to stop it. Know how to silence it, and how to turn it off, before you start.
3. Turn off the screen, or close your eyes, or use the "screen curtain" feature if it has one. Resist the urge to look.
4. Open a simple page, such as one you built, and move by headings.
5. List the links and the landmarks. Do they make sense?
6. Fill in a form with the keyboard only. Are the labels spoken? What happens when you make a mistake?
7. Open a menu or a dialog. Does focus move into it? Can you get out again?
8. Slow down. Listen at a normal speed first. Speed comes later.
9. Write down every moment you felt lost or confused.
10. Fix one thing, and listen again.

Do not judge by your first minutes

Everyone sounds clumsy with a screen reader at first. Experts are fast and efficient, and their experience of your page is very different from yours as a beginner. Your goal is not to become an expert, but to catch obvious problems, and to learn what the information in your HTML sounds like.

Testing With Screen Readers: Good Practice

• Test more than one combination, such as NVDA with Firefox, VoiceOver with Safari, and TalkBack with Chrome. They do not behave identically.
• Test on mobile as well as desktop.
• Test the important journeys: sign-up, search, checkout, and error recovery.
• Do not copy what one screen reader says as the standard. Follow the HTML and ARIA specifications, and use real tests to find problems.
• Pair testing with users who use screen readers every day. They find problems that you never will.
• Combine with automatic checks and keyboard tests, which find different problems.

Good Habits

1. Write semantic HTML, so the right information reaches the screen reader.
2. Give every control and meaningful image a name.
3. Use headings, landmarks, and lists so people can navigate.
4. Use real form controls, and real labels.
5. Announce dynamic changes with live regions or by moving focus.
6. Avoid duplicate and redundant text.
7. Do not autoplay audio.
8. Listen to your own pages regularly.
9. Test on more than one screen reader and browser, desktop and mobile.

Accessibility Checklist

• Every image has an alt, or is deliberately empty.
• Every link, button, and field has a clear accessible name.
• Headings and landmarks give a usable map of the page.
• Form fields have labels, and errors are announced.
• Dynamic updates are announced, or focus is moved to the new content.
• Dialogs and menus move focus in and out correctly.
• Tables have headers, captions where needed, and no layout tables.
• Nothing important is only in a background image, or only in colour.
• No audio plays automatically.
• The page has been heard with at least one real screen reader.

Security and Privacy Notes

• Screen reader use is private information. Detecting whether someone uses a screen reader can reveal a disability. Do not try to detect it, track it, or store it. Design so that it is not needed.
• Do not serve a different page to screen reader users, which is neither reliable nor fair.
• What is spoken can be overheard. Avoid reading out sensitive details such as full account numbers, passwords, or health information in error messages and status updates. Mask or abbreviate them.
• Password fields are normally announced as protected, and the characters are not read. Make sure you never expose a password in plain text in a label, a hint, or a live region.
• Hidden text is still text. Content that you make visually hidden for screen readers can also be read by search engines, scrapers, and anyone who views the page source. Never put secrets in it.
• Authentication should work with assistive technology. Do not make a login depend only on an image puzzle. See WCAG 3.3.8 (Accessible Authentication).

Global Audience Notes

• Screen readers speak in many languages, but they need to know which. Set lang on <html>, and on passages in other languages, or text may be pronounced in the wrong voice and become unintelligible.
• Voice quality and language support vary between screen readers and operating systems. Some languages have fewer or lower-quality voices, so clear structure matters even more.
• Braille is used worldwide, in many languages and codes. Good text alternatives and clean structure help braille users too.
• Many people use free or built-in tools, often on older phones and shared devices. Lean, semantic pages work best.
• Write plain, short labels and alt text that translate well, and are pronounced clearly.
• Numbers, dates, abbreviations, and symbols may be read in unexpected ways. Test them in each language you support, and write out anything that could be misheard.
• Right-to-left languages need dir="rtl", so the reading order is correct.

Common Mistakes to Avoid

1. Never listening to your own pages.
2. Assuming a screen reader user can see the layout.
3. Using "click here" and "read more" as link text.
4. Icon buttons with no name.
5. Unlabelled form fields, or placeholders as the only label.
6. Missing or filename-style alt text.
7. Faking buttons and links with div.
8. Silent updates that screen readers never announce.
9. Moving focus to the wrong place, or nowhere.
10. Over-using ARIA, so that it contradicts the HTML.
11. Testing with only one screen reader, and treating it as the truth.
12. Treating screen reader users as one group with one set of needs.

Practice Time

Try these in your browser and your editor:

1. Use the reader above, and fix every problem in the faulty sample, one by one.
2. Add a checkbox with a label to the good sample, and listen to it.
3. Turn on a screen reader on your phone, and use your favourite app for five minutes.
4. Install NVDA (or turn on VoiceOver), and move through a page of your own by headings.
5. List the headings, landmarks, and links of a site you use, with the screen reader's list feature.
6. Find an icon-only button on a real site, and see what it announces.
7. Fill in and submit a form with an error, and listen to how the error is announced.
8. Change the speech speed, and notice how much information you can take in.
9. Replace three "read more" links with descriptive text.
10. Bonus: ask a screen reader user, if they are willing, to walk you through how they browse a site.

Quick Recap

Click a question to check your answer.

1. What does a screen reader read?

The accessibility tree that the browser builds from your HTML, with each element's role, name, state, and value. It does not read the pixels of the screen.

2. Name three screen readers.

For example NVDA and JAWS on Windows, VoiceOver on Mac and iPhone, and TalkBack on Android.

3. What is the usual order of an announcement?

The name of the element, then its role, then its state, for example "Subscribe, button" or "Send me news, checkbox, not checked". The exact wording varies.

4. How do screen reader users usually find content?

By jumping between headings, landmarks, links, and form fields, rather than by listening to the whole page from the top.

5. What does an empty alt="" do?

It marks an image as decorative, so the screen reader skips it.

6. Why is it a bad idea to detect screen reader users?

Their use can reveal a disability, which is sensitive information. It is also unreliable and unfair to serve a different page. Design one accessible page for everyone.

Key Takeaways

• A screen reader turns the accessibility tree into speech or braille. It reads name, role, state, and value.
• People mostly navigate by structure: headings, landmarks, links, lists, and form fields.
• Desktop screen readers have browse mode and focus mode. Phone screen readers use gestures.
• NVDA, JAWS, VoiceOver, and TalkBack are the main ones. Test more than one, on desktop and on mobile.
• The usual problems are missing names, missing alt text, fake controls, silent updates, and wrong lang.
• Listen to your own pages regularly, and involve screen reader users when you can.
• Protect privacy: do not detect or track assistive technology, and do not read sensitive details aloud.

Next, learn the other major way people use the web without a mouse: Keyboard Accessibility.