An introduction to screen readers
What are screen readers?
Screen readers are a form of assistive technology that read aloud the text displayed on a computer screen. Contrary to popular belief, screen readers are not just for the blind. A study by WebAIM in October 2017 showed that while 75% of respondents are blind, the remaining disability types included visual impairment, deafness, cognitive and motor.
While screen readers can be used to navigate an entire operating system, I will focus on their use on the Internet, explaining how they are used, how they work, how to structure content for them and how to test with screen readers.
(As an added bonus, screen readers can also be used to proof-read your own work; if that isn't a good enough reason to delve into this technology then I don't know what is.)
Types of screen readers
Desktop screen readers
Based on the 2017 study by WebAIM ("Screen Reader User Survey #7 Results." webaim.org), the three most popular desktop screen readers amongst the surveyed participants were:
Of the three, JAWS and NVDA only support Windows operating systems, with VoiceOver being exclusive to macOS and developed in-house by Apple.
Most Linux distributions include the Orca screen reader by default ("Orca." wiki.gnome.org), though there are several other alternatives available to download. There is even ChromeVox, a screen reader developed by Google for their line of Chromebooks ("Introducing ChromeVox." chromevox.com).
The differences between screen readers come down to the number of supported languages, what types of speech synthesisers1 are used and support for third-party integrations and special content types (such as images, PDFs and MathML).
Some screen readers offer features such as the ability to provide feedback on text formatting, or a wizard that uses voice to guide the installation process.
The main difference between screen readers is how they navigate content. Most will primarily use the keyboard for navigation, but the keybindings and actions will vary between them.
Braille displays
Some desktop screen readers include support for refreshable Braille displays. These are small devices that plug in to the computer and work with the screen reader to print the textual content on a website as tactile Braille.
Electronic pins move up and down accordingly to represent the on-screen text. People can also interact directly with the controls on Braille display to instruct the screen reader to move through the text ("Braille." visionaustralia.org).
Mobile screen readers
Screen readers are also available on mobile devices with touch screens. The iOS and Android operating systems each come with their own built-in screen readers, VoiceOver and TalkBack respectively.
Mobile devices have an added layer of difficulty due to the lack of haptic feedback and the presence of a soft keyboard. Screen readers rely on hand gestures and patterns that make use of specific finger movements and combinations as opposed to key combinations.
As an example, a person needs to move a single finger across the screen to announce what item they have hovered over (and what action will be performed, if applicable) before they can select or commit an action via a double tap anywhere on the screen.
Unfortunately, using a screen reader with a mobile devices introduces another layer of cognitive load on the user but the same practices used when creating accessible interactions on the desktop apply to mobile devices regardless.
Semantic HTML, avoidance of complexity (especially with the use of complex touch gestures) and good copy writing/low interaction costs will all help to improve the mobile screen reader experience. (Sherwin, Katie. nngroup.com)
How are screen readers used?
The majority of screen reader users are those with blindness or visual impairment. They can also help people with learning disabilities, such as dyslexia ("Screen Readers." dyslexiatech.com), or even those who suffer from screen fatigue.
Screen readers are all primarily driven via keyboard input. Because they run on an operating system level, the number of available commands is quite lengthy. To list and compare them would be beyond the scope of this article, but in terms of web browsing, most screen readers will allow a user to:
- read and skip through text at varying intervals;
- list content on a page, such as headings, to provide an overview; and
- navigate across elements such as:
- headings;
- lists;
- links;
- forms or form fields;
- buttons; and
- graphics.
Optimising websites for screen readers
Set the correct language
Always ensure that the correct lang definition is set on the <html> element.
Marking the incorrect language can affect the pronunciations of words and be
distracting to the user, or make the content incomprehensible.
When inserting content that is in another language, be sure to change the value
of the lang attribute for that content:
<p>This paragraph is English, but the language is not specifically defined. It
will inherit the value of what is set on the <html> element.</p>
<p lang="fr">Ce paragraphe est défini en français.</p>
Write content for a linear experience
Unlike sighted browsing, where users often skim or jump across a page within milliseconds, screen readers can only consume content in a single direction. When writing content, construct it in such a way that it will make sense when read from start to finish.
Things to avoid
Over-engineering
Most accessibility can be catered for using semantic HTML and logically ordering content. ARIA labels are for when additional information needs to be conveyed, such as describing page changes or labelling dynamic content. However, ARIA labels can be misused due to a lack of understanding, which results in the following:
No ARIA is better than Bad ARIA
The WAI-ARIA Authoring Practices 1.1 provides extensive examples for a variety of accessible design patterns, including how to best implement keyboard navigation for dynamic components.
Stereotypes and prejudice
Diving in to screen reader accessibility with a preconceived idea of who will be using it can be detrimental to a person's experience on a website. An example of this would be providing assistive text that makes the assumption that the person is blind.
There is no set list of reasons for why a person will be using a screen reader. Rather than building a website to accommodate one or two target groups, it is better to develop to the expectations of screen reader software and existing web standards.
Problematic items
Some elements that have become common occurrences on websites can cause issues with screen readers, or make website navigation virtually impossible. The 2017 survey by WebAIM ("Screen Reader User Survey #7 Results." webaim.org) collated a list of the most common culprits of accessibility issues, which included:
- CAPTCHA;
- screen changes and updates;
- ambiguous wording on links and buttons;
- Flash content; and
- a lack of keyboard accessibility, e.g. navigation.
In many cases, tools such as CAPTCHA are widely used and the accessibility concerns are easily forgotten due to how prevalent they are. Google's reCAPTCHA does address accessibility ("Accessibility." support.google.com), but other third-party scripts may not be as thorough in their support.
Performing screen reader testing
Having first-hand experience of a screen reader is a useful skill to have. It allows the developer to quickly debug screen reader issues without the need for an external resource or subject matter expert.
However, as WebAIM writes in its article, "Designing for Screen Reader Compatibility":
Using any screen reader for the first time can be a confusing and discouraging experience. […] much of the content on a web page will seem to be inaccessible, when in fact the problem may be that the new user simply does not know how to use the screen reader.
Testing with a screen reader is not something that can be approached haphazardly. Without an existing knowledge of how screen readers work, what may seem like a bug could just be a setting in the browser or how the screen reader interprets content.
In most circumstances, a single developer cannot be expected to learn about multiple screen readers (including how they work and their shortcuts) as well as taking note of any platform, browser and screen reader specific bugs.
A better approach is to ignore specifics and run screen reader tests using default configurations. This approach will still provide insight into the accessibility of a website without the need for investing time into learning every tool.
Incorporate "power user" testing
Engaging with people who use screen readers on a daily basis is a quick way to test website accessibility without any developer training. Running user tests with these people will provide a clearer insight into exactly how accessible a website is by people who use screen readers on a regular basis.
Use accessibility evaluation tools
There are a variety of tools available for evaluating a website's accessibility. The World Wide Web Consortium (W3C) has compiled a list of vendors that serves as a good starting point for finding tools for specific scenarios and test cases. ("Web Accessibility Evaluation Tools List." w3.org)
It is important to note that automated testing is not enough, as WebAIM states:
No automated evaluation tool can tell you if your site is accessible, or even compliant. Human testing is always necessary because accessibility is about the human experience.
WAVE, axe and AChecker are all popular choices that cover a broad spectrum of accessibility issues that do not require extensive configuration and will improve the experience of screen readers.
Some of these tools come in the form of browser extensions that can highlight issues such as colour contrast and incorrectly used ARIA roles directly on the page. axe (by Deque) and WAVE (by WebAIM) are both popular and trusted extensions that support up-to-date installations of Chrome and Firefox.
The future of screen readers
As the boundaries of what makes a "website" are continually pushed, creating accessible interactions can feel increasingly more difficult. But it is our duty to ensure that what is created is accessible to everyone. The web is a platform that anyone can access and nobody should be excluded, regardless of the content.
That being said, as websites progress forward, so too do other technologies. Conversational user interfaces are now a real, tangible experience thanks to Apple's Siri, Amazon's Alexa, Microsoft's Cortana or (the appropriately named) Google Assistant. These virtual assistants are speech driven, but could likely move towards other input methods for those where voice commands would be limiting.
Artificial intelligence could also be integrated into screen reader technology; they would become much more than just tools that read text. They could visually optimise the page for the user or present information in a conversational format (e.g. using the user's name when confronted with an option; "Hey Bob, which one of these options should I pick?"). (Frederiksen, Pierre. visionaustralia.org)
There may even come a time when they are so intelligent that ARIA attributes become unnecessary. For now though, we should stick with what we know will work. Web accessibility should not be abandoned, but it might change. Developers will need to change and adapt with it to ensure the best experience is had by all.
Works cited
"Accessibility." reCAPTCHA Help, Google, https://support.google.com/recaptcha/answer/6175971?hl=en&ref_topic=6081879. Accessed 23 October 2018.
"Accessibility." MDN Web Docs, Mozilla, https://developer.mozilla.org/en-US/docs/Web/Accessibility/. Accessed 16 October 2018.
"Accessibility Evaluation Tools." WebAIM - Web Accessibility In Mind, Center for Persons with Disabilities, https://webaim.org/articles/tools/. Accessed 26 October 2018.
"Braille." Vision Australia. Blindness and low vision services, Vision Australia, https://www.visionaustralia.org/information/adaptive-technology/using-technology/braille/. Accessed 28 April 2018.
"Designing for Screen Reader Compatibility." WebAIM - Web Accessibility In Mind, Center for Persons with Disabilities, 21 April 2017, https://webaim.org/techniques/screenreader/. Accessed 16 October 2018.
Frederiksen, Pierre. "Screen readers of the future." Vision Australia. Blindness and low vision services, Vision Australia, https://www.visionaustralia.org/services/digital-access/blog/screen-readers-of-the-future. Accessed 26 October 2018.
Gallo, Sofia. "How Various Screen Readers Work on Mobile Devices." Equal Entry, Equal Entry, 7 November 2017, https://equalentry.com/how-various-screen-readers-work-on-mobile-devices/. Accessed 19 May 2018.
"Introducing ChromeVox.", ChromeVox, Google, http://www.chromevox.com/. Accessed 23 October 2018.
"Orca." Projects/Orca - GNOME Wiki!, The GNOME Project, 9 February 2018, https://wiki.gnome.org/Projects/Orca/. Accessed 28 April 2018.
"Screen Readers." Dyslexia Tech, 28 October 2016, http://www.dyslexiatech.com/gadgets/screen-readers/. Accessed 15 May 2018.
"Screen Reader User Survey #7 Results." WebAIM - Web Accessibility In Mind, Center for Persons with Disabilities, 21 December 2017, https://webaim.org/projects/screenreadersurvey7/. Accessed 25 April 2018.
Sherwin, Katie. "Screen Readers on Touchscreen Devices." Nielsen Norman Group, Nielsen Norman Group, 30 August 2015. https://www.nngroup.com/articles/touchscreen-screen-readers/. Accessed 25 June 2018.
"Web Accessibility Evaluation Tools List." Web Accessibility Evaluation Tools List, W3C, March 2016. https://www.w3.org/WAI/ER/tools/. Accessed 26 October 2018.