Screen Readers Explained: How They Work and Which Ones You Actually Have to Support in 2026

Most teams first meet screen readers as a testing chore: install NVDA, fumble through a page with the monitor still on, discover the modal announces nothing, file a ticket. That works well enough to find bugs. It does not tell you what you are actually building for, why the same page behaves differently in JAWS and VoiceOver, or how many screen readers you are obliged to support.

Those questions have answers, and in 2026 two of them changed.

What a screen reader actually does

A screen reader is not a text-to-speech engine pointed at your page. It is an interpreter sitting between your code and a user, and understanding its pipeline explains most of the bugs you will ever file.

The chain runs roughly like this:

1. The browser parses your markup into the DOM.
2. The browser builds an accessibility tree from that DOM - a parallel structure in which each node carries a role (what kind of thing this is), an accessible name (what it is called), a value, and states (expanded, checked, disabled, invalid).
3. The screen reader reads the accessibility tree through platform accessibility APIs - UI Automation and IAccessible2 on Windows, NSAccessibility on macOS, the Android accessibility framework - not through your HTML directly.
4. The screen reader presents that tree as synthesised speech, as braille on a refreshable display, or both, and offers navigation commands over it: next heading, next landmark, list all links, enter table navigation mode.

Two consequences follow, and they cause most real-world defects.

Your markup is a proposal, not the output. If you build a control from a div, the accessibility tree gets a node with no role and no name. The screen reader is not withholding information; there is none to read. This is why "it looks like a button" and "it is a button" are unrelated claims.

Screen readers are not browsers with audio. They present a structural model. A sighted user scanning a page sees hierarchy instantly through visual weight. A screen reader user reconstructs that hierarchy by jumping between headings, landmarks and lists. Correct heading order and real landmarks are not decorative semantics - they are the entire navigation system. A page with one h1 and forty styled divs is, functionally, a page with no table of contents.

Screen readers also run in distinct modes that trip up developers testing for the first time. On Windows, readers switch between a browse or virtual mode for reading content and a forms or application mode for interacting with controls. A custom widget that works when you click it may be unreachable in browse mode, and a widget that traps the user in application mode can make the rest of the page unnavigable. If you test without knowing which mode you are in, you will misdiagnose what you find.

The 2026 market, and why the answer differs by continent

Four screen readers cover almost the entire market; everything else combined sits below roughly seven percent. But "market share" is two different numbers, and conflating them produces bad support decisions.

The most recent full dataset is WebAIM's Screen Reader User Survey #10 (survey #11 is due in 2026):

	Used by (any use)	Primary screen reader
NVDA (Windows, free, open source)	65.6%	37.7%
JAWS (Windows, commercial)	60.5%	40.5%
VoiceOver (macOS/iOS, built in)	-	9.7%

Note the inversion: more people use NVDA, but more people use JAWS as their primary. Both numbers are real and they answer different questions. Primary-reader share tells you what people do their daily work in. Any-use share tells you what will encounter your site at some point - and it is why "we tested in JAWS" leaves roughly two thirds of screen reader users in untested territory.

The regional split matters more than either headline, and it matters especially for EAA scope:

Region	JAWS primary	NVDA primary
North America	55.5%	24.0%
Europe	29.7%	37.2%
Asia	22.9%	70.8%
Africa / Middle East	23.3%	69.9%

In Europe, NVDA leads. If your obligations are European - and under the European Accessibility Act they are, if you sell to EU consumers - then a support matrix inherited from a US-centric agency playbook has your priorities backwards. NVDA has overtaken JAWS as the most-used Windows desktop reader overall, and the gap is widening rather than narrowing; analysts expect survey #11 to widen the NVDA lead further.

A note on the data itself: WebAIM's survey is self-selecting and skews towards people engaged enough with accessibility to answer a survey about it. It is the best public dataset available and it should still be read as indicative rather than census-grade.

What changed in 2026: every reader now ships AI

This is the year the assistive technology itself started guessing at what your page means, and it changes the calculus of "supported" in a way worth thinking about carefully.

