Screen reader testing

A screen reader turns the interface into speech or braille. On iPhone and Mac it is VoiceOver, on Android TalkBack, and on Windows most often NVDA or JAWS. The user does not look at the layout. They swipe or press keys to move from one element to the next, and the reader announces each element's name, its role (button, link, heading, switch) and its state (selected, expanded, busy). Testing checks that this spoken version of the app is complete, in a sensible order, and lets the user finish every task.

Most of what a tester hears comes from the code. On the web, the accessible name comes from the HTML element, its label or ARIA attributes. In a native or React Native app it comes from properties such as accessibilityLabel and accessibilityRole. A screen can look correct and still be announced as button, button, button, or read as one long block that the user cannot split into separate controls. WCAG 4.1.2 Name, Role, Value requires each control to expose its name, role and state or value to assistive technology, and 4.1.3 Status Messages requires messages such as file uploaded or an error count to be exposed so that the reader can announce them without moving focus.

Each reader behaves differently. VoiceOver and TalkBack differ in how they announce switches, radio buttons and live regions, and the same React Native component can work on Android and fail on iOS. For that reason a test plan names the readers and platforms, and each issue is reported with the platform, the reader and its version.

Automated scanners find missing labels and low contrast, but they cannot say whether a screen makes sense when heard. Requirements for an app you are ordering:

• The contract names the readers and platforms: for example VoiceOver on the current iOS, TalkBack on Android, and NVDA with one browser for the web app.
• Every control has a label that names its action, such as delete document for a trash icon, and labels are reviewed like any other content.
• Every screen has a defined first focus position, usually the title or the back button, and moving between screens announces where the user is.
• Errors and progress are announced automatically. A timer or counter that changes every second needs a deliberate rule, or the reader will interrupt itself.
• The test plan covers whole tasks, such as registering, ordering a service or uploading a document, not single screens.
• Tests happen during development, and the final round includes users who rely on a screen reader every day. A tester who uses VoiceOver occasionally hears a different app than someone who uses it all day.
• Each round ends with a list of issues with platform, reader, steps and expected announcement, and a retest that closes or reopens each one.

For Centrum Komunikacji we build the mobile and web apps that connect deaf, hard-of-hearing, blind and deafblind users with sign language interpreters. The requirements name WCAG 2.1 AA and compatibility with screen readers and braille displays, so screen reader testing runs through the whole project.

Testing on iOS in November 2025 found that the main content was read as one element, so the user could not choose a single tile; the fix passed retests on iOS and Android in December 2025. TalkBack showed meeting list buttons labeled with a leftover placeholder, and on iOS form fields did not accept input from a braille keyboard. A VoiceOver round between January and March 2026 found error pop-ups that were never read, a phone number announced as millions and thousands, and radio buttons that repeated their state three times. Fixes from that round were retested in March 2026, and the next round's findings were closed in May 2026.

In September 2026 a blind accessibility expert working with the client tested the production app on iOS and Android. Service tiles were announced only by their shared button text, so the user heard the same word on every tile. We changed the tile labels and retested them on both platforms.

For PSONI we test the web and mobile apps of Generator ETR, which simplifies documents into easy-to-read Polish. The web round closed on October 6, 2026, with its report turned into a separate task for fixes. The mobile round, in testing in October 2026, covers points such as errors that are not announced and a resend-code counter that the reader announces every five seconds.