Do accessibility widgets work, or just hide the problem?

Say you run an eight-person optical practice with three branches around Columbus, Ohio. A letter arrives on a Tuesday from a law firm you've never heard of. Your website isn't accessible, it says, and here are nine barriers and a number.

By Thursday your web person has installed a script. One line in the footer, a few hundred dollars a year. A small blue icon appears bottom right, with sliders for text size and contrast. The vendor dashboard says 97 percent compliant.

So do accessibility widgets work? At the narrow job of letting a visitor resize text and raise contrast, yes. At making a website conform to the Web Content Accessibility Guidelines (WCAG), no: the scanners score a page higher the day the widget goes on, while a keyboard and a screen reader find the same barriers still there.

The filing counts show what that gap is worth. UsableNet, which tracks US digital accessibility claims and also sells remediation, recorded 360 new web and app lawsuits in September 2026. Ninety-one of those defendants had a third-party accessibility widget running at the time.

What an accessibility widget actually does to your page

It is JavaScript that runs after your page has loaded, and it edits what the browser is holding in memory. It can recolour text, resize it, stop animations, guess alt text for images, and add ARIA attributes (Accessible Rich Internet Applications, the markup that tells assistive software what a control is and what state it is in). It cannot rewrite your source files. Switch the script off and every one of those changes goes with it.

That distinction matters because of who is reading. A screen reader reads the accessibility tree the browser builds from your markup. So does an automated scanner. So, in effect, does a plaintiff's expert witness. The widget edits that tree from the outside, last, with no idea what any of your controls are for.

What that looks like in practice:

• An image of your price list gets alt="price list" from a vision model. A person would have written out the eleven prices.
• An unlabelled date field in your booking form gets a generated name like "input 3". The scanner is satisfied. A screen reader user is not.
• Your mega menu gets role="navigation" bolted on, while the focus order underneath it still jumps from the logo straight to the footer.

Do accessibility widgets work for keyboard and screen reader users?

Not reliably, and that has now been measured rather than argued about.

Parker Hartman and Tim Gorichanaz at Drexel University built test sites with known accessibility errors, installed three commercial overlays, then tested the results twice: once with automated tools, once by hand with a keyboard and a screen reader. Their paper went to ASSETS '25, the ACM's accessibility conference, in October 2025. The automated tools reported an improvement. The manual testing found that major errors remained. All three overlays struggled to move keyboard and screen reader focus into a hamburger menu, which on a phone is the whole navigation.

They expanded the study for the 2026 ACM Conference on Fairness, Accountability and Transparency, published open access, and landed in the same place. The overlays helped most with alt text and form fields. On their own, they did not reduce legal exposure.

Sit with that pattern for a second. The tools that measure got better. The person using a keyboard did not.

Does an accessibility widget prevent an ADA demand letter?

No. On the filing data, sites running one still get sued under the ADA (the Americans with Disabilities Act, the US law most web accessibility claims are brought under).

UsableNet's figures for the first half of 2026 put around 20 percent of sued companies as having a widget or overlay installed when the claim arrived. That is a vendor's number from a vendor with remediation to sell, so weigh it accordingly. The monthly tracker is harder to argue with: 91 of 360 in September 2026.

The marketing has already drawn a regulator. In January 2025 the US Federal Trade Commission brought a complaint against accessiBe, whose accessWidget had been sold as making a site compliant with 30 percent of WCAG immediately and the other 70 percent within 48 hours. The FTC said the widget had failed to make basic components such as menus, headings, tables, images and recordings conform, and that the claims were therefore false, misleading or unsubstantiated. The Commission approved a final order on 22 April 2025: a $1 million payment, plus a bar on claiming its automated products can make any website WCAG-compliant without evidence behind it. accessiBe denied the allegations and settled without admitting them.

You will also hear that a widget signals to a plaintiff's lawyer that you knew about the obligation and bought the cheapest thing on the shelf. We have not seen that tested in a judgment, so treat it as a theory about motive rather than a finding.

Why does your scanner score go up when nothing got easier?

Because automated checks read the markup the browser ends up with, and changing that markup after the fact is the widget's entire job.

Automated testing only ever catches part of the problem. A tool can tell you an image has no alt attribute. What it cannot tell you is that alt="image" is a lie. Flagging a button with no accessible name is easy; noticing that the name reads "click here" is not.

Contrast, labels, empty links: all machine-checkable. Whether a human can finish your three-step booking flow without a mouse: not machine-checkable. Someone has to sit down and try.

There is one more wrinkle, from this year's data. WebAIM's 2026 Million report scanned the top million home pages and found 95.9 percent carried WCAG 2 A or AA failures that automated tools could detect, at an average of 56.1 errors per page, up 10.1 percent on 2025. Further down: pages using ARIA averaged 59.1 detected errors, against 42 on pages using none at all. More accessibility attributes, more errors.

