What should I keep in mind when testing with screenreaders?

Testing with ScreenReaders

When using a computer, people with visual impairments rely on screenreaders. Especially when visiting various websites, this user group often encounters obstacles that assistive technologies cannot overcome. Nested content or poor code quality often prevents them from finding relevant information.

Analysis tools such as browser plugins can uncover structural errors on a website that are relevant for accessibility and screenreaders. However, content-related issues or interaction limitations cannot be tested automatically. Therefore, accessibility tests should always include manual evaluations using screenreaders.

Choosing a ScreenReader

There are several screenreaders available. According to WebAIM statistics, JAWS and NVDA are the most widely used. JAWS is a paid software, while NVDA is a free alternative for Windows systems. Windows also comes with a built-in screenreader called Narrator. On Apple systems, VoiceOver is preinstalled.

Browser plugins like ChromeVox are also available, but they are used less frequently by the target user group compared to system-wide screenreaders. It’s important to note that screenreaders differ in both functionality and the way they output information. Therefore, testing with multiple tools is recommended.

The choice of screenreaders depends on various criteria: What operating systems are the users working with? What browsers are they using? What settings are configured in the screenreader? Understanding the user group is key here. Ideally, users are involved early in the development process. If direct communication is not possible, there are many studies and reports available online that provide valuable insights.

Planning and Conducting the Test

First, the screenreader and, in the case of a website, the browser to be used must be selected. Then, a precise test scenario should be defined. The goal is not to evaluate the entire website in one session, but rather one or two typical usage scenarios. Navigation usually takes place via arrow keys or keyboard shortcuts. However, there are cases where users operate screenreaders with a mouse or touchpad. Testing on mobile devices is a separate topic and is not covered in this article.

To put yourself in the user’s perspective, you should close your eyes or look away from the screen during testing. A distraction-free environment is essential. System notifications or chat messages can shift the screenreader’s focus, which may require restarting the test.

If the user loses orientation on the website or cannot proceed further during testing, the test must be stopped. These are considered critical issues that must be addressed.

Findings and Benefits

Testing with a screenreader uncovers many issues that code analysis tools cannot detect – such as missing alternative texts for images. It also provides a direct experience of the user interface, which can sometimes be frustrating.

Test results should be documented in writing and shared with the team. This helps build a deeper understanding of different user perspectives and enables more targeted attention to accessible and frustration-free design from the early design stages onward.