The Promise: One Script Tag to Fix Everything
Accessibility overlays are JavaScript-based tools added to existing websites to patch accessibility problems without modifying the underlying code. The pitch is compelling: install a widget, get WCAG compliance, and avoid EAA penalties — all in under an hour.
The major players in this space include AccessiBe, UserWay, AudioEye, EqualWeb, and Accessiblity.cloud. These tools typically inject a floating toolbar into the page that lets users toggle settings like increased contrast, larger text, or "screen reader mode." Some go further, using AI to attempt real-time fixes — rewriting alt text, adjusting heading structure, or modifying ARIA attributes on the fly.
The market exists because accessibility is hard, expensive, and time-consuming when done properly. Retrofitting a poorly built site to meet WCAG 2.1 AA can require months of engineering work. Overlays offer an apparent shortcut. That shortcut does not hold up under scrutiny.
Why Overlays Do Not Work
They Cannot Fix What Is Broken Underneath
An overlay sits on top of a rendered page. It can modify what users see or hear, but it cannot change the fundamental structure of the HTML the assistive technology receives before the overlay has fully initialised — and even after initialisation, the intervention is incomplete.
Consider a form built without proper <label> elements linking to their inputs. A screen reader user navigating by tab will land on an unlabelled field with no programmatic name. The overlay may attempt to infer a label from nearby text and inject an aria-label, but this inference is frequently wrong, inconsistent across browsers, and applied too late in the rendering cycle for some assistive technologies to pick up reliably.
The same logic applies to missing heading structure, incorrect reading order, non-descriptive link text ("click here," "read more"), colour contrast built into image assets, keyboard traps in custom components, and time limits on session tokens. These are structural problems. They require structural fixes.
The Overlay Fact Sheet: 800+ Professionals Agree
The most authoritative statement on overlays comes from the accessibility community itself. OverlayFactSheet.com is an open letter signed by more than 800 accessibility practitioners, researchers, and disabled users. The letter states plainly:
"We the undersigned, representing different facets of the accessibility community, call for the end to the use, sale, and marketing of accessibility overlay products."
The signatories include some of the most respected names in the field. Their objections are not theoretical. They are based on documented failures: overlays breaking existing accessible functionality, conflicting with screen reader keyboard shortcuts, and introducing new bugs while claiming to fix old ones.
The letter also notes the systematic misrepresentation in overlay marketing — specifically claims of "full WCAG compliance" or "ADA/EAA protection" that no overlay product can legitimately make.
The European Disability Forum's Position
The European Disability Forum (EDF), which represents over 100 million disabled people in Europe, has explicitly warned against using overlays as a compliance strategy. In their guidance on the European Accessibility Act, the EDF states that overlays do not constitute a valid accessibility solution and should not be relied upon to meet the requirements of Directive 2019/882.
The EDF's position reflects a broader consensus among disability organisations: overlays do not represent equal access. They represent a performance of compliance that satisfies marketing departments while failing the actual users the legislation is designed to protect.
The National Federation of the Blind
In the United States, the National Federation of the Blind (NFB) — the largest organisation of blind people in the country — issued a strong statement against AccessiBe specifically in 2021, following sustained complaints from blind users. The NFB documented cases where AccessiBe's overlay actively degraded the experience for screen reader users, in some cases making previously navigable sites impossible to use.
This is the most important point, and it bears repeating: overlays can make things worse. When an overlay intercepts keyboard events to manage its own widget, it can interfere with the standard keyboard shortcuts that screen reader users depend on. NVDA and JAWS users navigate by headings (H key), links (K key), and form fields (F key). An overlay that captures these keystrokes for its own purposes does not just fail to help — it actively blocks access.
Litigation Has Not Been Prevented
AccessiBe has faced multiple lawsuits from disabled users in the United States, including a class action filed in federal court arguing that websites using AccessiBe remained inaccessible to blind users despite the overlay's presence.
The fundamental legal problem is straightforward: courts look at whether a disabled person can actually use a site, not at whether a vendor's widget is installed. An overlay cannot provide a legal defence if the underlying accessibility barriers remain.
What the EAA Actually Requires
The European Accessibility Act (Directive 2019/882) does not permit cosmetic compliance. Its requirements are structural.
The directive mandates that digital services be accessible by design, referencing EN 301 549 as the harmonised technical standard. EN 301 549 maps directly to WCAG 2.1 Level AA for web and mobile interfaces. This is not a standard that can be satisfied by a third-party toolbar injected after the page renders. It requires that the underlying HTML, CSS, and interactive components be built to specification.
The EAA covers a specific and broad set of sectors:
- E-commerce — online shops selling to EU consumers
- Banking and financial services — consumer banking, payment services, digital banking apps
- Transport — booking interfaces, passenger information systems
- Telecommunications — consumer-facing digital services
- Customer support channels — including chat and messaging interfaces
Enforcement has been active since 28 June 2025. Member states have transposed the directive into national law with their own enforcement bodies and penalty structures. The consequences of non-compliance are material:
- Spain: fines up to €1,000,000
- Germany: fines up to €100,000
- France: fines up to €50,000
These penalties are per infringement, not annual caps. A site with persistent accessibility barriers is not protected by an overlay installation. It is still non-compliant, and it is still exposed.
What Actually Works
Genuine accessibility compliance requires building accessibility in at the design and development phase — not adding it retrospectively with a script tag.
The practical requirements are well understood:
Semantic HTML: Use the correct elements for their intended purpose. <button> for interactive controls, <nav> for navigation regions, <main> for primary content, <h1> through <h6> in a logical hierarchy. Semantic elements carry implicit ARIA roles that assistive technologies understand without additional annotation.
Explicit ARIA where needed: When semantic HTML cannot express the required semantics — custom dropdowns, modal dialogs, live regions for chat messages — use ARIA attributes correctly. aria-label, aria-labelledby, aria-describedby, role, aria-live, aria-expanded. The key word is "correctly": ARIA misuse is consistently among the most common accessibility failures auditors find.
Keyboard navigation: Every interactive element must be reachable and operable by keyboard alone. Focus order must follow a logical reading sequence. Focus must never be trapped (except in modal dialogs where it must be deliberately managed). Focus must be visible — the default browser outline is often insufficient; design a visible focus indicator.
Colour contrast: Text must meet the 4.5:1 ratio requirement against its background at normal sizes (3:1 for large text). This must be verified in the design system and cannot be patched at runtime.
Regular audits with assistive technology: Automated testing tools (axe, Deque's toolchain, Lighthouse) catch approximately 30-40% of WCAG failures. The remainder require manual testing with actual screen readers — NVDA and JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android. If your team is not doing this, you do not know whether your product is accessible.
For customer support and chat interfaces specifically, the standard is the same: the interface must be keyboard navigable, screen-reader compatible, and free of colour-only information. Tools built with accessibility as a foundational requirement — not retrofitted — are the only defensible choice. AISWise's chat platform was built to WCAG 2.1 AA from the ground up, not patched to meet it after launch. If you are evaluating customer support tools for EAA compliance, see how AISWise approaches this in practice.
The Future: AI-Powered Accessibility Beyond Cosmetic Fixes
The overlay industry's use of "AI" deserves scrutiny. When AccessiBe or UserWay describe their AI, they mean a system that attempts to infer missing accessibility metadata at runtime — generating alt text from image content, guessing at form field labels, restructuring heading levels. This is AI as patch.
The more significant question is what genuine AI-powered accessibility looks like when built structurally rather than applied as a surface layer.
Structural accessibility AI means systems that understand the semantics of an entire interface — not just individual elements in isolation. It means generating meaningful alt text that describes an image in context, not in isolation. It means navigation assistance that understands the user's task, not just the current page structure. It means personalisation that adapts interaction patterns to individual users' access needs without requiring them to configure a widget.
This is not about replacing human expertise in accessibility auditing. It is about extending what is possible when AI is integrated into the accessibility layer from the beginning rather than added afterward.
AISWise is building toward this: starting with customer support — one of the highest-traffic accessibility failure points — and expanding toward broader web experience accessibility. The architecture is the same whether the interface is a chat window or an entire web application: semantic structure first, AI augmentation on top of that structure, and continuous testing against real assistive technology use cases.
If your organisation is evaluating how to meet EAA requirements with tools that will remain compliant as standards evolve, start with AISWise's approach to accessible AI.
The Summary
Accessibility overlays are not a compliance solution. They are a compliance liability. The accessibility community has documented their failures consistently and at scale. The European Disability Forum has warned against relying on them. Courts in the US have not accepted them as a defence. The EAA does not make an exception for websites that have installed a widget.
The directive requires accessible digital services. That means semantic HTML, keyboard navigation, proper ARIA, tested with assistive technology, maintained over time. It means building accessibility into the product, not bolting it on afterward.
Any business operating in the EU that believes an overlay has addressed its EAA exposure should commission an independent accessibility audit before that assumption is tested in front of a market surveillance authority.
The cost of getting this right is lower than the cost of getting it wrong.