How to test with a screen reader

If you are not visually impaired, chances are you may never have come across a screen reader or text-to-speech tool. While it is hard to estimate exactly how many people regularly use screen readers, approximately 2.2 billion people worldwide experience some form of vision impairment, including millions who are blind or have moderate to severe vision loss. So if someone asks about the value of screen reader testing, these numbers highlight just how many people may be affected by accessibility barriers. 

Some common tools available 

JAWS (Job Access With Speech) is the most common, with around 40% of the market share. NVDA (NonVisual Desktop Access) is a free and open-source tool from NV Access. You can learn about it and other free tools at WebAIM (Web Accessibility in Mind). Apple have VoiceOver built into its systems, and Android have TalkBack. There are a number of text-to-speech tools, and some browsers have them built in. There is a wide choice, and they all have some variance in use, but the primary functions are the same. 

So in this post, I’ll explain how they work. How they sound, as you will find it is not just what is on the screen being announced, as well as some tips on getting started. Including, a slightly embarrassing story involving me and a train carriage. 

What do screen readers say?

Screen readers can sound a little strange when you first hear them. People who use them every day can hear things much faster than we testers ever will. Partly because they use them all day, every day. Watching someone hear 300 or more words a minute is like hearing another language. So when you begin and struggle to follow, just remember you can see to help you. 

The tools announce lots of things that us sighted users simply take for granted because we can see them. Information such as whether a field is empty or already populated, whether something is a button or a link (or a previously visited or broken link!), and whether a piece of text is a heading all needs to be spoken aloud. Even the heading level is spoken to help with navigation. Those extra details help screen reader users build a mental picture of the page and navigate it efficiently. 

You may be surprised to find out that one of the most powerful features of a screen reader is that it doesn't force users to read a page from top to bottom. Instead, it can announce and navigate by different types of content. I’ve mentioned headings and links, but buttons, form fields, and tables are also options. A user might bring up a list of all headings on a page to jump straight to the part they want, browse only links, or move between form fields. 

Screen readers can also announce additional information such as whether a link has been visited, whether a button is disabled, whether a menu is expanded, or even additional instructions a sighted person might not need. Think of it like switching between different maps of the same city. One map shows roads, another shows train stations, and another highlights tourist attractions. The information is the same, but the way you explore it changes depending on what you're trying to achieve. 

A simple login screen with a screen reader

A simple login form will have the usual email and password fields. A sighted user can glance at the screen and immediately recognise both fields, see their labels or placeholders, and notice, if visual location indicators are present and of good quality, which field has focus. A screen reader has to communicate all of that information through speech. To begin, when the page loads and the user begins navigating, they will hear the page's name. Typically, ‘login’, ‘sign in’, etc. When a user tabs into the first field, normally the email field, they might hear something like, “Email address, edit, blank, required.” 

Let’s take a second to think about the information we have just received. ‘Email address’ is the title of the field, so we know where we are. ‘Edit’ tells us the field is editable and we can enter information. ‘Blank’ means no information has been entered yet. ‘Required informs us that we must populate it to successfully submit the form. Four separate pieces of information need to be audibly communicated so the person has what they need to enter their email address or username. Let that sink in for a moment. Then think of all the other elements you encounter on a web page or app. 

If they type their email address and move on, the screen reader may then announce, “Password, edit, protected, blank, required.” The word “protected” tells the user that the field will hide characters as they type. Similar field, but additional information communicated. This time, five pieces of info to complete the picture. It’s no wonder I’ve had many conversations with people who really struggle with using screen readers. I can promise you, with persistence over time and practice, you'll get more comfortable using them. Another skill to add to your CV, and you may find a bug that helps someone you will never meet. 

The same principle applies across the rest of the page. A screen reader might announce “Heading level one, Welcome back”, followed by “Heading level two, Sign in”, allowing users to jump between sections quickly without listening to every word on the page. At first, this can feel repetitive or overly detailed, but those announcements provide the context, structure and navigation cues that make the web usable for people who cannot rely on sight alone. In many ways, the screen reader describes the page the way a tour guide might describe a room, helping users understand not just what is there, but how everything fits together. 

