Whether a technique works in the screen readers people use

What WCAG means by accessibility supported, which screen reader and browser pairs to test, and how to tell a flaw in the code from a gap in support.

In short: A way of using HTML, ARIA or script is accessibility supported when it has been tested to work with the assistive technology people use, in the language of the content, and in browsers they can get. WCAG doesn't say how many screen readers that takes. It requires that a page relies only on supported ways, and that anything delivered in an unsupported way is also there in a supported one.

When you need this

A team's document editor saves as people type. When the connection drops, a notice bar at the top writes "Connection lost. Changes you make now won't be saved." into an element with role="alert", which has been on the page, empty, since it loaded. A tester reads a paragraph with NVDA in Firefox while the connection drops, and hears nothing. The same test in NVDA with Chrome reads the warning once the paragraph ends.

The developer asks whether the code is wrong, whether the screen reader is wrong, and whether the page can still claim WCAG 2.2 Level AA. The answers depend on what WCAG means by accessibility supported.

What accessibility supported means

Conformance requirement 4 (WCAG 2.2 §5.2.4) has two sentences: "Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported."

WCAG's glossary says a use of a technology is accessibility supported when both of these are true:

It is supported by users' assistive technology: it "has been tested for interoperability with users' assistive technology in the human language(s) of the content".
It has accessibility-supported user agents that are available to users, in at least one of four ways:
- native support in widely distributed browsers that are themselves accessibility supported, as HTML and CSS have;
- a widely distributed plug-in that is accessibility supported;
- a closed environment, such as a company network, whose browser is accessibility supported;
- browsers that cost a person with a disability no more, and are as easy to find and get, as for a person without one.

A technology is relied upon when "the content would not conform if that technology is turned off or is not supported". So the question is never "is ARIA supported?" but whether this use of it is: role="alert" written while someone is reading, aria-label on a span, a scroll box reached with Tab. The glossary's own note says most technologies, HTML included, lack support for at least one feature or use.

Two things WCAG leaves open. Its note on the definition says the Working Group and the W3C "do not specify which or how much support by assistive technologies there must be". The Understanding document explains why: support differs by environment and by language, a new technology can't be supported by every older assistive technology, and support by one assistive technology "would not usually be enough". It leaves the judgement to whoever sets the requirement for an organisation, a purchase or a community.

Which screen readers and browsers to test with

Pick pairs by what people use. WebAIM's survey #11 (July and August 2026, 1,780 responses) reports these screen reader and browser combinations on desktops and laptops. EaseWeb tests every one above 4%:

Screen reader and browser	Respondents
JAWS with Chrome	31.2%
NVDA with Chrome	17.3%
JAWS with Edge	17.0%
NVDA with Firefox	9.1%
NVDA with Edge	5.4%
JAWS with Firefox	5.0%
VoiceOver with Safari	4.3%

WebAIM notes that its sample was not controlled and may not represent all screen reader users. EaseWeb's Japanese pages list a different set, NVDA and JAWS with Chrome, VoiceOver on iOS and TalkBack, taken from the National Diet Library's 2015 survey of readers in Japan. The pairs, and the results recorded for each, are on ARIA screen reader support.

Other testing methods choose other pairs. GOV.UK's Service Manual asks for JAWS, NVDA, VoiceOver on iOS and TalkBack, with screen magnifiers and Dragon. The Scottish Government's Service Manual checks pages with Narrator, which is on its laptops, and says "Edge is the recommended browser to use with Narrator". EaseWeb doesn't test with Narrator and has no results for it.

Desktop and mobile

Most respondents use a screen reader on a phone or tablet as well:

In WebAIM's survey #11	Respondents
Use a screen reader on a mobile device	91.8%
Commonly use VoiceOver on mobile	72.2%
Commonly use TalkBack on mobile	29.5%
Use a screen reader most on a desktop or laptop	42.6%
Use mobile and desktop about the same	49.0%
Use a screen reader most on a mobile device	8.3%

A phone is not a smaller desktop. Apple's guide says that when VoiceOver is on, "standard touchscreen gestures have different effects": a tap selects and speaks an item, a double tap activates it, and a three-finger swipe scrolls. Google's guide for TalkBack says scrolling takes two fingers instead of one. With either one on, dragging one finger across the screen speaks what is under it instead of moving the page, so test touch twice: once with the screen reader off, for one finger, the page's own gestures and the size of what is tapped, and once with it on, for whether every action can still be reached. Pinch, drag and tilt gestures with no button shows what goes wrong in between.

How people move through a page with each kind of tool is on how people use the web with assistive technology.

How to do it

When a screen reader doesn't say what you expect, work out whose problem it is before changing anything:

