An accessibility widget is a layer over your website. The barriers that get a business sued live underneath it. That distinction is not academic: in September 2026 alone, 91 of the 360 new web accessibility lawsuits filed in the United States named a defendant that already had a third-party accessibility widget running on the site. The icon in the corner was there. The lawsuit came anyway. If you bought one of these to close a risk, it is worth knowing exactly what you bought.
What does an accessibility widget actually do?
It loads after your page does, and it patches what a script can reach from the outside: contrast and text size, a reading mask, reduced motion, sometimes a machine guess at missing alternative text. Some of that is genuinely useful, and most sites never build any of it themselves. But the failures that end in a complaint are structural — a form field with no programmatic label, a control built as a styled div instead of a button, a dialog that traps keyboard focus, a checkout error signalled only by turning text red. Those are properties of the markup your developer shipped. An overlay can try to infer them from outside, but it is reading the same ambiguous markup the screen reader is reading, and when it guesses wrong it puts a confident, incorrect label on top of a missing one.
Why doesn't the widget stop the lawsuit?
Because the claim is about a task, not a settings panel. UsableNet, which tracks filings in the New York and California state courts and in the federal courts, counted 360 new web accessibility lawsuits in the United States in September 2026. Ninety-one of those defendants already had a widget installed, and 78 had been sued over digital accessibility at least once before. Most of these cases are brought by people who use screen readers, and a screen reader meets your actual page, not your overlay's menu. If a visitor cannot finish your booking form with a keyboard, a toolbar that enlarges type does not answer the complaint. It mostly establishes that the business knew accessibility was a question and picked the cheapest available answer.
The test is the task, not the score
When we take over an inherited site, we do not start with an automated score. We pick the three tasks the business actually lives on — book, buy, contact — and complete each one with the keyboard alone, then again with a screen reader. That is the test a complaint describes. Scanners are necessary and not sufficient: they find the machine-detectable failures, and they cannot tell you whether a person could finish checkout.
Websites got less accessible last year, not more
The WebAIM Million, published in February 2026, ran an automated check over the home pages of the top one million websites. 95.9% had detected WCAG 2 failures, up from 94.8% a year earlier, at an average of 56.1 errors per page — 10.1% more than the year before. That is the second consecutive annual regression after six years of slow improvement, and WebAIM attributes part of the rise to heavier reliance on third-party frameworks and libraries and to automated or AI-assisted coding.
Increased reliance on 3rd party frameworks and libraries and automated or AI-assisted coding practices.
Read that in the order it happened. Writing a page got faster. A framework ships a component that renders correctly and says nothing about itself; a model asked for a dropdown returns the markup that looked right in everything it was trained on. Nobody decides to drop accessibility. It is simply one of the properties that stops arriving for free once the writing of markup moves one level away from the person accountable for it. The same shift that made your last build cheap is the one putting you on next year's filing list.
A widget is something you add. Accessibility is mostly something you remove — the assumption, baked into the markup, that every visitor has a mouse and is looking at the screen.
What actually fixes it?
- Complete your three money tasks with the keyboard alone, today.
- Run one screen reader through your checkout or contact form.
- Give every form field a real label, not a placeholder.
- Make every control a button or a link, never a styled div.
- Report every error in text beside the field, never by colour alone.
- Add contrast and keyboard checks to the build so regressions fail the pipeline.
Does this only matter in the United States?
No. The counts are American because US filings are public and countable; the obligation is not. The European Accessibility Act is an EU directive whose scope includes e-commerce services, and Member States had to write it into national law by June 2022 — which means the requirement reaches an exporter through that national law rather than through a court docket. Both regimes point at the same technical criteria, WCAG. That is the useful part: one remediation satisfies both. A widget satisfies neither, and it bills you every month until it is replaced.
So what is a widget still good for?
Two honest things. The preference controls are real features — larger text, higher contrast, reduced motion, a reading mask — and a visitor who needs one is better off with it than without it. And a widget is a single script tag, which makes it a defensible placeholder while real remediation is scoped, budgeted and scheduled. What it is not is a defence. Anyone who tells you their script makes you compliant is selling the demo, not the system. Before you renew, read the contract and find out who indemnifies whom; that one clause tells you what the vendor privately believes about its own product.
Your site has a keyboard test it has never been given.
Hamed Azimi
Founder, NexusWave
Hamed Azimi is the founder of NexusWave Technologies, a Vancouver-based AI-native digital agency and product studio.
We write these guides from real client work — GEO, SEO, and builds we've shipped. If a piece raised a question about your own site, we're happy to look at it.
- Straight answers, no retainer required
- We reply in your language — EN · فارسی
- Based in Canada, working worldwide