A few hard-earned tips 

I’ll start with the embarrassing one. On desktop, it is relatively simple to turn screen readers on and off, as your mouse works the same way in either mode. On mobile, not so much! On mobile, the toggle for screen readers is way down in accessibility settings. It sounds easy to get to it and turn it on, doesn’t it? Well, it is. But turning it off is completely different if you don’t know the tip I will share. 

When a mobile is in screen reader mode, the screen turns into a trackpad of sorts, and you navigate with finger swipes and taps. Using one, two, or even three or four fingers can change the input. Swiping shapes rather than left or right means something else again. If you are unprepared, you can be stuck in a train carriage with no headphones, desperately trying to turn screen reader mode off and getting very strange looks as your phone reads out elements, status, etc. 

Did I keep a cool head and think to simply turn the volume down? Of course not. I was in full panic mode, wondering if I'd ever be able to use my phone again. Of course there was a simpler way than me fumbling for ages (in reality, maybe 5 minutes or so). So that’s my number one tip below. Hope you like the others. 

• Identify the shortcut to turn your mobile phone screen reader mode on and off. Some are volume and power button combinations. On my iPhone, it's three taps on the back of the phone. Whatever it is, make sure you know it. 
• Get a keyboard or mobile gesture cheat sheet and keep it nearby while you test. I had a few on my desk when I began, and they were invaluable. There are quite a few available. 
• Most tools have a tutorial. Take it. You will thank me. 
• Start slowly and in familiar territory. Go to a screen you know well. Turn on the screen reader, navigate slowly through the screen, and carefully listen to each step. If you need to, search for something you are not sure about to help you understand. 
• Build up timed sessions. Start with 5 minutes, then take a break. I found concentrating quite draining at first and had a few headaches. Nothing too bad, but building up over time helped me a lot. 
• Try not to use the mouse. Someone who cannot see doesn’t use a mouse. In general, I’d recommend spending some portion of your week doing your normal testing without a mouse. You might be amazed by what you might find. 
• When your confidence grows, try different modes of navigation, links, headings, etc. Links can be tricky if they all say ‘here’ or ‘click here’... 
• Adjust the speech rate. You can slow it down to under 1x in the beginning, or speed it up as you build your skills. 

How to test with a screen reader

Now you have those tips, let’s talk testing. Some things you can test for will feel familiar. Heading level consistency and logical order might become more obvious with a screen reader. Visually, we can see them, but a jump from a level 3 heading to a level 5 one might not be that obvious. If you can hear them announced, you can’t miss it. And there is only one H1, of course, unless there are specific independent regions. 

Confirming that all semantic HTML is announced becomes straightforward. Does it say header, main, footer, etc. Labels are clear and descriptive. Sometimes submit is a fine label name, sometimes not. Context will tell you. Pop-ups, error messages, and real-time updates like search results can be tricky, so making sure those announcements are clear is vital. Anything you need to know but aren't told is an issue. As is things announced twice. That usually indicates one announcement should be hidden, like an icon on a button. 

Another key thing to be on the lookout for is inconsistent journeys. A keyboard or audio journey should match a sighted, mouse user journey. If there are differences beyond providing the same or equivalent information, you may have a problem to flag. 

Questions to ask as you test 

Headings: 

• Can you navigate by headings? 
• 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 a lot wider than most folks are aware of. Using them, or any assistive technology for accessibility testing, can help you uncover quality issues that only visual testing might never find, such as application structure bugs. Some of those found issues could affect overall quality, not just screen reader users. Testing is risk mitigation to find issues before our customers do. Screen reader compatibility is a risk that we can consider if we use empathy and inclusive testing. While this is just one small aspect of digital accessibility, it is something, like a lot of accessibility,  that you don’t need to be an expert to do. Don’t think of it as just an accessibility tool. For testers, it is another opportunity to explore in a different way and find information and knowledge we might otherwise miss. 

Hopefully that has inspired you to try screen readers. If you do, I’d love to hear how it goes. Until next time, test inclusively.