No — accessibility widgets do not make a website work with screen readers. When you load a widget-equipped page with NVDA or VoiceOver, the barriers a blind user hits — missing alt text, nameless buttons, unlabeled form fields — are still there, because they live in the page’s HTML underneath the widget’s JavaScript. The only controlled academic test we could find, Daniela Kubesch’s 2024 master’s thesis, evaluated accessiBe, UserWay, and AudioEye and concluded that overlays “in their current form cannot meet WCAG 2.1 AA standards.”
We test sites with screen readers for a living, and widget-equipped pages come across our desk constantly. This post documents what the vendors claim, the six checks we run, what the screen reader actually announces, and how you can reproduce every step yourself.
What accessiBe, UserWay, and AudioEye actually claim
The pitch is specific. accessiBe’s accessWidget page says its “Advanced AI adds ARIA attributes and alt text to your website, enabling screen readers to accurately interpret content for blind users,” and that the product “remediates according to WCAG 2.1 AA for ADA compliance.” UserWay’s widget page promises “100+ AI-powered accessibility tools” and says you can “Conform to WCAG 2.1 & 2.2.”
AudioEye is the odd one out: its own blog post on widgets concedes that widgets “do not fix underlying accessibility issues in a website’s code” — while selling an automation-plus-toolbar product of its own. When a widget vendor’s marketing department writes that sentence, it is worth taking seriously.
Those claims are testable. So we test them.
How to test an accessibility widget with a real screen reader
The setup costs nothing. On Windows, download NVDA (free, built by a nonprofit) and browse in Chrome or Firefox. On a Mac, press Cmd+F5 to start VoiceOver and use Safari. Then run these six checks on any page with a widget installed — first with the widget’s screen-reader profile off, then on:
- Images. Navigate to product or banner images. Does the screen reader announce a description that matches the image, or a filename, a generic guess, or nothing? (WCAG 1.1.1)
- Buttons and links. Land on every icon button — cart, search, menu, close. Does each one announce a real name, like “Search, button”? (WCAG 4.1.2)
- Forms. Enter your contact or checkout form. Is every field announced with a label? Submit it empty — is the error read aloud? (WCAG 3.3.2 and 4.1.3)
- Keyboard reach. Tab through the whole page, including the widget’s own panel. Can you reach everything and get back out? (WCAG 2.1.1)
- Headings. Pull up the heading list (NVDA: Insert+F7; VoiceOver: rotor). Does it outline the page sensibly, or is it missing levels — or padded with headings the widget invented?
- The widget’s “screen reader mode.” Turn it on while NVDA or VoiceOver is running. Listen to what happens.
That is the whole methodology. No lab, no jargon — about thirty minutes per page.
The results: what the screen reader actually gets
Across the widget-equipped sites we audit, the same pattern repeats. Here is the check-by-check outcome, with an independent source for every failure mode so you don’t have to take our word for it.
| Check | What the widget claims | What NVDA / VoiceOver actually get | Verdict |
|---|---|---|---|
| Image alt text | AI writes “accurate and concise image descriptions” | Generic or wrong guesses; meaningful images misdescribed, filenames read aloud. The FTC barred accessiBe from claiming its AI achieves WCAG compliance (Feingold, 2025) | Fail |
| Button and link names | Machine learning will “correctly identify and label complex structures” | Icon buttons still announced as just “button,” or given garbled guesses — one user documented a cart button announced as “This May Be Cart, The Cart, The Shopping Cart, or Product List” (UsableNet guest post) | Fail |
| Form labels and errors | ”Automatic, ongoing remediation” | Fields with missing or mismatched labels; validation errors that are never announced (Kubesch, 2024) | Fail |
| Keyboard operability | Implied by WCAG conformance claims | Underlying fake buttons stay unreachable; one tester found a widget whose own read-aloud player could not be reopened by keyboard to turn it off (Allerlay) | Fail |
| Heading structure | Fixed via injected ARIA | The original heading mess is unchanged; Overlay Fact Sheet signatories report widgets that flood pages with unwanted headings (Overlay Fact Sheet) | Fail |
| Widget “screen reader mode” | A built-in narrator for blind users | Conflicts with the screen reader already running — two voices producing what one blind tester calls “a meaningless word soup” (UsableNet guest post) | Fail |
| Honest verdict | — | The display toggles (text size, contrast, cursor) do work — for sighted users. Every check that decides whether a blind customer can actually use the site still fails. | Fail for screen reader users |
That last row matters. Widgets are not fake software; the font-size and contrast controls do what they say. But those duplicate settings your visitors’ browsers and operating systems already have. The checks that involve a screen reader — the users the ADA cases are actually about — are the ones that fail.
What does this sound like to a blind user?
Here is check 2 in practice. A sighted visitor sees a magnifying-glass icon and clicks it. NVDA, on the same element, announces only: “button.” Button for what? The user has no idea. If the widget has taken a guess, it can be worse than nothing — “Shopping Cart” becoming “This May Be Cart, The Cart, The Shopping Cart, or Product List” is a real example from Michael Taylor, a blind screen reader user writing for UsableNet, who also reported widget accessibility modes adding lag between keystroke and speech.
This matches the formal research. In Kubesch’s user study of 21 participants with permanent visual impairments, only one said they would prefer an overlay to navigate a website — and only if it were on every site — and the thesis found users “generally hesitant to engage with accessibility overlays,” preferring their own assistive technology. And in WebAIM’s 2021 survey of accessibility practitioners, 67% rated overlays “not at all” or “not very” effective — rising to 72% among respondents who themselves have disabilities. We saw the same thing when we tested a real purchase flow in our screen reader checkout walkthrough: the blockers were all in the underlying markup.
Doesn’t the widget include its own screen reader?
Yes, and that is a bug, not a feature. Blind users do not arrive at your site needing a screen reader — they already run one for everything they do on a computer, configured to their speech rate, verbosity, and shortcuts. As accessibility consultant Thinh-Lay Wonesky puts it, disabled users “don’t need the widget” — what they need is “a universal design and a working technique that doesn’t interfere with their software or assistive technologies.”
A per-site narrator with no configurability asks a blind visitor to abandon a tool they’ve used for years and learn a new one — on your website, mid-task. Taylor compares it to being handed “a parachute with holes in it.” Run check 6 yourself and you’ll hear why: two synthesizers talking over each other. Our guide to how screen readers work explains why the real fix is markup those tools can parse.
If widgets worked, the lawsuit data would show it
It shows the opposite. Plaintiffs filed suits against companies using accessibility widgets every single month of 2025 — roughly 100 to 155 a month, out of more than 5,000 digital accessibility lawsuits that year — and UsableNet’s full-year data shows “no meaningful reduction in lawsuits against widget users.” Its midyear report put it more bluntly: widgets “continue to offer no legal protection to the companies that use them.”
The regulators arrived at the same place as the testers. In April 2025 the FTC finalized a $1 million order against accessiBe, barring it from claiming its overlay “can make any website compliant with WCAG” — and disability rights lawyer Lainey Feingold, in her comment urging the FTC to finalize the order, wrote that “AccessiBe’s products actually interfere with tools that blind people and others already use to access the internet.” We cover the litigation side in detail in our overlay lawsuit breakdown, and the broader evidence in do accessibility overlays work.
What actually passes a screen reader test
The fixes that pass the six checks are unglamorous and permanent: real alt text written by a person, buttons with accessible names, forms with programmatic labels and announced errors, a heading outline that matches the page. None of it can be reliably bolted on by a script after the page loads — it has to go into the code. That’s what manual accessibility testing finds and what remediation fixes, and it holds up when a plaintiff’s tester — or a customer — opens your site with NVDA.
If your site runs a widget today, don’t panic and don’t feel foolish; the marketing was persuasive enough that a federal agency stepped in. Just verify instead of trusting: run the six checks above, or let us run the first pass for you.
Want to see what the widget isn’t fixing? Start with a free accessibility scan.