A screen reader is specialized software that converts digital text into spoken language or Braille. The technology is commonly used as a key accessibility tool for people who are blind or have low vision (and other users, as discussed below).
Even accessibility-minded web designers sometimes struggle to understand screen readers: who they’re for, why they’re important, and how to create content that survives the transition to non-visual output. That lack of information can disrupt the best-intentioned accessibility strategies. Here are some common myths about screen readers, along with the facts to help you design more effectively.
Myth 1: Everyone with blindness or low vision uses a screen reader to "listen" to content
It’s true that people with low or no vision may use screen readers with synthesized speech to access web content, documents, and apps, but some users prefer other assistive technologies.
Other options include screen magnifiers, refreshable Braille displays, high-contrast modes, or some combination of tools. This diversity of approaches means that it’s not enough to optimize content just for screen readers. Consider all the accessibility tools your users may employ. Also, make sure that the use of one assistive technology wouldn't unnecessarily interfere with another.
Myth 2: Only people with blindness or low vision use screen readers
According to a WebAIM screen reader user survey, people with blindness and low vision make up the majority of screen reader users with disabilities. However, more than 3% of survey respondents with disabilities reported cognitive impairments; 6% were deaf or hard-of-hearing; 2% had motor disabilities; and nearly 4% had other, unlisted disabilities. Around 16% reported multiple disabilities. Put simply, people with vision impairment aren’t the only ones using screen readers.
This survey also illustrated another important fact: People without disabilities use screen readers, too. More than 12% of respondents reported their use of a screen reader is not due to a disability at all. Screen readers can be helpful for people with lower literacy, for non-native speakers, and for anybody who prefers to listen to content in place of or in addition to other methods of reading.
Myth 3: You can sufficiently test accessibility with a single, in-app screen reader
Web browsers, document creation software, and app design tools may include their own screen readers. It can be tempting to conduct accessibility tests using these native features alone — but this rarely reflects actual user behavior.
Before accessing your content, users must open a web browser or app. They may use a screen reader to do so, and an in-app feature can’t help with this fundamental task. That’s one reason why some screen readers are built into operating systems, while others are third-party software. The effectiveness and capabilities of different screen readers also come into play, so testing only with an in-app screen reader is likely to miss issues or obstacles.
Testing your site, app, or document with a screen reader can be useful, but remember that a single test session will not reflect the different ways that actual users behave. Web designers should conduct testing on multiple combinations of screen readers and browsers, and on both mobile and desktop devices. They should also seek input from accessibility professionals and real-world users.
Myth 4: All screen readers are exactly the same
Not all screen readers are compatible (or as compatible) with every operating system, browser, and app, and user interfaces can differ considerably. Someone who’s adept at Apple’s VoiceOver may encounter a learning curve when switching to Android’s TalkBack. Users will have their favorites, which is another reason that developers shouldn’t test their content in a single computing environment.
The most common screen readers for desktops and laptops are NVDA, JAWS, and VoiceOver on Mac, and dozens of other assistive tools are available. These tools may interpret the same content in slightly different ways.
Myth 5: Content is automatically compatible with screen readers
Screen readers can’t interpret content without the right contextual information — alt tags for every image, proper use of heading tags, and appropriate deployment of Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA, or more commonly just ARIA) in HTML may all be necessary for a good screen reader experience. These three examples are far from comprehensive, but hopefully demonstrate the point.
Screen readers are powerful, but they can only function as well as the content they’re interpreting allows. Great web development can help. Building a site that operates smoothly with screen readers requires plenty of testing, but it starts with understanding — and avoiding assumptions about assistive technologies.