That is correlation, and WebAIM's numbers do not isolate overlays. Complex pages use more ARIA, and complex pages break in more places. But injecting ARIA at scale, from outside, with no knowledge of what a control does, is the one technique every overlay has in common. The direction of that figure should slow you down.

Which accessibility failures should you fix first?

Start with the six that turn up most often, because they are the cheapest to fix and the most frequently cited in demand letters. WebAIM's 2026 scan ranks them:

1. Low contrast text, on 83.9 percent of home pages.
2. Missing alternative text for images, 53.1 percent.
3. Missing form input labels, 51 percent.
4. Empty links, 46.3 percent.
5. Empty buttons, 30.6 percent.
6. Missing page language, 13.5 percent.

Not one of those needs a redesign. The last is a single attribute on your <html> element. Contrast is a stylesheet change, and if your brand palette fails at 4.5:1 for body text, that is a conversation with whoever owns the brand rather than a technical problem. Labels and empty buttons usually live in a theme or a page builder, so they get fixed once and stay fixed everywhere.

Then do the part no tool reports. Unplug your mouse. Tab through the contact form, the booking flow, and the menu at phone width. Watch for the focus ring vanishing behind a sticky header.

If you cannot finish a booking, a share of your customers cannot either, and no script in the footer will change it. Third-party embeds make this worse rather than better: we wrote about what a chat widget does to a page, and the same scripts arrive with their own focus traps and unlabelled buttons.

While you are in the forms, check they are actually delivering. A perfectly accessible form that is quietly landing in spam is a different leak with identical symptoms.

Where an accessibility widget is the honest choice

When you cannot yet afford to fix the code, and you treat the widget as a stopgap with a date on it.

This is the part that costs us something. Say you have a 600-page WordPress site, eight years of accumulated plugins, and a library of scanned PDF price lists. A real audit and remediation on that is a project, and we will quote you far more than a widget costs. For some businesses the honest sequence is to install the widget this month, fix contrast and labels next month, rebuild the booking flow in spring, and keep the widget running in the meantime because a contrast slider genuinely helps some people today.

What we will not do is pretend the widget is the finish line. There is a limit on our side too. We fix websites, and we do not retype a decade of scanned PDFs into accessible documents. For plenty of businesses that archive is the bigger liability and the bigger bill. If somebody quotes you a flat fee to make everything compliant, ask them what happens to the PDFs.

We also do not give legal advice and cannot make anyone lawsuit-proof. A site conforming to WCAG 2.2 AA can still receive a demand letter. What changes is what happens after it arrives.

What changes for web accessibility in 2027 and 2028

Two dates are already fixed.

In the US, the Department of Justice's Title II rule sets WCAG 2.1 Level AA as the technical standard for state and local government web content. An interim final rule published on 20 April 2026, at 91 FR 20902, pushed the compliance dates back a year: 26 April 2027 for public entities serving 50,000 people or more, and 26 April 2028 for smaller entities and special districts. The Department said it had overestimated what covered entities could manage, on staffing and on technology, inside the original window. Title II covers government, not your shop. It still reaches you if you sell to a school district, a county, a transit authority or a utility, because their procurement will start asking you for conformance evidence long before their own deadline.

Europe is moving the bar rather than the date. The European Accessibility Act has applied since 28 June 2025, and the standard EN 301 549 is its technical route. ETSI, the European Telecommunications Standards Institute, which writes that standard, published version 4.1.1 in September 2026, and it moves the benchmark from WCAG 2.1 to WCAG 2.2.

That version carries no legal presumption until the European Commission cites it in the Official Journal, and ETSI's own schedule targets late 2026 for the citation. So the cited version today is still v3.2.1, built on WCAG 2.1 AA. Microenterprises providing services, meaning under ten staff and turnover under two million euros, sit outside the Act's service obligations.

Build for WCAG 2.2 anyway. W3C's WCAG 2.2 adds six A and AA criteria that no overlay can reach, because none of them is about markup attributes: focus not obscured, dragging movements, a minimum target size of 24 by 24 CSS pixels, consistent help, redundant entry, and accessible authentication.

A script cannot make an 18-pixel tap target bigger without wrecking your layout. It cannot take the puzzle out of your login. Those are design and code decisions. No script makes them for you.

Do one thing this week

Open your site in a phone-width window, unplug the mouse, and try to book an appointment or send the contact form using only Tab, Enter and the arrow keys. Write down where you get stuck. That list is your real accessibility backlog, already in priority order, and it is worth more than any dashboard percentage.

If it runs longer than you would like, that is what our website development work covers: contrast, focus order, labels, keyboard flows, and the templates so it stays fixed after we go. Fixing the code also leaves you owning the fix, and who owns the code matters more than most people expect. Tell us what broke and we will tell you what it takes.