What is a screen reader? How they work and how to test with them

A screen reader is software that converts screen information into speech or braille. In Dutch, it is also called a schermlezer.

Screen readers are mainly used by people who are blind or have low vision. Others can benefit too, such as people who understand information better when it is read aloud or temporarily cannot use a screen.

A screen reader lets you operate a computer, phone, tablet, website or app without a mouse or looking at the screen.

Want to start practising? Choose a guide:

• Testing websites with NVDA on Windows
• Testing websites with VoiceOver on Mac
• Testing apps and websites with VoiceOver on iPhone and iPad
• Testing apps and websites with TalkBack on Android

What does a screen reader do?

A screen reader does more than read ordinary text. It also identifies the elements you encounter, including:

• Headings
• Links
• Buttons
• Menus
• Form fields
• Images
• Tables
• Errors
• Status messages
• Selected or disabled elements

A well-built button is announced as Submit and button, telling the user what it is and what it does.

Speech and braille

Most people know screen readers through their computer-generated voices, but they can also send information to a braille display.

A braille display has one or more rows of small moving pins, allowing someone to read text by touch.

Preferences vary. Not every screen reader user reads braille, works at the same speed or uses the same software, commands and settings.

How does a screen reader work technically?

A screen reader obtains information from the operating system, browser, website or app.

Operating systems provide an accessibility interface, called an Accessibility API.

An API lets programs exchange information. Through it, assistive technology receives information about screen elements.

Three types of information are particularly important:

• Name: what is the element called? For example Search, Open menu or Email address.
• Role: what kind of element is it? For example a button, link, heading, field or table.
• Value or state: what is its current condition? For example checked, selected, collapsed, invalid or disabled.

If name, role or state is missing, the element is often unclear to screen reader users.

For example, sighted users recognise a magnifying-glass button as search. Without an accessible name, a screen reader may announce only “button”, leaving its purpose unknown.

Good code matters

A screen reader does not simply read screen pixels. It uses the accessibility API.

Good semantic HTML is therefore important: it already supplies much of this information.

Use:

• h1–h6 for headings
• Actual button elements for actions
• Actual links for navigation
• label elements for form field names
• Text alternatives for informative images
• Lists for enumerations
• Headers in data tables

ARIA: Accessible Rich Internet Applications

ARIA attributes add accessibility information to HTML. Use them only when ordinary HTML is insufficient. ARIA can help, but frequent misuse also makes it a major source of accessibility problems.

Read more in What is WAI-ARIA?.

Screen readers take practice

A screen reader can feel overwhelming at first. You hear a lot of information quickly, and operation differs from what you are used to.

Testing is still useful, but you will use it differently from someone who relies on it daily. In user research, I also see many differences between experienced users. Be careful with conclusions.

If something does not work, there may be three causes:

• The website or app is inaccessible.
• You are not yet using the screen reader effectively.
• The combination of screen reader, browser, device and settings behaves differently from what you expected.

Where possible, establish the cause before reporting a failure.

How do people use screen readers?

People use screen readers in different ways.

Some read a whole page from the beginning, particularly for unfamiliar or important content. Many navigate more quickly using:

• Headings
• Links
• Form fields
• Buttons
• Tables
• Landmarks
• Page search

A good page supports both approaches:

• A logical complete reading order
• A structure that supports quick scanning

Screen reader testing is not a full audit

Screen reader testing is useful, but it is not a full accessibility audit.

It mainly reveals problems involving:

• Name, role and state
• Reading order
• Heading structure
• Forms
• Errors
• Links and buttons
• Images
• Dynamic elements such as menus and dialogs

Other accessibility issues require different checks. Testing only with a screen reader misses issues involving:

• Colour contrast
• Zoom and text size
• Keyboard focus for people without a screen reader
• Captions
• Understandable language
• Touch target size
• Moving content
• Error prevention in forms

Always include screen reader testing as part of a broader assessment.

Which screen readers are available?

Most common operating systems have a screen reader.

Which screen reader should you test with?

Start pragmatically. The choice depends on what you are testing and your audience.

For a website aimed at Windows users, start with NVDA in a common browser such as Firefox, Chrome or Edge.

For Mac users, test VoiceOver in Safari.

For mobile websites and apps, test both VoiceOver and TalkBack. An app may exist on both platforms, but the underlying technologies differ considerably. This demands a lot from developers and often causes problems.

For services with significant impact, such as government, healthcare, education, banking or workplace systems, testing with real users is particularly important.

What can you test yourself?

Even with little experience, you can find many problems.

Check:

• Is the page title announced clearly?
• Are headings real headings and logically structured?
• Are links clear?
• Do buttons have names?
• Do form fields have labels?
• Are errors announced?
• Do informative images have useful alternatives?
• Is the page order logical?
• Can you operate menus, dialogs and pop-ups?

When reporting a problem, record:

• Screen reader
• Operating system
• Browser or app
• Steps taken
• Expected result
• Actual result

Common problems

Problems I often encounter:

• A button is announced only as button, with no name.
• A link says only read more.
• An image is announced as a filename, without an alternative.
• A form field has no label.
• An error is visible but not announced.
• A dialog opens, but content behind it is still read.
• Information is visible but not announced.
• Interactive elements work only with a mouse or ordinary swipes.

A practical testing order

When starting out, follow this order:

1. Test with the keyboard, without a screen reader.
2. Then enable a screen reader.
3. Read the complete page in order.
4. Check the heading structure.
5. Check links and buttons.
6. Check forms and errors.
7. Check images.
8. Check menus, dialogs and dynamic elements.
9. Test on mobile with VoiceOver or TalkBack.

Learn more

Further reading:

• W3C WCAG: Name, Role, Value
• W3C Understanding Name, Role, Value
• WAI: Providing Accessible Names and Descriptions
• WebAIM: Screen Reader Testing resources

Ready to practise with a specific screen reader? Choose a guide:

• Testing websites with NVDA on Windows
• Testing websites with VoiceOver on Mac
• Testing apps and websites with VoiceOver on iPhone and iPad
• Testing apps and websites with TalkBack on Android