Check the code against the specification. Is this HTML or ARIA, used the way the specification allows? An aria-label on a span with no role is prohibited by ARIA, so it is a flaw even in the screen reader that reads it. A live region created together with its message never changes in front of the browser, so it is a flaw even though the attribute is there.
Reduce it to a test case. Take the element out of the page, with nothing else around it. If the reduced case works and the page doesn't, the cause is in the page: a script, a timing, a hidden parent.
Compare the pairs. Run the same case in every pair on your list, with default settings, reaching it the same way (Down Arrow, Say all, Tab). Then compare what you heard with what the specification allows. ARIA calls politeness levels "a strong suggestion" that browsers, assistive technology and the user may override, so a screen reader that waits until the end of a paragraph is not breaking anything.
Name it: a flaw or a gap. A flaw in the code is fixed in the code. A gap in support means the code follows the specification and a pair doesn't present it. Look for it in the vendor's issue tracker, NV Access's on GitHub for NVDA or WebKit's Bugzilla for Safari, and report it with the reduced case if it isn't there.
Decide and record. Requirement 4's second sentence decides what a gap costs: anything the unsupported use carries must also reach people in a supported way. Use another technique, add something that is supported, or add a workaround, and record the pair, the versions, the date and the link to the bug report.

Four guides show the difference:

What was heard	Flaw or gap	Guide
A rating in an `aria-label` on a `span` is read by one screen reader and skipped by others	Flaw: ARIA prohibits naming an element with no role	aria-label on divs and spans that screen readers often skip
A "Draft saved" toast is shown and never announced	Flaw: the region arrives with its message	Status messages that are shown but never announced
Routine notices in `role="alert"` break off VoiceOver mid-sentence	Flaw: an alert is for important, time-sensitive information	Alerts that cut off VoiceOver for routine updates
Tab reaches a scrolling terms box in Chrome and Firefox, not in Safari	Gap: Safari doesn't make the box a Tab stop, so the page adds one	Scrollable areas that a keyboard can't scroll

Workarounds, polyfills and the page without its script

A workaround is worth it when the answer to each of these is yes:

It follows the specification. A workaround that breaks it for one screen reader, such as an aria-label where ARIA prohibits one, moves the gap to the other pairs.
It has been tested in every pair on the list, not only in the one with the gap.
It can be taken out. Record the bug it works around, so someone can check whether the gap has closed.
The gap reaches enough people to be worth the extra code. The usage tables above are a starting point; the site's own audience may differ.

tabindex="0" on a scroll box passes all four. It is plain HTML, it changes nothing in the browsers that already stop on the box, and it can stay after Safari changes.

A polyfill is code that runs on every page that loads it, so it adds a security question to the accessibility one. Sansec reported on 25 June 2024 that the cdn.polyfill.io domain, embedded by more than 100,000 sites by its count, had been bought that February along with the project's GitHub account, and was injecting malware for mobile visitors through every site that loaded it. The polyfill's original author recommended not using it at all, because modern browsers no longer needed it. When a polyfill is still needed, serve a fixed version from your own site, test what it gives the screen readers in the same pairs, since it imitates the feature in script, and remove it when the browsers you support have the feature.

Progressive enhancement covers the case where the script never arrives. GOV.UK's Service Manual lists why JavaScript fails to load or run: network errors, ad blockers, a content delivery network that is down, DNS failures, browser updates, and firewalls or antivirus software that block or change content. WebAIM's survey detected JavaScript in 99.7% of responses, so this is not about screen reader users turning script off; it is about the script failing for anyone. A page built this way keeps its content, its links and its forms in HTML that a server answers. It also makes the conformance claim simpler: script that only enhances the page isn't relied upon, and WCAG §5.2.5 then asks that the page still meets the conformance requirements when that script is on, off or not supported, and that it still meets 1.4.2, 2.1.2, 2.2.2 and 2.3.1, which apply to all content.

Results age

Screen readers and browsers change with each release. NV Access's user guide is for NVDA 2026.3 as of this page's date. A result says what was heard in the releases that were current then, and no more. Record, for every result:

what was tested: the page or component, and the build;
the pair, with the operating system, browser and screen reader versions;
the settings, and whether they were the defaults;
how it was reached or read: Down Arrow, Say all, Tab, a swipe;
what was heard, in words, not a verdict;
the date.

WCAG's glossary notes that when a web content technology with several versions is cited, the versions supported should be specified, and §5.3.2 suggests listing the user agents and assistive technologies used to test in a conformance claim. EaseWeb's own record gives each result its month, and shows a result 12 months old or more as due for a retest.

Worked example

The team works through the editor's warning from the scene.

Check the code. The region is on the page and empty from load, the script writes the text into it, and "Connection lost" is important and time-sensitive, which is what ARIA says role="alert" is for. This is not a flaw.
Reduce it. The same role="alert", on its own, is on EaseWeb's ARIA test pages.
Compare the pairs. EaseWeb's record for role="alert", tested in October 2026 with default settings:

