What People Use, and What It Needs From You

Assistive technology does not repair a page. It reads one. Every WCAG requirement is ultimately about giving these tools something true to work with, so it helps to know what they are and how each one fails when you do not.

It is Cheaper to Test Than You Think

The barrier used to be cost. It is not any more:

• NVDA is a free, open-source screen reader for Windows.
• VoiceOver is built into every Mac and iPhone. Command and F5 starts it.
• TalkBack is built into Android.
• Narrator ships with Windows.
• Magnifier and Zoom are built into Windows and macOS.
• Voice Control is built into macOS, iOS and Android.

A few tools still cost money, and JAWS is the one that matters most, because it is the tool most people name as their main one. WebAIM's tenth screen reader user survey puts it at 40.5% of primary use, ahead of NVDA at 37.7%. Dolphin SuperNova at 3.7% and ZoomText or Fusion at 2.7% are commercial too, and together they are a bigger share of primary use than half of VoiceOver's. JAWS also runs in a forty-minute demonstration mode you can restart, so the cost objection to testing with the most-named screen reader is smaller than it looks.

Two things about that 40.5% before anybody quotes it. It measures primary use, meaning what people name as their main tool. Ask instead which readers people commonly use and the order flips, with NVDA at 65.6% against JAWS at 60.5%, because 71.6% of respondents use more than one and 43% use three or more. Whichever measure you quote, say which one it is, because the two produce opposite headlines from the same survey.

And the answer moves depending on where your customers are. In North America, JAWS leads NVDA by better than two to one. Across Europe, Africa, the Middle East and Asia, NVDA leads, and in Asia it is not close. So a European team defaulting to JAWS because a US blog post said it leads is optimising for the wrong tool.

Test On a Phone, Because That Is Where People Are

One survey figure changes a test plan more than any other, and it is the one everybody skips. 91.3% of respondents use a screen reader on a mobile device.

Which means a screen reader test that stops at the desktop misses something nine in ten users do routinely. It also reframes VoiceOver. On the desktop it is about one in ten of primary use, which makes it easy to treat as a Mac curiosity. On mobile the same technology is what most screen reader users are holding. Our mobile accessibility guide covers what else changes there.

The Two Survey Questions Nobody Quotes

The tenth survey asks two questions that get quoted far less than the screen reader shares and that change more decisions than any of them.

The first asks what would improve web accessibility most, better websites or better assistive technology. 85.9% answered better websites. That figure has risen at every survey since 2009, when it stood at 68.6%, so the people who depend on these tools have grown steadily more certain that the problem is not the tool. That means the honest answer to a widget sold on the promise of repairing your site from the outside is already in the data, and it comes from the users rather than from us.

The second should unsettle any owner who has never had a complaint. 67% of respondents said they never or rarely contact a site's owner about a barrier they hit. So a quiet inbox is not evidence that your site works. It is the expected result. Most people who cannot finish your checkout leave and buy somewhere else, and it reaches you as a bounce rate rather than as a message.

Two more figures are worth carrying out of the same survey. 38% of respondents with disabilities use a braille display, up from 27.7% in 2012, and a braille display needs everything a screen reader needs plus a transcript for anything carrying sound. And only 40.2% use a screen reader most often on a desktop, with about half saying they use desktop and mobile roughly equally. That second one turns testing on a phone from a recommendation into arithmetic.

One caveat travels with every figure on this page, and WebAIM prints it themselves. The sample was not controlled and may not represent all screen reader users. It is self-selected, it ran in English, and it leans toward people who follow accessibility closely. It is the best dataset anybody has and it is not a census. The eleventh survey closed on August 31, 2026, with results due the following month, so check any number here against the newer one before you plan a year of work around it.

The Mistake Teams Make

Testing with one technology and assuming the rest follow. They fail differently, because they depend on different things.

