A screen reader is assistive technology that allows people, primarily those who are blind or have low vision, to navigate and interact with websites, apps, documents, and other digital content through speech or Braille.
A screen reader relies on the underlying structure, such as headings, links, buttons, form fields, labels, states, and relationships between elements that a browser or operating system exposes.
A website may look correct but still be difficult or impossible to use with a screen reader. A webpage can also work well with one screen reader-browser combination while behaving differently with another. For enterprise digital accessibility teams, “tested with a screen reader” is not specific enough. The screen reader, browser, platform, and task all matter.
How does a screen reader work?
When a browser loads a webpage, it interprets the HTML and creates the Document Object Model, or DOM.
The browser also uses the page’s HTML, CSS, and ARIA information to create an accessibility tree. That tree communicates information about elements such as:
- what the element is
- what it is called
- whether it is selected, expanded, checked, or disabled
- how it relates to other elements on the page
The screen reader receives this information through the operating system's accessibility APIs and converts it into speech or Braille.
A div styled to look like a button may look perfectly functional to a sighted user. But if it isn't coded as an actual button or given the appropriate accessible semantics, a screen reader may not identify it as a button.
The same principle applies to headings, form labels, tables, menus, alerts, dialogs, and other interactive components.
For screen reader users, that structure is essential to how they navigate.
How do people navigate websites with a screen reader?
One of the most common misconceptions about screen readers is that users start at the top of a page and listen to every word until they reach what they need.
Experienced users are usually much more efficient.
Screen readers let users navigate directly to headings, links, buttons, form fields, landmarks, tables, and other element types.
For example, UsableNet blog contributor Michael Taylor describes how he changes his navigation strategy throughout a typical ecommerce journey. When arriving on an unfamiliar site, he may first navigate by headings to understand how the page is organized.
When browsing a product list, he may switch to links to move quickly from one product title to the next.
During checkout, navigating directly among text fields can help him move through the form without repeatedly hearing information he has already reviewed.
Testing should also ask whether a user can understand the page structure, move efficiently to important functionality, determine the state of controls, and complete the intended task.
Individual screen reader users also develop different strategies and preferences. Michael notes that he occasionally listens to an unfamiliar or particularly confusing page from top to bottom, but generally avoids it because it is slower.
Who uses screen readers?
People who are blind or have low vision primarily use screen readers. Some people with other disabilities, including certain reading-related disabilities, may also use screen readers or text-to-speech tools.
Developers and QA professionals may also use screen readers for accessibility testing. But testing with a screen reader differs from relying on one for everyday navigation, which is why experienced screen reader users remain an important part of a mature testing program.
JAWS vs. NVDA vs. VoiceOver
Enterprise website testing commonly includes three screen readers: JAWS, NVDA, and VoiceOver.
| Platform | Windows | Windows | Apple devices |
| Cost | Commercial license | Free and open source | Included with Apple devices |
| Common testing role | Enterprise Windows testing | Windows accessibility testing | Mac, iPhone, and iPad testing |
| Developer | Freedom Scientific | NV Access | Apple |
JAWS
JAWS, or Job Access With Speech, is a commercial Windows screen reader from Freedom Scientific.
It has a long history in enterprise, government, education, and professional environments and remains an important part of many accessibility testing programs.
For corporate testing, organizations need an appropriate professional JAWS license. The inexpensive home license is intended for personal, noncommercial use, so QA teams should check current business licensing options directly with Freedom Scientific before budgeting.
NVDA
NVDA, or NonVisual Desktop Access, is a free, open-source screen reader for Windows developed by NV Access.
Its lack of licensing cost makes it easy for development and QA teams to add to their testing environment. More importantly, screen reader users also use it widely.
NVDA should not be treated as a lightweight substitute for a paid screen reader. It is an important testing target in its own right.
VoiceOver
VoiceOver is Apple’s built-in screen reader and is available across devices including Mac, iPhone, and iPad.
For organizations with meaningful iPhone and iPad traffic, VoiceOver testing should be part of the testing matrix.
Its navigation and interaction model also differs from JAWS and NVDA, which is one reason a component that works well on Windows may behave differently on an Apple device.
Do screen reader users stick with one screen reader?
Not necessarily.
In WebAIM’s 2024 Screen Reader User Survey, 71.6% of respondents reported using more than one desktop screen reader. Forty-three percent reported using three or more.
That is more useful for testing strategy than simply asking which screen reader has the largest market share.
Your customer may use JAWS at work, NVDA on another Windows machine, and VoiceOver on an iPhone.
The browser matters too.
Screen readers do not operate independently of Chrome, Edge, Firefox, or Safari. The browser renders the page and exposes accessibility information to assistive technologies, so the screen reader and browser are part of the testing environment.
A meaningful testing record could look like:
Ad hoc test: macOS + Safari + VoiceOver
Teams should also record versions when practical, because both browsers and screen readers change over time.
Why can a site work in one screen reader and fail in another?
Passing one screen reader test does not prove the same experience will work across other common screen reader and browser combinations.
Browser support, ARIA implementation, platform accessibility APIs, and the screen reader’s own interaction model can all affect the experience.
For example, a modal may open visually while screen reader focus remains on the page behind it. A selected state may be obvious visually but never announced. Or a custom component may work as expected with NVDA and behave differently with VoiceOver.
Which screen readers should an enterprise test?
No single testing matrix fits every organization. Your actual customer traffic, supported browsers, platforms, applications, and accessibility requirements should drive the final plan. For many enterprise websites, however, a useful baseline includes:
NVDA with a mainstream Windows browser.
NVDA gives teams an accessible starting point with no software procurement barrier and is a widely used real-world screen reader.
JAWS with a mainstream Windows browser.
JAWS remains especially relevant for enterprise and professional Windows environments.
VoiceOver with Safari on iOS.
Organizations with meaningful iPhone and iPad traffic should consider including this testing.
Organizations with significant Mac usage should also consider using VoiceOver with Safari on macOS.
Teams should treat each screen reader-browser pairing as a test environment rather than treating “screen reader testing” as a single universal check.
What does screen reader testing catch?
Screen reader testing asks: Can someone actually complete the task?
An automated test may confirm that a modal exists. A screen reader test can reveal that focus never moved into it.
A scanner may find that a form field has a label. A user may discover that an error appears somewhere else on the page and is never announced when the field fails validation.
All the information on a product card may technically be available. Yet, navigating through every image, rating, price, shipping message, and action, one element at a time, can make browsing painfully slow.
Michael encountered that exact issue while shopping online. The site split each product into separate announcements, which made the results inefficient to navigate. He adapted by switching his screen reader to move among product links instead.
A screen reader test should therefore look beyond whether the information is present and ask whether a user can move through it efficiently.
Why testing with experienced screen reader users matters
Using a screen reader as a testing tool is not the same as relying on one every day. Experienced users develop navigation strategies that a new tester may not know. They recognize when an interaction technically works but requires unnecessary effort. They also approach the experience with a real goal rather than following a test script.
UsableNet combines manual accessibility testing with testing by people with disabilities who regularly use assistive technology.
Build screen reader testing into the process
A strong testing process should define which screen reader and browser combinations matter for your audience, test key user journeys rather than isolated pages, document results consistently, and get findings to the development team for action.
Watch a live demonstration of a screen reader in this on-demand webinar.
Or, if you're ready to take action and make your website accessible, contact us.
