The screen reader matrix:
Why every AT combination tells a different story

When an accessibility audit reveals that a website “works with screen readers,” that claim is almost meaningless without qualification. Screen readers are not a monolithic category of software — they are complex applications that each implement their own interpretation of the Accessibility APIs provided by operating systems, layering that interpretation on top of the browser’s own accessibility tree, which itself varies significantly between vendors.

The result is a layered stack of interpretations. A role="dialog" attribute on a modal element will be announced differently in JAWS 2024 with Chrome vs. NVDA 2024.1 with Firefox 124 vs. VoiceOver on macOS Sonoma with Safari 17. These are not minor phrasing variations — they can be the difference between a user understanding they are in a modal dialog that traps focus, or hearing nothing at all.

The three-layer stack — operating system accessibility API → → screen reader engine — means that any change at any layer can produce an entirely different user experience. Browsers update their accessibility tree implementations. Screen readers update their virtual buffer strategies. OS APIs evolve. The combination testing requirement isn’t bureaucratic box-ticking; it’s a technical necessity rooted in genuine architectural divergence.

The assistive technology landscape has consolidated around a handful of dominant tools, but each has unique architectural characteristics, user bases, and browser affinities. Understanding these is prerequisite to intelligent test prioritisation.

The following matrix documents observed behaviour for common ARIA patterns and HTML semantics across the most important AT/browser combinations. Results are based on testing conducted with production-representative versions as of Q1 2025.

Legend: Pass = announced correctly and completely. Partial = announced with missing or incorrect information. Fail = not announced, announced incorrectly, or navigation broken.

Understanding why combinations diverge — not just that they do — is essential for writing code that is robust across the matrix. The differences fall into several architectural categories.

Internet Explorer 11 reached end-of-life on 15 June 2022. Microsoft no longer provides security updates or technical support, and Freedom Scientific’s JAWS 2024 does not officially support IE 11. WCAG 2.2 — published in October 2023 — includes success criteria such as 2.4.11 Focus Not Obscured that depend on CSS and rendering capabilities IE 11 cannot support. JAWS+IE is not a valid target combination for WCAG 2.2 AA compliance work.

That said, teams maintaining legacy codebases that pre-date 2022, or supporting locked-down enterprise environments that have not yet completed their IE-to-Edge migrations, may need to understand the historical behaviour of this pairing. The JAWS/IE combination used Microsoft Active Accessibility (MSAA) — an older API layer with significantly limited ARIA support compared to the IAccessible2 (IA2) and UI Automation (UIA) interfaces that modern browsers expose. Many ARIA 1.1 patterns behaved incorrectly or were entirely silent under MSAA.

If you are one of the rare teams with a documented, contractual obligation to support IE 11, treat it as a supplementary target with its own separate test pass — not as part of a WCAG 2.2 compliance programme. The modern enterprise combination is JAWS + Edge (Chromium), which uses UIA and has excellent ARIA support.

Apple’s approach to accessibility differs fundamentally from Microsoft’s. Where JAWS and NVDA build a complete virtual representation of the document and allow users to navigate that representation independently of focus, VoiceOver works more directly with the rendered accessibility tree and often with actual keyboard focus.

This means that patterns which work by manipulating focus invisibly — focus moves that happen in response to ARIA attributes rather than user interaction — can break VoiceOver in ways that seem inexplicable until you understand the architectural difference. VoiceOver users on macOS navigate with a separate VoiceOver cursor, but the relationship between VoiceOver cursor position and keyboard focus is more tightly coupled than in JAWS’s Virtual PC Cursor model.

Use this calculator to estimate the testing effort required for your product, based on your user base characteristics, compliance target, and available AT combinations.

No team has unlimited testing resources. The goal of a coverage strategy is to maximise the probability of catching real-world failures affecting real users, within the constraints of time and tooling. Risk weighting — allocating testing effort proportional to user impact and architectural risk — is the professional approach.

Effective combination testing is not simply running the same manual test script across multiple tools. Each AT has unique keyboard commands, navigation models, and announcement verbosity settings. A professional workflow accounts for these differences and yields reproducible, comparable results.

The following checklist maps directly to WCAG 2.2 AA success criteria that are primarily validated through screen reader testing. Each item must pass in all P1 combinations before a feature is considered WCAG 2.2 AA conformant.

Screen reader testing is not an accessibility compliance checkbox. It is a quality assurance discipline that, when done well across the right combinations, reveals interface bugs that affect all users — not just those with disabilities. Focus management errors, dynamic content that fails to update, and state that isn’t communicated programmatically are usability failures that happen to be detected through the lens of assistive technology.

The legal landscape reinforces the technical argument. The EU Web Accessibility Directive, the US Revised Section 508 Standards, the UK Public Sector Bodies Accessibility Regulations, and an accelerating wave of private sector ADA litigation all point toward WCAG 2.2 AA as the baseline expectation. Litigation risk is highest where no documented testing has been conducted — and testing one combination is often insufficient evidence of a good-faith compliance effort.

At AIOPSGROUP, we work with organizations across financial services, government, retail, and enterprise software to build accessibility testing programs that are both rigorous and sustainable. Rigorous means covering the right combinations for the right user populations. Sustainable means embedding AT testing into CI/CD pipelines, training development teams, and creating living test matrices that grow with the product.

If your team is building or maintaining a digital product that serves any segment of the public, the question is not whether to conduct multi-combination screen reader testing, but how to do it efficiently and at scale. We can help with both.