A site can work perfectly with a screen reader and be miserable with a magnifier. The error message appears at the top of a form while focus sits at the bottom, and at 400% magnification those are effectively different screens. Worth being precise about that one, because it is often not a conformance failure at all. If the error is programmatically associated with its field, the rule is satisfied and the person still cannot see both at once. It goes in our reports as an observation rather than as a finding, and it is still the thing costing you the sale.

A site can also be fully keyboard operable and break voice control outright, because somebody added an aria-label that disagrees with the visible text. A voice-control user says the words they can see, and the words they can see are no longer the control's name.

A Voice-Input Worksheet You Can Run Without Speaking

Voice control is the one technology on this page you can gather real evidence against without installing anything. The rule behind it, 2.5.3 Label in Name at Level A, is a comparison between two strings. On one side, the words printed next to a control. On the other, the accessible name that control computes. If the name contains the printed words, it passes. That is the entire test, and it explains why anybody who tells you this failure is invisible without speech software has not read the criterion.

Start with what the rule does not reach, because that is where reports lose arguments. It applies to components whose label includes text, or an image of text. A control with no visible text label at all sits outside it. So a bare icon button with nothing written on it is not a 2.5.3 failure, however unusable it is. Where it has no accessible name, that is 4.1.2 Name, Role, Value, and where the icon is an image carrying the meaning it is 1.1.1 Non-text Content as well. All three are Level A, so nothing gets excused by being filed correctly. What you avoid is the meeting, because a criterion number a supplier can disprove is the one they will spend an hour on.

One more exclusion, and it catches every text editor. Characters used as a symbol rather than as language are not a visible label here. The B and the I in a formatting toolbar stand in for Bold and Italic, and a greater-than sign standing in for a play arrow is a picture assembled out of punctuation. W3C's guidance in those cases is that the name should be the function the button performs, which is a recommendation rather than the criterion's requirement, so record it as one. Mathematical expressions are the stated exception, since A>B does say something, and the advice there is to leave the formula alone and match the name to it exactly.

Two things people get wrong about the comparison itself. It asks the name to contain the printed words rather than to equal them, so a button reading Search whose name is “Search for a value” passes. And capitalisation and most punctuation are ignored, because a person speaking a label says neither, so a visible “First Name:” and a computed “first name” are a match rather than a finding.

You also have to settle what counts as the label before you can compare anything. It is the adjacent string, read conservatively: to the left of a text input or directly above it, to the right of a checkbox or radio button, inside a button, or immediately underneath an icon acting as one. The heading above the form is not a label. Neither is the instruction paragraph, nor the legend on a fieldset. Those can end up in the control's description instead, which is a separate thing the browser computes and a separate thing a screen reader announces after the name.

The computed name comes out of your browser's accessibility inspector, and a screen reader announcing the control tells you the same string out loud. Where it disagrees with the printed words, the culprit is almost always aria-label or aria-labelledby, because both win the name computation outright and replace the visible text even when that text is properly associated with the control. Searching your codebase for the first of those, on anything that already has a visible label, finds most of a site's failures in an afternoon.

One thing the worksheet does not establish. It tells you the names are sayable. It does not tell you somebody can finish your checkout by voice, because that needs a person speaking, working the whole journey, and meeting whatever your interface does when a command is misheard. Two different pieces of evidence, and the second one nobody has until somebody sits down and runs it.

Where to Start

1. 1Keyboard first. Everything else depends on it, because switch devices and screen readers both drive through the keyboard interface, so a keyboard failure is a failure for all of them at once. Our keyboard guide has the ten-minute test.
2. 2Then a screen reader, for half an hour, with the monitor off. Our screen reader testing guide covers the six commands you need to be useful.
3. 3Then the same thing on a phone, since that is where most screen reader use happens and where your desktop test tells you nothing.
4. 4Then zoom to 400% and watch what reflows, which is the magnifier user's whole experience compressed into five minutes.
5. 5Then compare visible labels against accessible names, which is the voice-control failure and the only one on this page you can evidence without owning the technology. The worksheet above works seven controls through it.