Pair	Reading with Down Arrow	Say all
JAWS with Chrome	Read once the chunk being read ends	Not read
NVDA with Chrome	Read once the paragraph ends	Read once the paragraph ends
NVDA with Edge	Read once the paragraph ends	Read once the paragraph ends
NVDA with Firefox	Not read	Not read
JAWS with Edge	Edge froze each time this was tested	Edge froze each time this was tested

The other pairs on the list have no result yet.

Name it. Waiting for the end of a paragraph is within what ARIA allows. "Not read" in NVDA with Firefox, and during Say all in JAWS with Chrome, is a gap in support: the code follows the specification, and those pairs don't present the change.
Decide and record. The team keeps role="alert", which follows the specification and is read in the other pairs. Because the warning is not read in two of the tested ways, it must also reach people in a supported way. So the warning no longer clears itself after a few seconds: it stays in the notice bar, at the start of the page, as plain text, until the connection comes back, where someone whose screen reader said nothing can still read it. The team records the gap, the pairs, the versions and the date, and checks the issue trackers before the next release.

The result: the warning is available as plain text on the page, and role="alert" adds an announcement in the pairs that make one. That is the team's judgement, not a test result, and whether it is enough for the contract is the client's decision, as the next sections say.

Common mistakes

Testing with one screen reader and calling it supported. The developer of aria-label on divs and spans that screen readers often skip heard the label in one screen reader and shipped it; others skip it. Test every pair on the list.
Calling a flaw a screen reader bug. A toast built with its own aria-live is silent in many screen readers because of the code, not the screen readers. Check the specification first, as status messages that are shown but never announced does.
Reaching for the role that is "sure to be heard". Making every notice an alert so that some pair reads it interrupts people in another. Alerts that cut off VoiceOver for routine updates owns the fix.
Waiting for the browser. A gap in support still fails the people using that browser today. Scrollable areas that a keyboard can't scroll fixes it in the page.
Loading a polyfill from someone else's domain. Whoever controls the domain controls the code on your pages. Serve it yourself, as above.
Results without versions or dates. A result from last year's releases says nothing certain about this year's. Record them as above, and keep them in one place, as ARIA screen reader support does.

What the standard says

WCAG 2.2 §5.2.4 (required): only accessibility-supported ways of using technologies are relied upon, and anything provided in an unsupported way is also available in a supported way.
WCAG 2.2 glossary, "accessibility supported" (required): the two conditions and the four ways above. Its notes, including that the Working Group doesn't say how much support is needed, are informative: §5.1 says notes don't create requirements.
WCAG 2.2 §5.2.5 (required): technologies used in an unsupported way don't block the rest of the page, and the page still conforms when a technology not relied upon is turned on, turned off or not supported.
WCAG 2.2 §5.3.2 (advice): a conformance claim may list the user agents, including assistive technologies, used to test.
Understanding Conformance (advice): which and how many assistive technologies is left to "entities closer to each situation".
EN 301 549 V3.2.1, clause 9.6 (required where the standard applies): a web page satisfies the five WCAG 2.1 conformance requirements at Level AA, requirement 4 among them, and test C.9.6 checks each by inspection. This page quotes V3.2.1 (2021-03). ETSI published V4.1.1 in September 2026: its clause 9.6 asks for the same five conformance requirements from WCAG 2.2, and C.9.6 tests them by inspection. Check which edition the law or contract cites.
Section 508, E205.4 (required for US federal agencies): electronic content conforms to WCAG 2.0's Level A and AA success criteria and conformance requirements.
JIS X 8341-3:2016: its text is identical to WCAG 2.0 (ISO/IEC 40500:2012), so the same definition applies. WAIC's test guidelines advise deciding the test environment, the browsers and assistive technology, using the one in the site's accessibility policy if there is one, and setting aside techniques that the accessibility-support information shows can't be used there.

Limits

This page doesn't say how many screen readers are enough, because WCAG doesn't. The client, the policy or the contract decides which pairs count, and a lawyer answers whether a law reads them the same way. EaseWeb's results are one record, by one tester, in default settings and in the releases of the month shown; they are not a public compilation of the kind the Understanding document describes, and they don't cover Narrator or PC-Talker. The other conformance requirements are on what it takes for a page to conform to WCAG, and the test results themselves are on ARIA screen reader support.

Terms

accessibility supported: A way of using a web technology that has been tested to work with the assistive technology people use, in the language of the content, in browsers they can get.
relied upon: A technology is relied upon when the content would not conform if it were turned off or not supported.
gap in support: The code follows the specification, but a browser or an assistive technology doesn't present it the way the specification asks.
polyfill: A script that adds a feature to browsers that lack it, by imitating the feature in JavaScript.
progressive enhancement: Building a page so that it works with HTML first, then adding CSS and script on top.

Sources and guides

Guides that show it

This page explains a practice, with recreated examples. It is not legal advice, and it is not a finding about a named client.