Choose your Screen Reader!
You teach me and I'll teach you, screen readers! It’s time to talk about the oh-so-dreaded screen reader testing. Will your code stand a chance?
It’s time to talk about the oh-so-dreaded screen reader testing. As already teased, braille displays peacefully coexist with text-to-speech (or TTS for short) screen readers. They are a staple for web access!
Screen Reader Output
So screen readers read what’s on the screen? Wrong! They read what you wrote into your code! While a software tester who uses a mouse and screen might not notice that your menu exit button is actually a styled div, the SR will. And it will not work.
This is where the accessibility tree comes into play. The accessibility tree is how SR users navigate through a website, climbing along heading levels and structures to find the desired information. The accessibility tree is sprouted by the browser based on the DOM (shorthand for Document Object Model) tree and accessed by platform-specific Accessibility APIs.
The DOM tree contains objects representing all the markup’s elements, attributes, and text nodes. This is precisely why following the h1, h2, h3 … heading structure is important. When you skip heading levels, you saw off the branches that assistive tech needs for a sound climbing route.
But not all screen readers are the same. Let’s briefly go over the differences in screen reader output: Below are 2 popular screen readers reading the same thing in the same browser and both outputting something different:
NVDA vs JAWS
The following table of our workshop at We Are Developers 2024. The code for it is available here SR Table Navigation on Julia’s profile CodePen.io/YuriDevAT You can download NVDA screen reader and follow along.
NVDA will say:
Choose your Starter Pokemon
Table with 4 rows and 3 columns
Choose your Starter Pokemon caption
and JAWS will say:
Table with 4 rows and 3 columns
Choose your Starter Pokemon
Column 1, row 1
Person
Same table, same code, same browser, yet 2 different outputs. That doesn’t mean that one is better than the other, they both get the job done. But be aware that there are some nuances between them.
Then what Screen Reader Setup is best for Testing?
Classic UX answer: it depends. For one on your target demographic, but more tangibly on the operating systems you are developing for. Every year WebAIM releases a survey for screen reader users where they ask which SR-browser combination they use.
The latest survey was conducted between December 2023 and January 2024, go check the Screen Reader User Survey #10 Results. While you’re at it, check out the WebAIM Million report as well. The Million report audited 1 million websites to give us a benchmark of progress in web accessibility over the years and the most common WCAG failures. (It’s still low contrast btw.)
TL;DR
JAWS and NVDA came out on top with 40.5% and 37.7% respectively and 3rd on the podium was VoiceOver with 9.7%. As for browsers, the big 3 are Google Chrome, Microsoft Edge, and Mozilla Firefox.
