A screen reader is used by low to no vision users to hear the content of a website. Testing with a screen reader means listening to your web content rather than looking at it. Whilst the primary reason screen reader testing is conducted is to improve accessibility, it can also provide the development team a different perspective in which to look at our product. This different perspective can lead to finding bugs that would be harder or impossible to catch visually. Pairing a developer and QA not only shares accessibility testing knowledge, but also leads to quickly identifying and fixing bugs.
Here are some examples from my latest project:
HTML elements that should be removed
To visual users on the web page, the sentence looked correct: “Let’s change it”.
The screen reader (the combination was Chrome browser with VoiceOver) was reading out: “Let’s change it. Let’s [pause] change it”.
Let's <span>change it</span>
The source code showed a span was used around the phrase “change it” which resulted in it being read out twice by the screen reader. The span previously had CSS inside it. The CSS had been removed but not the span. Deleting the <span> cleaned up the code and stopped the screen reader repeating text.
Missing footer tag
Screen reader users have different ways of navigating the content other than just reading the page from start to finish. They make use of landmarks (such as <main>), headings, and images and other elements.
When looking at the webpage at a high level through its ARIA landmarks, we noticed the structure of the webpage was:
There was no footer element for the screen reader, although visually you could see a footer being presented. By replacing the <div> tag with a <footer>, the semantic structure became clearer for screen readers and developers:
Removing redundant alternative text
Alternative text is used by screen readers to describe images. This text isn’t surfaced to visual users of the web page in most circumstances (unless for example the image failed to load). When adding in ‘alt text’ for accessibility, you may not have the context around the text the screen reader will also read.
An icon we were using had the alt text “icon to copy this content to clipboard”. When using the screen reader on the popup where this icon was used on a button, the screen reader was reading: “icon to copy this content to clipboard Copy”. The screen reader first read the alt text and then the button text. In this situation, alt text was not needed so was removed. This made the button clearer for screen reader users.
Paired screen reader testing and fixing increased the team’s shared understanding of the code, led to more bugs being identified and fixed, and widened knowledge of accessibility and screen readers specifically. Whilst learning to use a screen reader can seem daunting, a walkthrough from someone who already knows how to use one goes a long way in bridging the gap. Next time your project conducts some accessibility testing, why not experiment with pairing to see what you may learn?
Further accessibility resources