Accessibility overlays and the EAA: why a widget does not make your site compliant
There is a sales pitch that has landed in the inbox of almost every European web team since the European Accessibility Act came into force on 28 June 2025: install this one line of JavaScript and your site becomes compliant overnight. The product is an accessibility overlay, a widget that sits in a corner of the page and offers bigger text, higher contrast, a "screen reader mode" and, in the more ambitious versions, machine-generated alt text.
It is worth being precise about what these tools do, because the gap between the promise and the legal reality is where the risk lives.
What an overlay actually changes
An overlay runs after your page has loaded, in the visitor's browser. It can restyle what is already there: enlarge fonts, invert colours, pause animations, add an outline to links. Some of them also try to patch the code on the fly, guessing an alt text for an image that has none or wrapping an unlabeled button in a label they infer from the icon.
Three things follow from that, and they matter for the EAA:
- It does not change your code. The HTML your server sends is exactly as accessible, or as inaccessible, as before. Every audit, every screen reader that does not load the widget, every crawler and every conformity assessment sees the original page.
- It only works for people who find and use the widget. Most disabled visitors arrive with their own assistive technology already configured: a screen reader, a braille display, a switch, magnification. They did not ask for a second, unfamiliar layer on top, and a well-documented complaint from that community is that the layer gets in the way of the tools they rely on.
- The guesses are guesses. A machine that labels a "Submit" button as "arrow icon" has not made your checkout accessible. It has made the error harder to see in a test report.
What the EAA asks for instead
The Directive (EU) 2019/882 does not mention widgets, badges or vendors. It sets functional accessibility requirements for the products and services in scope (e-commerce, banking, transport, e-books, telecoms and the rest) and points to the harmonised standard, EN 301 549, which for web content means the WCAG 2.1 level AA success criteria.
Those criteria are about the thing you ship: does every image have a text alternative, does every form field have a name, can the whole journey be completed with a keyboard, is the focus order sensible, is the contrast sufficient by default, are errors described in text. They are also about the organisation: the service must carry an accessibility statement, explain how it complies, list what does not comply yet and give people a way to report problems.
Market surveillance authorities in each Member State can ask an operator to demonstrate conformity. The answer they expect is an assessment against the standard and the documentation behind it. "We installed a plugin" is not an assessment, and no overlay vendor will sign your declaration for you.
The EAA puts the obligation on the economic operator. You can outsource the testing and the fixing. You cannot outsource the responsibility to a script tag.
The track record
The overlay market grew up in the United States, under the ADA, and that is where the evidence is longest. Two data points are enough to frame it:
- For several years running, a meaningful share of web accessibility lawsuits filed in the US have been against sites that already had an overlay installed. The widget did not stop the complaint, because the complaint was about the underlying code.
- In January 2025 the US Federal Trade Commission ordered one of the largest overlay vendors to pay one million dollars over claims that its product could make any website compliant with accessibility guidelines. The FTC's finding was that the claims were not supported.
More than eight hundred accessibility practitioners, many of them disabled users themselves, have signed a public statement asking site owners not to rely on overlays. That is an unusual level of agreement in a field that argues about most things.
When an overlay is not harmful
None of this means the widgets are useless. A visitor without assistive technology who simply wants larger text on a long article gets something from a font-size control. If you already have an accessible site and you add a widget as a convenience, the widget is not the problem.
The problem is the order of operations. The widget goes on top of an accessible site; it does not stand in for one. If your budget covers either the overlay subscription or two days of a developer fixing labels and focus order in your templates, the second option moves you towards the Act and the first does not.
What to do instead
A practical route that we see working for small and mid-sized operators:
- Audit the real journeys, not the whole site. Sign-up, search, add to basket, checkout, contact. Test each one with a keyboard only and with a screen reader, then run an automated scan for the rest. Automated tools catch roughly a third of the criteria; the rest needs a person.
- Fix in the templates. One corrected component fixes every page that uses it, and it stays fixed on the next deploy.
- Write the accessibility statement while the audit is fresh: what complies, what does not yet, when it will, and how to report a problem. Publish it where a visitor can find it in one click.
- Put accessibility in procurement. Ask every vendor of a component, a theme or a plugin for its own conformity evidence. This is where most regressions come from.
- Re-test on release. A short checklist in the pull request template does more than any annual audit.
If you want a quick reading of where a site stands before deciding on any of this, an automated scan against EN 301 549 is a reasonable first step, as long as everyone understands it is the beginning of the assessment and not the end of it.