How Screen Readers Work

Screen readers (a type of Assistive Technology) are both software and hardware that people use to interact with a computer. They convert text and graphics on a screen to speech or Braille output.

The iPhone has a screen reader built-in (VoiceOver for iOS), as do Mac computers and other devices. On Windows, users can employ the built-in screen reader Narrator or install third-party software like NVDA or JAWS.

When users turn on their device, the screen reader takes input from the platform applications in use: Settings apps, a Web Browser, YouTube, etc. and renders output aloud or in another a tactile device like a refreshable Braille display.

It’s quite amazing, really. We as develoeprs can do a huge service in making our software more screen reader accessible.

Read about screen readers from Daniel Göransson: https://axesslab.com/what-is-a-screen-reader/ (opens in a new tab)

• Browser & Assistive Tech (AT) combos -> nod to WebAIM surveys
• Using site analytics to narrow down a test matrix
• Platform similarities and differences (brief mention of accessibility APIs)

Platform Accessibility APIs

Each platform has its own platform accessibility APIs (Apple OSX, Apple iOS, Windows, Android) that translate input into speech output. It's a big part of how browsers work (opens in a new tab), in fact, as HTML (opens in a new tab) and ARIA (opens in a new tab) provide mechanisms to plumb accessibility information and structure through web pages.

One tangible difference with various accessibility APIs as a developer is that the output can vary from platform-to-platform. For example, the aria-haspopup state has wildly different results: https://www.matuzo.at/blog/2023/aria-haspopup/ (opens in a new tab)

Apple also has iOS web browsers locked down to only use Webkit under the hood (such as Mobile Chrome and Firefox). VoiceOver testing results can vary between Apple iOS webkit and browsers on a Mac computer.

The Accessibility Tree

The Accessibility Tree is a tree structure created with accessibility APIs and web browsers to expose relevant accessibility information. As you debug HTML and ARIA markup in Chrome or Firefox accessibility tools, you’ll see and work with this structure apart from the DOM. It contains information about the hierarchy of accessible nodes, roles, accessible names, states, and more. We’ll dive deep into this topic in the Enterprise Accessibility (opens in a new tab) workshop!

How to prioritize various platforms

Want to know which screen readers to test, with which browser combinations? Screen reader makers don’t share usage stats for privacy reasons. But we do have highly-respected survey data from the dedicated folks at WebAIM (opens in a new tab).

The WebAIM screen reader surveys can help you understand the types of Assistive Technologies that people with disabilities use: https://webaim.org/projects/screenreadersurvey9/ (opens in a new tab)

Cross-reference that with any analytics data you have for your site. Voilà, a semi-prioritized testing matrix emerges!

You could also check out AssistivLabs to run screen readers in the cloud: https://assistivlabs.com/ (opens in a new tab)