Which browser and screen reader combinations should you test?

Use a practical baseline for routine testing, then adjust it to the people, platforms, browsers, and risks that matter to your product.

Reading: about 5 minutes
Knowledge check: 2-3 minutes

The quick answer

For a public-facing web product, the first four combinations form a defensible professional release baseline. The remaining combinations extend coverage when product support, audience evidence, or risk justifies them.

Recommended browser and screen reader combinations for accessibility testing. The priority column distinguishes the release baseline from combinations to add when relevant.
Priority	Platform	Screen reader	Browser	Why include it
Release baseline	Windows	JAWS	Chrome	Widely used, especially in workplaces and North America.
Release baseline	Windows	NVDA	Chrome	A widely used, free Windows combination suited to regular team testing.
Release baseline	iPhone or iPad	VoiceOver	Safari	Apple documents Safari as the standard VoiceOver web environment on iOS and iPadOS.
Release baseline	Android	TalkBack	Chrome	Google documents TalkBack web navigation specifically with Chrome.
Add when relevant	Windows	NVDA	Firefox	Adds a commonly used pairing and a browser engine beyond Chromium.
Add when relevant	macOS	VoiceOver	Safari	Covers desktop VoiceOver when Mac users or Safari are in scope.
Add when relevant	Windows	Narrator	Edge	Covers the built-in Windows screen reader and Microsoft browser environment.

Why the browser matters

On the web, the browser turns page semantics into an accessibility tree. The screen reader then interprets that representation and provides navigation and interaction commands. Different browser engines and screen readers can expose or interpret the same interface differently, particularly when a product uses complex ARIA, focus management, live updates, or custom controls.

Choose coverage from evidence

Begin with the release baseline, then change it using evidence rather than convenience alone.

Supported environments: include the operating systems and browsers your product promises to support.
Actual users: use research, support requests, and accessibility feedback to identify real combinations.
Analytics: use browser and platform data carefully; ordinary analytics usually cannot identify a screen reader.
Region: JAWS and NVDA usage differs substantially between regions, so a global product should avoid assuming one Windows screen reader represents everyone.
Risk: authentication, payments, healthcare, employment, education, and other consequential flows justify broader coverage.
Managed technology: enterprise and internal products may need specific browser and assistive technology versions.

Three useful levels of coverage

Development smoke test

Use one relevant combination that the team can operate correctly and run it throughout design and development. NVDA with Chrome is a practical Windows starting point, but it is not a release claim.

Professional release baseline

Test representative tasks with JAWS and NVDA on Windows, VoiceOver with Safari on iPhone or iPad, and TalkBack with Chrome on Android. Remove a platform only when the product genuinely does not support it.

Expanded coverage

Add Firefox, macOS VoiceOver, Narrator, older supported versions, or audience-specific combinations when the product evidence or impact calls for them.

JAWS access and cost

JAWS remains one of the most widely used desktop screen readers, particularly in workplaces and North America. Its commercial pricing can make it harder for smaller teams to include, but cost does not make the user environment less relevant.

Freedom Scientific provides a downloadable 40-minute demonstration mode. It is useful for initial evaluation and learning, but its licence terms say it is not intended as a substitute for a commercial licence for ongoing organizational testing. Professional, timed, and multi-user options are available; check current JAWS licensing and pricing.

Balance usage and browser diversity

Chrome and Edge are both Chromium-based, but they remain distinct supported products and are used in different environments. Testing both can be justified by audience or enterprise evidence. If the goal is to broaden browser-engine coverage, adding NVDA with Firefox often provides more information than repeating every Windows screen reader in both Chrome and Edge.

Use and record meaningful versions

Use current stable versions for routine testing unless users or product support requirements establish another version. Recheck important flows after major browser, operating system, or screen reader updates.

Device and operating system
Browser and version
Screen reader and version
Input method and relevant configuration
Task and exact navigation path
Expected result and actual result
Date tested

Interpret results precisely

There is no universal certification matrix. A passing result describes one task in one recorded combination; it does not prove support across every browser, screen reader, or experienced user workflow.

A responsible conclusion is: No barriers were found in this task with this recorded combination. If a defect appears in one combination but not another, investigate the product first, then determine whether browser or screen reader interoperability contributes to it. Do not dismiss a barrier merely because another combination compensates for it.

Beyond browser testing

This matrix applies to websites and browser-based applications. Native iOS and Android apps, WebViews, and platform prompts need their own combinations of device, operating system, app build, screen reader, and input method.

TRY THIS NOW

Draft a defensible release baseline

Write one row for each combination you intend to test. A useful row contains all of the following information.

EnvironmentDevice, operating system, browser or app, screen reader, versions, and input method.
ReasonSupported environment, user evidence, regional relevance, or product risk.
TaskA representative journey with a clear start, expected behavior, and completion point.
ConclusionA scoped statement about that task and combination, not a claim about the whole product.

Sources and review context

These recommendations combine current vendor documentation, public-sector testing guidance, interoperability work, and usage research. Survey data can inform priorities but does not represent every region or user.

Editorially reviewed 20 July 2026. Recheck this guide when major browser or screen reader support changes.

Knowledge check

Answer every question, then use the forward lesson button to record this lesson as complete. The check is not scored and can be repeated.

NEXT STEP

Continue to lesson 7: Describe each reader consistently

Move on when you are ready. Your knowledge-check answers are not stored.