AT Stack Combinations: Why Auditors Must Test Across Multiple Screen Readers

There is a secret that often confuses developers: an accessibility bug can only appear in a specific technology combination and not in others. A developer testing with NVDA+Chrome might think "this is fixed," while millions of JAWS+Edge users are still stuck in a completely different barrier.

This is why a professional accessibility auditor cannot rely on mastering just one screen reader. They must understand the AT Stack landscape — the specific combinations between Assistive Technology (AT) and the browser or platform used by real users in the world — and know when each combination should be used in an audit.

---

Why Do AT+Browser Combinations Matter?

Screen readers work by "reading" the accessibility structure exposed by the browser through a layer called the Accessibility API. The problem is that each browser exposes this information slightly differently, and each screen reader interprets that API in its own way.

The result: different behavior for the same code.

As a real-world example, a modal dialog component built with role="dialog" and aria-modal="true" might:

• Work perfectly in NVDA + Chrome (user is trapped inside the modal as expected).
• Fail in JAWS + Edge (user can escape the modal using Virtual Cursor and read background content).
• Partially work in VoiceOver + Safari (modal is detected, but focus doesn't automatically move into it).

A good audit report must document which combinations succeed and which fail.

---

The AT Stack Map Every Auditor Must Know

Desktop

Combination	Market Share	OS	Key Notes
JAWS + Chrome	~33%	Windows	Most popular among professionals; widely used in corporate and government environments
JAWS + Edge	~10%	Windows	Relevant for users in Microsoft 365 ecosystem
NVDA + Chrome	~26%	Windows	Most popular among home users; open source and free
NVDA + Firefox	~8%	Windows	Open source community; important for verifying open web standards compliance
VoiceOver + Safari	~9%	macOS	Mandatory for auditors targeting Apple ecosystem users
Narrator + Edge	~3%	Windows	Built-in Windows screen reader; important for basic government compliance testing

Mobile (Native Apps & Mobile Web)

Combination	Platform	Key Notes
VoiceOver + Safari	iOS/iPadOS	Primary standard for Apple mobile testing; mandatory for all iOS apps
TalkBack + Chrome	Android	Primary standard for Android testing; gesture behavior differs across Android versions
TalkBack + Firefox	Android	Relevant for privacy-focused Android users

Reference Data: The WebAIM Screen Reader Survey (annual) is the most comprehensive survey for understanding real screen reader usage trends worldwide. Auditors should follow this survey each year as market share changes over time.

---

Testing Strategy: You Don't Have to Test Every Combination

Testing every AT+browser permutation for every page would be unrealistically time-consuming. A professional auditor uses a pragmatic strategy:

Tiered Approach

Tier 1 (Mandatory): Always test at least two desktop combinations and one mobile combination:

• NVDA + Chrome
• JAWS + Chrome (or Edge)
• VoiceOver + Safari (iOS)

This already covers over 70% of real screen reader users.

Tier 2 (Recommended for Enterprise Projects):

• Add TalkBack + Chrome (Android)
• Add VoiceOver + Safari (macOS)

Tier 3 (For Government or High-Accessibility Projects):

• Add Narrator + Edge
• Add NVDA + Firefox

How to Choose the Right Tier

When scoping a project with a client, ask:

1. Who is the target audience? Apple or Windows platform dominant?
2. Is this an enterprise/government product? If yes, JAWS is mandatory.
3. Is there a mobile app? If yes, VoiceOver + TalkBack are mandatory.
4. What is the audit budget? More combinations = more billable hours.

---

Documenting AT Stack in Bug Reports

Every bug entry in a report must explicitly state the AT Stack:

Issue #12: Navigation Dropdown Cannot Be Closed via Keyboard
Affected AT Stack: JAWS 2024 + Chrome 126 / Windows 11
Unaffected AT Stack: NVDA 2024.1 + Chrome 126 / Windows 11
Steps to Reproduce: ...

This information is crucial because it allows developers to prioritize fixes based on how large the affected user population is.

---

Known Quirks Per Combination

Each AT+browser combination has historical "quirks" — not bugs, but implementation differences auditors must understand:

JAWS: Has Virtual Cursor mode (reads page like a text document) vs Forms/Application Mode (interacts with form elements). The transition between modes is sometimes not automatic, causing users to get stuck in the wrong mode.

NVDA: Uses Browse Mode and Focus Mode. Has a "Speech Viewer" feature extremely useful for audits — it displays all text the screen reader speaks in a real-time text window that sighted team members can read.

VoiceOver (iOS): Left/right swipe gestures for element navigation are fundamentally different from how NVDA/JAWS navigate web pages. Auditors must be truly fluent with the VoiceOver Rotor as a critical audit tool.

TalkBack (Android): Notification behavior and navigation gestures changed significantly between Android 12, 13, and 14. Always document the Android version and TalkBack version in reports.

---

Conclusion

Mastering diverse AT Stacks doesn't mean having all devices simultaneously — many auditors start with the most popular (NVDA + Chrome) and gradually expand their skills. What matters most is understanding the principle: that the user experience can differ vastly depending on the tool they use, and an auditor's job is to ensure no user population is left behind.

References

- Firth, A. Practical Web Accessibility: A Book Apart. - Lazar, J. et al. Ensuring Digital Accessibility Through Process and Policy. - WebAIM. Screen Reader User Survey. https://webaim.org/projects/screenreadersurvey/