Screen reader testing: from first steps to a test log

First, set up a test environment you know

On Windows, for example, you can use NVDA; on the Mac, VoiceOver is built in. Use the official guide for your software and start by learning how to start and stop it, navigate element by element and interrupt speech output. Keyboard shortcuts differ by operating system, keyboard layout and settings. Avoid learning a new website and the basics of the screen reader at the same time.

Note the screen reader, browser, operating system and their versions. These details help others reproduce the issue. A finding from one combination must not be applied to every browser and assistive tool without further testing.

Choose a task with a clear end

A good first test is: “Find the opening hours and then send a contact request.” Provide a suitable test environment so that no unintended messages or bookings are created. Define which information and actions are needed to complete the task successfully. Test the page first in its normal presentation; you can examine personal adjustments or an additional menu separately afterwards.

Understand the page through its structure

Explore the page title, the main regions and the headings. Screen readers offer their own ways to jump to these elements: NVDA uses single-letter keys in browse mode, among other things, and VoiceOver offers the rotor. Check whether the headings name the sections meaningfully. A visually large line without the right HTML structure does not help with this kind of navigation.

Then move through the links or form elements. Repeated labels such as “More” become a problem when the context is lost while navigating. So assess the label that is actually announced, together with the context available.

Run through input, errors and success

1. 1Reach every required form field and listen to whether its name, purpose and, where relevant, required status are clear.
2. 2Trigger a typical error and check whether the cause and how to fix it become clear.
3. 3Open a dialog and check orientation, available actions and the way back after closing it.
4. 4Submit valid test data and check whether completion is understandable without seeing a colour change.
5. 5Repeat dynamic changes, such as filter results or a basket update, and note missing or disruptive announcements.

Write a useful ticket

Don't just write “The screen reader reads it wrong”. A helpful ticket gives the URL, the task, the exact steps, the expected information and the output you actually heard. Example: “After submitting without an e-mail address, an error appears visually; when moving on with Tab, this message is not conveyed at the e-mail field.” Add the name of the affected field and the test environment. That lets the developers investigate the technical cause directly.

Add real-world experience to your own tests

An introductory test helps your team spot problems and verify changes. It replaces neither a full WCAG evaluation nor the experience of people who use screen readers every day. For important processes, plan tests with suitable users. After the fix, compare the same task in the same environment and note which other combinations are still open.