Learning source: Ady Stokes, “How to Test with a Screen Reader,” WonderProxy Blog, October 14, 2026. This article follows the source’s order and keeps the author’s beginner tips and testing questions. Original: https://wonderproxy.com/blog/how-to-test-with-a-screen-reader/
If you are not visually impaired, you may rarely come across a screen reader or text-to-speech tool. The source mentions that about 2.2 billion people worldwide have some form of vision impairment, including millions who are blind or have moderate to severe vision loss. Stokes also says it is hard to estimate how many people regularly use screen readers. The figure points to the reach of accessibility barriers; it is not a count of screen reader users.
Some common tools
| Tool | Common platform | Note |
|---|---|---|
| JAWS (Job Access With Speech) | Windows | The source calls it the most common and reports about 40% market share; it does not state the estimate’s date or sample. |
| NVDA (NonVisual Desktop Access) | Windows | A free, open-source tool from NV Access; WebAIM lists accessibility tools and resources. |
| VoiceOver | Apple systems | Built into macOS and iOS. |
| TalkBack | Android | Built into Android. |
There are also text-to-speech tools, and some browsers include read-aloud features. Tools vary in how they work, but their main functions are similar.
What do screen readers say?
Screen readers can sound strange the first time you hear one. People who use them all day, every day can follow speech much faster than a tester who is just learning. Some can listen to 300 or more words per minute. At first, that can sound like another language. Stokes reminds beginners that they can still look at the screen to help them understand; there is no need to match an experienced user’s speed.
Screen readers announce details that sighted users usually get by looking: whether a field is empty or already filled in; whether an element is a button or a link, including whether a link has been visited or is broken; and whether text is a heading and what level it has. Those details help users build a picture of the page and navigate it.
Users do not have to listen from top to bottom. A screen reader can navigate by headings, links, buttons, form fields, or tables. A user can open a list of headings and jump to a section, browse only links, or move between form fields.
Screen readers can also announce whether a link has been visited, a button is disabled, a menu is expanded, or an instruction is present that a sighted user might not need. Stokes compares this to switching between maps of the same city: one shows roads, another train stations, and another tourist attractions. The information comes from the same place, but the view changes with the task.
A simple login screen with a screen reader
A simple login form usually has email and password fields. A sighted user can glance at the page, see the labels or placeholders, and notice which field has focus if the visual indicator is clear. A screen reader has to communicate those details through speech. As the user starts navigating after the page loads, they will typically hear the page name, such as “Login” or “Sign in.” When they move to the first field, often the email field, they might hear:
Email address, edit, blank, required.
That announcement carries four pieces of information. “Email address” identifies the field; “edit” means it accepts input; “blank” means nothing has been entered; and “required” means the field must be filled in to submit the form. The user needs those details to know where to enter an email address or username.
After entering an email address and moving to the password field, the screen reader might say:
Password, edit, protected, blank, required.
The announcement carries five details: the field name, that it accepts input, that its contents are protected, that it is empty, and that it is required. “Protected” tells the user that typed characters will be hidden. Testers can also listen for headings, such as “Heading level one, Welcome back,” followed by “Heading level two, Sign in.” These announcements may feel repetitive or overly detailed at first, but they provide the context, structure, and navigation cues that people who cannot rely on sight need. Stokes compares the screen reader to a tour guide describing a room, helping the listener understand both what is there and how it fits together.
With practice, these announcements become easier to follow. Stokes describes screen reader testing as another skill testers can build, and one that may help them find a bug affecting someone they will never meet.
A few hard-earned tips
Stokes starts with an embarrassing story. On desktop, turning a screen reader on and off is relatively simple because the mouse still works in that mode. On mobile, the toggle is buried in accessibility settings, and turning it off can be much harder if you do not know the shortcut.
In screen reader mode, a phone works more like a trackpad: users navigate with swipes and taps. One, two, three, or four fingers can change the input, as can the shape of a swipe. Stokes found himself in a train carriage without headphones, trying to turn off a screen reader while his phone announced elements and status information. He panicked and did not think to lower the volume. It took him about five minutes to find a way out.
- Learn the on/off shortcut first. Some phones use a volume and power button combination. Stokes’s iPhone is set to toggle the reader with three taps on the back.
- Keep a keyboard or gesture cheat sheet nearby. Stokes found these useful when he was starting out.
- Take the built-in tutorial. Most screen reader tools have one.
- Start slowly on a familiar page. Turn on the reader, move through the page, and listen carefully. Look up anything you are unsure about.
- Build up timed sessions. Start with five minutes, then take a break. Stokes found that concentrating was tiring at first and sometimes gave him a headache, though nothing too serious; gradually increasing practice time helped.
- Try not to use the mouse. Stokes’s point is that someone who cannot see does not rely on a mouse. He recommends doing some normal testing each week without one; testers may be surprised by what they find.
- Try different navigation modes as you gain confidence. Links can be hard to understand out of context when they all say “here” or “click here.”
- Adjust the speech rate. Beginners can slow it below 1x, then increase it as they gain experience.
How to test with a screen reader
Some checks will feel familiar. Heading levels and order may become easier to assess by listening. A jump from a level-three heading to a level-five heading can be hard to spot visually, but obvious when the levels are announced. Stokes recommends one H1 per page unless it contains specific independent regions.
Check whether semantic HTML is announced, including regions such as header, main, and footer. Labels should be clear and descriptive. “Submit” may be a suitable label in some contexts; in others, it may not. Pop-ups, error messages, and real-time updates such as search results can be difficult to follow, so check whether the announcements are clear. Anything users need to know but are not told is a problem. Duplicate announcements also need attention; Stokes says they usually mean one item should be hidden, such as an icon on a button.
Look for inconsistent journeys, too. A keyboard or screen reader journey does not need to use the same steps as a sighted, mouse-driven journey, but it should provide the same or equivalent information. If a difference prevents that, flag it.
Questions to ask while testing
Headings
- Can you navigate by heading?
- Does the hierarchy make sense?
Forms
- Are labels announced?
- Are required fields announced?
- Are validation errors announced?
Dynamic content
- Are search results announced?
- Are error messages announced?
Links
- Do links make sense out of context?
To sum up
Screen reader use is more widespread than many people realize. Testing with screen readers or other assistive technology can uncover problems that visual checks miss, such as issues with application structure. Some of those issues may affect overall product quality and other users too. Stokes describes testing as a way to mitigate risk by finding issues before customers do. He recommends considering screen reader compatibility with empathy and inclusive testing. It is one part of digital accessibility, and testers do not need to become experts before they start. For testers, a screen reader is another way to explore a page and find information they might otherwise miss. Stokes encourages readers to try one, share their experience, and keep testing inclusively.
References
- Ady Stokes, “How to Test with a Screen Reader,” WonderProxy Blog, October 14, 2026: https://wonderproxy.com/blog/how-to-test-with-a-screen-reader/
- WebAIM, accessibility tools and resources: https://webaim.org/
Ady Stokes is a Ministry of Testing Ambassador and accessibility advocate. At the time of the source article, he had contributed to quality and testing for nearly 25 years.