JAWS 2026 is the clearest example. Its Picture Smart AI feature submits an image to a model and returns a description in the Results Viewer, with language support extended to Icelandic, Macedonian, Albanian and Croatian. It adds AI Page Explorer and AI auto-labelling. Vispero has also been developing a JAWS AI Agent, targeting a beta in mid-2026, that uses screen capture to visually identify elements lacking proper ARIA or semantic HTML and interact with them through coordinate-based clicking - reaching controls that a conventional screen reader cannot find at all. JAWS 2026 also detects content language automatically and switches voice accordingly, entirely on-device. Across the category, every major reader now ships on-device image description, has aligned with the core of ARIA 1.3, and has refreshed its braille output.

It is tempting to read this as the problem solving itself. It is closer to the opposite, for three reasons.

An AI description is not an alt text. A model describing your product photo does not know the photo's purpose in the page, which is what alt text encodes. "A person holding a blue cylindrical object" is not "Replacement filter cartridge, 6-month".

Coordinate-based AI interaction is a workaround, and it is the user's workaround, not yours. If a JAWS AI agent can click your unlabelled button by looking at pixels, your button is still unlabelled. It fails the Success Criterion, it fails in every other reader, and it fails for the braille user who gets no pixels. Under EN 301 549 and the EAA, your obligation attaches to your product, not to the ingenuity of the assistive technology compensating for it.

"Accessibility supported" cuts against you here. WCAG's accessibility-supported requirement means you may only rely on technologies the user's assistive technology actually supports. A feature available in the newest commercial release of one reader is not a basis for a conformance claim, because a large share of users are on older versions, on free alternatives, or on braille output where the feature does not apply.

The reasonable posture: treat AI features as a genuine improvement in users' lives and as no change whatsoever to your obligations.

Building a support matrix you can defend

The goal is a written, evidence-based statement of what you test and why - the thing you produce when an auditor or a market surveillance authority asks how you know your product works.

Test reader plus browser pairs, not readers. A screen reader's behaviour is a function of the pairing, because the browser builds the accessibility tree. JAWS with Chrome behaves differently from JAWS with Firefox. Name pairs, not products.

A defensible baseline for an EU-facing product, in priority order:

1. NVDA + Chrome (Windows) - highest European share, free to install, no procurement barrier. Your default development-time reader.
2. NVDA + Firefox (Windows) - long-standing pairing with meaningful usage; catches tree-construction differences.
3. JAWS + Chrome (Windows) - the largest primary-reader group overall and dominant in enterprise and North America. Requires a licence, which is a budget line, not an excuse.
4. VoiceOver + Safari (macOS) - the only realistic macOS path; also the closest analogue to iOS behaviour.
5. VoiceOver + Safari (iOS) and TalkBack + Chrome (Android) - mandatory if you ship a mobile app or a substantial mobile web journey. Mobile screen reader interaction is gesture-based and genuinely different; desktop passes tell you very little about it.

Then hold three rules:

Test the current version and one back. Users do not upgrade in lockstep, particularly where the reader is a paid product and the upgrade is a purchase.

Include a refreshable braille display in scope for critical journeys, or at minimum review braille output through your reader's speech viewer. Braille users receive no tone, no pacing and no image description - text alternatives and structure are all they have. It is the strictest test of your semantics and it catches things speech testing hides.

Do not let the matrix substitute for users. A matrix tells you your markup is interpreted correctly. It does not tell you your checkout is tolerable to complete at screen-reader pace. Those are different findings, and only one of them comes from your own team.

What this means under the EAA

The European Accessibility Act does not name screen readers, and it does not publish a support matrix for you to copy. It sets functional accessibility requirements, operationalised through the harmonised standard EN 301 549, which incorporates the WCAG Success Criteria - including the robustness criteria that screen reader compatibility directly tests, and the accessibility-supported condition that makes real assistive-technology testing unavoidable.

The practical translation is that your defence is not "we used semantic HTML." It is a documented support matrix, dated test results against the pairs in it, and a remediation log for what failed. That is the same evidence that makes a conformance claim or an accessibility statement substantiable rather than aspirational - and, with enforcement now live and member-state authorities auditing, substantiable is the standard that matters.

Start with NVDA and Chrome. It is free, it is what most European users are on, and you can have it running in ten minutes.