Accessibility overlay widgets and EAA compliance risk

Accessibility Overlay Widgets Are a Legal Liability, Not a Compliance Strategy

Last updated · September 7, 2026

The pitch is everywhere: add one line of JavaScript, a floating widget appears, and your site is instantly WCAG- and EAA-compliant. It sounds like a solved problem. It is not - and the legal record is now unambiguous about that.

Regulators, courts, and disability advocates have spent the last eighteen months systematically dismantling the overlay compliance claim. If your business is currently relying on an accessiBe, UserWay, or similar widget to satisfy its European Accessibility Act obligations, this post explains why that approach fails technically, why it is increasingly a litigation accelerant rather than a shield, and what genuine compliance actually requires.

What an Overlay Actually Does (and Doesn't Do)

An accessibility overlay is a JavaScript bundle, typically loaded from a third-party CDN, that runs on every page of your site after the HTML has finished rendering. The script analyses the DOM at runtime, attempts to detect accessibility issues, and tries to patch them by injecting ARIA attributes, modifying focus order, generating alt text from filenames, and presenting a sidebar widget that lets users toggle contrast, text size, and animation settings.

The pitch is seductive. The technical reality is that none of those runtime modifications change the underlying HTML. They exist only as long as the JavaScript runs, only in the browsers it supports, and only for the visitors whose assistive tools recognise them - which is far fewer than overlay vendors imply.

The timing problem

Screen readers like JAWS, NVDA, and VoiceOver build an accessibility tree from the DOM when the page loads. By the time overlay JavaScript executes, users have already encountered inaccessible content. The overlay's modifications may not even be picked up without a page refresh - which defeats the purpose entirely.

The detection ceiling

Automated tools can only catch approximately 30-40% of WCAG issues, according to W3C Web Accessibility Initiative research. The remaining issues require manual testing with screen readers, keyboard-only navigation, and other assistive technologies. An overlay's pattern-matching heuristics operate within that same ceiling - and then attempt to fix only a fraction of what they detect.

What overlays cannot fix

Logical reading order. If the underlying DOM order is wrong, injecting ARIA landmarks does not correct the sequence a screen reader follows.
Custom interactive widgets. A JavaScript-heavy date picker, carousel, or modal built without ARIA semantics cannot be reliably repaired at runtime. Adding role="button" to a <div> without attaching keyboard handlers creates an element a screen reader announces as a button but that cannot be activated by keyboard.
Inaccessible third-party iframes. Payment widgets, chat tools, and video embeds loaded in iframes are outside the overlay's DOM scope entirely.
Meaningful alternative text. Overlays generate alt text from filenames. A file named IMG_4872.jpg produces alt text of IMG_4872 - meaningless to a screen reader user.
An EAA-compliant accessibility statement. The EAA requires a published statement describing your conformance status, known gaps, and how users can report barriers. An overlay cannot produce this document, and its presence does not substitute for one.

When overlays make things worse

Documented issues include duplicate announcements (the screen reader reads the same text twice), focus traps (the keyboard gets stuck inside the overlay panel), and overridden settings (the overlay changes contrast settings the user had already configured at OS level). The National Federation of the Blind has issued a formal position opposing overlay products specifically because of how disruptive they are to assistive technology users.

Incorrect ARIA is worse than no ARIA. When an overlay injects role="button" onto a <div> without also attaching keyboard event handlers, it creates an element that screen readers announce as interactive but that keyboard users cannot activate. This is a new barrier introduced by the overlay — not a fix.

The Regulatory and Legal Record

The FTC drew the line in April 2025

The US Federal Trade Commission required accessiBe to pay $1 million to settle allegations that it misrepresented the ability of its AI-powered accessWidget to make any website compliant with WCAG - with the final order approved in April 2025. The FTC's complaint alleged that accessiBe claimed installing accessWidget's "one line of code" makes a website compliant with 30% of WCAG requirements immediately and initiates an AI process that achieves full compliance within 48 hours. The FTC found those claims were false, misleading, or unsubstantiated.

The order bars accessiBe from representing that its automated products can make any website WCAG-compliant or ensure continued compliance with WCAG over time, unless it has competent and reliable evidence to support such claims. The order remains in effect for twenty years, during which time accessiBe must file annual compliance reports with the FTC.

For EU businesses, the practical reading is this: the very compliance claim that justified purchasing the overlay has been ruled deceptive by a federal regulator. That is now Exhibit A in any litigation where a customer relied on those claims.

UserWay: a customer suing the vendor

In July 2024, BloomsyBox.com LLC - an online flower delivery service - filed a class-action lawsuit against UserWay at the Delaware District Court, alleging breach of contract after the overlay failed to prevent an ADA lawsuit against the company. UserWay had marketed its widget as a comprehensive solution that would ensure ADA compliance and provide up to $1 million in legal support if litigation occurred. Merely six months after installing the overlay, BloomsyBox was served with an ADA lawsuit. When it sought help from UserWay, the company sent a generic PDF guide and closed the ticket four days later. BloomsyBox spent $4,000 on external legal fees and settled independently.

A Magistrate Judge has since recommended denying UserWay's motion to dismiss, meaning the case will proceed. The pattern it illustrates - vendor promises compliance, customer gets sued anyway, vendor provides no meaningful support - is precisely the scenario EU businesses face when they treat an overlay as their EAA strategy.

The lawsuit data: overlays do not prevent claims

According to the 2025 Mid-Year ADA Website Accessibility Lawsuit Report, 456 lawsuits - representing 22.6% of all US web accessibility filings in the first half of 2025 - were filed against sites that already had accessibility widgets installed.

AudioEye's 2026 Web Accessibility Litigation Report found that 38.5% of businesses sued for inaccessibility in 2025 already had some form of accessibility solution in place - in most cases an overlay or widget marketed as instant compliance. When lawsuits arrived, plaintiffs were able to show that key site actions - forms, checkout flows, navigation - were still inaccessible despite the widget being present.

Plaintiff attorneys have learned that an overlay is not evidence of compliance. In some courts, it is evidence of awareness without remediation - which can be worse than doing nothing, because it demonstrates the business knew about its accessibility obligations and chose a tool that did not address them.

No US court has accepted an overlay as a valid compliance defence.

The EAA Dimension: EU Courts Are Scrutinising Substance

The European Accessibility Act has been enforceable across all 27 EU member states since 28 June 2025. The technical standard it references is EN 301 549, which incorporates WCAG 2.1 Level AA in full. Following EN 301 549 creates a presumption of conformity with the EAA - but that presumption requires actual conformance, not the presence of a widget that claims to produce it.

The first year of EAA enforcement has produced two instructive French rulings.

Carrefour: the first compliance order

On 4 June 2026, the Tribunal judiciaire de Caen ordered Carrefour France to make its website and mobile app fully accessible within six months, with a penalty of €500 for every day of non-compliance after that deadline. Carrefour had argued that achieving 71% conformity with France's accessibility standard (RGAA) was a reasonable position. The court rejected that argument: an obligation of result does not bend to a percentage. The ruling is the first under an EAA-transposition law to go against a retailer and the first anywhere in the EAA regime to cover a mobile app explicitly.

Auchan: dismissed on procedure, not on accessibility

The Auchan case was heard in May 2026 and dismissed on procedural grounds - a conflict between France's 2005 domestic revenue threshold and the EAA transposition - though the court explicitly acknowledged the website's inaccessibility. The court found "strong or major failures across 13 of 19 audited sections." Auchan did not dispute that its site was inaccessible. The dismissal turned entirely on which statute applied to that specific corporate entity's revenue figure - a narrow threshold argument that has no application to larger organisations.

The combined message from both rulings: EU courts will engage on the merits of accessibility, they expect full conformance, and partial scores are not a defence. An overlay that produces a compliance badge but leaves structural barriers in place would fare no better than Carrefour's 71% score.

The EAA applies based on who you sell to, not where you are based. If your e-commerce site sells to consumers in any EU member state and your annual turnover exceeds €2 million, the EAA covers you. Dutch regulators have already sent information requests to companies headquartered outside the EU.

What Actually Satisfies the EAA

An overlay cannot produce EAA compliance. Here is what does.

Establish your WCAG 2.1 AA baseline via EN 301 549

EN 301 549 v3.2.1 incorporates the full text of WCAG 2.1 Level A and AA. Achieving genuine WCAG 2.1 AA conformance across your consumer-facing digital products — website, mobile app, PDFs, embedded video — is the technical floor. Automated scanning is a starting point, not an endpoint: it detects at most 30–40% of issues. The remainder require expert manual testing with screen readers and keyboard-only navigation.

Remediate in the source code

Fixes must live in the HTML, not in a runtime JavaScript layer. Correct heading structure, native semantic elements (<button>, <label>, <nav>), logical DOM order, and properly implemented ARIA where genuinely needed. A custom widget that cannot be operated by keyboard must be rebuilt, not patched.

Publish a compliant accessibility statement

The EAA requires a published accessibility statement describing your current conformance level, any known gaps, the date of your last assessment, and how users can report barriers and request accessible alternatives. This is a separate legal obligation from being accessible — you need one even if your site is fully conformant. An overlay cannot produce this document.

Test with assistive technology users

Manual expert testing identifies the structural and semantic issues that automated tools miss. Testing with real screen reader users — not just automated screen reader simulation — surfaces the interaction failures that appear in litigation: keyboard traps, unlabelled form fields, inaccessible checkout flows.

Build accessibility into your release process

Accessibility is not a one-off project. New pages, new components, and third-party integrations can introduce regressions. Integrate automated checks into your CI/CD pipeline as a safety net, schedule periodic expert audits, and assign ownership so that accessibility does not erode between reviews.

Is Your Site Actually Covered? A Quick Self-Assessment

Before deciding on a remediation path, it helps to understand your current exposure. The widget below lets you assess your EAA risk profile and see what a realistic remediation roadmap looks like for your situation.

Practical Guidance for EU Businesses Using an Overlay Today

If you currently have an overlay installed, the following steps reduce your exposure while you plan a proper remediation programme.

Do not remove the overlay immediately without a plan. Removing it without addressing the underlying issues does not improve your accessibility - it just removes a visible signal. The structural barriers remain.

Do not rely on the overlay's compliance badge or certificate. These documents are generated by the vendor and have no legal standing under the EAA. A court or regulator will look at whether a person with a disability can actually use your site - not at a PDF certificate.

Treat the overlay as a temporary stopgap, not a destination. If budget or timeline constraints mean you cannot complete full remediation immediately, prioritise the highest-impact barriers: keyboard navigation, form labels, checkout flow accessibility, and page structure. These are the failures that appear in the vast majority of litigation.

Commission a professional audit. An expert audit combining automated scanning with manual screen reader testing will identify the full scope of your barriers - including the 60-70% that automated tools miss. The audit output gives you a prioritised remediation backlog and the evidence base for your accessibility statement.

Publish your accessibility statement. Even if your site is not yet fully conformant, a statement that honestly describes your current status, your known gaps, and your remediation timeline demonstrates good-faith effort. The EAA requires one regardless of your conformance level.

The Bottom Line

The overlay market was built on a compliance shortcut that does not exist. The FTC has said so. US courts have said so through consistent refusal to accept overlays as a defence. EU courts are now saying so under the EAA. And the litigation data - nearly one in four US accessibility lawsuits in the first half of 2025 hitting sites with widgets already installed - confirms that the shortcut does not even reduce legal exposure.

The EAA requires genuine conformance with EN 301 549, which means WCAG 2.1 AA delivered through source-code remediation, validated by expert testing, documented in a published accessibility statement, and maintained over time. An overlay satisfies none of those requirements.

If your current accessibility strategy is a widget, your EAA strategy is a gap.