Why an accessibility overlay widget won't satisfy the EAA

The pitch sounds appealing

Install one line of JavaScript, and a script rewrites your page for visitors who need it — no developer time, no waiting for an audit. That's the pitch behind accessibility overlay widgets, and it's why they're popular.

It's also why they don't satisfy the European Accessibility Act.

What the EAA actually asks for

The EAA doesn't just ask "is your site usable by people with disabilities." It asks for documentation: real evidence against WCAG 2.1 AA (via EN 301 549), a published accessibility statement, and — under Article 14 — an assessment that gets reassessed at least every 5 years or whenever the service changes.

An overlay produces none of these. It's a live script that patches the rendered page in a visitor's browser. Your underlying markup — the thing an auditor, a regulator, or a screen reader actually interacts with — is unchanged. There's no report, no evidence trail, no statement.

This already went to court

In April 2025, the FTC finalised a $1,000,000 order against accessiBe, one of the largest overlay vendors, for claiming its widget could make any website WCAG-compliant. The order specifically found the widget failed on basic components — menus, headings, tables, and images. Not edge cases. The fundamentals.

That's not a knock on automation as a concept — Cluesia is an automated scanner too. It's specifically about the claim: that a client-side patch is equivalent to actually testing and documenting a site's real accessibility. It isn't, and a regulator checking for a published statement and audit evidence — exactly what's happening in France, the Netherlands, and Italy right now — won't find either behind an overlay.

What actually satisfies the requirement

Real testing against your real markup, a report you can hand to a regulator or a customer's procurement team, and a statement that's actually yours to defend.

See the full comparison →