QualiBooth

Assistive Technology

Multi screen-reader evaluation

Screen readers don't all behave the same way. A page that reads perfectly in VoiceOver can be unusable in JAWS. We test across the major readers so every user gets a coherent experience.

Talk to an expert Free URL scan
Abstract visualization of audio waveforms representing multiple screen readers announcing a web page.

What you get

01

All major screen readers

Evaluation across NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android — the combinations your users actually run.

02

Announcement accuracy

We verify that names, roles, states, and value changes are announced correctly — not just that an element technically exists in the accessibility tree.

03

Focus & reading order

We check that focus moves logically, that dynamic updates are announced, and that the reading order matches the visual intent.

04

Custom widget testing

Menus, modals, comboboxes, tabs, and carousels are tested against the ARIA Authoring Practices and against real reader behavior.

05

Cross-reader differences

Where readers diverge, we document the discrepancy and recommend the markup that works consistently everywhere.

06

Actionable findings

Each issue includes the reader, browser, steps to reproduce, what was announced, and what should have been announced.

A clean automated report does not guarantee a usable experience for screen-reader users. Multi-screen-reader evaluation is how you confirm that your interface is announced clearly and navigable for the people who depend on it.

Why one screen reader isn’t enough

NVDA, JAWS, VoiceOver, and TalkBack each interpret ARIA and HTML semantics differently and are typically paired with different browsers. A custom combobox that JAWS announces perfectly may go silent in VoiceOver; a live region that updates politely in NVDA may interrupt constantly in another reader. Testing a single reader gives a false sense of safety — the only reliable way to know your product works for everyone is to test the real combinations your audience uses.

The screen readers we test

  • NVDA (Windows) with Chrome and Firefox
  • JAWS (Windows) with Chrome and Edge
  • VoiceOver (macOS) with Safari
  • VoiceOver (iOS) with Safari
  • TalkBack (Android) with Chrome

We tune the exact matrix to your analytics and audience so the effort goes where your users actually are.

What we evaluate

  • Announcements — names, roles, states, and value changes are announced accurately and at the right time
  • Focus management — focus moves logically, is never trapped, and returns sensibly after modals close
  • Reading & navigation order — the reading sequence matches the visual intent; headings, landmarks, and lists support efficient navigation
  • Dynamic updates — live regions, validation messages, and loading states are announced without overwhelming the user
  • Custom widgets — menus, modals, comboboxes, tabs, carousels, and grids behave correctly with real readers, not just on paper

What we deliver

A detailed report of announcement, focus, and navigation issues — each tied to a specific reader/browser pairing, with what was announced, what should have been announced, steps to reproduce, a WCAG 2.2 mapping, and the markup change that resolves it consistently across readers.

Tested by people who rely on these tools

Evaluation is carried out by auditors with disabilities who use these screen readers every day. That means findings reflect genuine usability — the difference between “technically present in the accessibility tree” and “actually understandable and operable” — not just automated conformance. Pair this with a full audit by people with disabilities for end-to-end coverage.

Frequently asked questions

Why test with more than one screen reader?

Screen readers interpret ARIA and HTML differently and pair with different browsers. Code that works in one reader can fail in another, so single-reader testing gives a false sense of safety.

Which screen reader and browser pairings do you use?

Typically NVDA and JAWS with Chrome and Firefox, VoiceOver with Safari on macOS and iOS, and TalkBack with Chrome on Android. We match the matrix to your analytics and audience.

Is this performed by people who use screen readers daily?

Yes. Evaluation is carried out by auditors with disabilities who rely on these tools every day, so findings reflect real usability, not just technical conformance.

Does this satisfy WCAG?

Screen-reader evaluation directly supports criteria like 1.3.1, 4.1.2, and 4.1.3. We map each finding to the relevant WCAG 2.2 success criteria.

Do you test on mobile screen readers too?

Yes. We test VoiceOver on iOS and TalkBack on Android, because mobile gestures and rotor/reading controls behave differently from desktop and frequently expose their own issues.

Can you evaluate a single complex component?

Absolutely. We often evaluate a specific custom widget — a date picker, combobox, data grid, or modal flow — against the ARIA Authoring Practices and real reader behavior, and hand back exact markup fixes.

Request a demo

Talk to our accessibility experts — including people with disabilities.

Request a demo