Screen readers are complex applications that output text as audio or braille. They’re commonly used by people with vision disabilities — but not all people with low vision use screen reading software, and some screen reader users do not have vision disabilities.
Most screen readers have extensive options, which allow users to configure the software to match their needs and preferences. One of the most important settings is verbosity, which controls the amount of information that the software reads about each element.
How Screen Reader Verbosity Works (And Why It Matters)
Let’s say that you use a screen reader to review a website with WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) markup. The website has a navigation menu, which uses the ARIA navigation role.
Screen readers will recognize the menu and announce “Navigation landmark.” That's an example of verbosity: The software’s feedback includes semantic information, which tells the user how the page is structured. This can provide a more natural experience for users — they have access to information that’s visually available to other users.
Of course, some users may not want to hear every piece of information. At maximum verbosity settings, a screen reader might read all punctuation and all semantics, which can slow down the user’s experience. Some semantic feedback may be confusing, particularly if the website uses ARIA or semantic HTML incorrectly.
Many screen readers have separate settings for semantic verbosity and punctuation verbosity. Some products may provide additional levels of control, which give screen reader users more options for getting the perfect amount of feedback.
Related: 5 Myths About Screen Readers That Can Hurt Accessibility
How Web Design Decisions Affect Verbosity
As a web developer, designer, or content creator, your goal is to ensure that your website works predictably, regardless of how the user’s screen reader is configured.
If you’re not thinking about screen reader users when producing content, you might make mistakes that affect these people:
-
If you use an ARIA landmark role incorrectly, the user may hear the wrong information — and since landmark roles essentially tell screen readers “this is essential for navigation,” your website may not work as expected.
-
If you use semantic HTML incorrectly, users may become frustrated. For example, if you skip or misuse subheading levels, users may assume that they’ve missed information.
-
If you use semantic markup redundantly (for example, using both ARIA and HTML to define an element), screen readers may overload the user with too much information. You might miss this issue if you’re testing your content with low verbosity settings.
-
If you don’t provide enough semantic information, users who want that information will notice. Poor semantic markup can affect every user’s experience, but it’s particularly annoying for non-visual users.
You can avoid these mistakes by double-checking your markup — but if you don’t use a screen reader regularly, you shouldn’t rely on screen reader tests to reveal accessibility barriers.
Related: How Screen Readers Are Used in Accessibility Testing
Screen reader testing is important, but it requires expertise
Screen reader testing plays an important role in evaluating some of the subjective criteria in the Web Content Accessibility Guidelines (WCAG), the international standard for accessibility.
For example, a screen reader test might reveal issues with your WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) markup that wouldn’t trigger an error through an automated test.
With that said, testing with a screen reader requires significant experience. Without that experience, tests may result in false positives (accessibility barriers that don’t actually exist) or false negatives (accessibility barriers that aren’t revealed by the test).
While you may want to download a screen reader to develop your perspective, high verbosity settings can be overwhelming for sighted users — and low verbosity settings may not reveal enough semantics for practically useful results.
Related: Is It Okay to Hide Content from Screen Readers?
Creating a Complete Strategy for Web Accessibility Testing
At the Bureau of Internet Accessibility, our human testers have certifications for JAWS (Jobs Access With Speech) and NVDA (NonVisual Desktop Access), the two most popular screen readers.
It’s important to remember that web accessibility isn’t just about accommodating screen readers. WCAG also includes requirements that make content more useful for people with neurocognitive differences, hearing disabilities, and a wide range of other conditions.
While our process includes manual tests, we also leverage powerful automation as part of our four-point hybrid testing methodology. We believe that this approach provides the best path to sustainable digital compliance.
To learn more or to start building an accessibility strategy for your organization, send us a message.
