J5.07.1screen reader browser combinationdesignresearch

Screen reader and browser combinations do not behave alike

Aliases: AT combination · engine differences · reader-browser pair

What it is

The same page can work in VoiceOver+Safari, drop a role in JAWS+Chrome, and double-announce in NVDA+Firefox. What actually runs is not “a screen reader” or “a browser.” It is a pair. Different pairs translate the same tree into different sentences and different operable behavior.

Why it happens

The browser folds the page into an accessibility tree; the reader folds the tree into speech, braille, and shortcut keys. Each side has its own mapping table, upgraded independently. How a role is spoken, whether an attribute is honored, whether a live change fires, is the product of both tables. “This page is correct on my machine” is usually one pair’s projection.

The gaps are not edge cases. One engine may demote a custom role to a group; another will announce it. One honors a class of state; another ignores it. “I tested a reader on my Mac” therefore proves that pair, not the pair in the user’s hands. A failure may live in the page or in the seam between the two mappings — a second pair is what splits those.

Studying it

Hold the page fixed and swap pairs: NVDA+Firefox, JAWS+Chrome, VoiceOver+Safari, same script (find the control, hear one utterance, activate, hear state). Transcribe the speech and align type / name / state / whether activation worked.

Independent variables: reader, browser, the combination of the two. Dependent variables: whether the utterance has the three slots, whether activation succeeds, whether the same operation agrees across pairs.

When they differ, swap the browser keeping the reader, then the reader keeping the browser, to see which side the seam is on. Do not write a single pair’s pass as “AT compatible.”

Where it stops holding

Native apps talk to the system accessibility API, not a browser, so web pair differences do not transfer; iOS VoiceOver and macOS VoiceOver are still not the same runtime. An enterprise that can pin staff to one pair may narrow the matrix; a public product may not. Very new or very old versions enlarge differences; sample the versions users actually run, not a lab nightly.

Applying it

  • Treat “reader × browser” as the unit of test, not the reader’s name alone.
  • Walk the primary flow on at least two independent pairs; a pass on one pair is not sign-off.
  • How to check: do the same task in NVDA+Firefox and in VoiceOver+Safari, and lay the two utterances and two activations side by side. Behavior that holds in only one pair is not yet the product’s behavior.

Related

  • Same group: J5.07.2 Cover mainstream combinations, not a single environment · J5.07.3 Mobile and desktop AT interaction models differ
  • Nearby: J5.01 Screen Readers · J5.09 How Screen Readers Work
  • Search terms: screen reader · browser combination · NVDA JAWS VoiceOver

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/J5.07.1