Overlay widget vs. code-level fix — an honest comparison
In short: An overlay is a script that tries to patch accessibility in the browser; it does not change your underlying HTML, CSS or ARIA, so it cannot reliably make a site conform to WCAG 2.1 AA or EN 301 549. Code-level fixes change the source itself — slower than adding a script tag, but the only approach regulators treat as real compliance.
An accessibility overlay is a script you add to your site that promises to "fix" accessibility on the fly, usually via a floating widget. It's a tempting shortcut — but it doesn't do what the marketing implies. Here's what actually happens under the hood.
| Overlay widget | Code-level remediation | |
|---|---|---|
| What it changes | Injects a JavaScript layer on top of your existing HTML/CSS at runtime — the underlying markup stays the same. | Edits the actual HTML, CSS, and ARIA in your codebase — the markup itself becomes accessible. |
| Setup time | Minutes — add a script tag. | Depends on the number of issues; typically days to weeks of developer work. |
| Keyboard navigation & focus order | Can add controls, but can't reliably fix a broken DOM focus order or missing keyboard handlers baked into custom components. | Fixes focus order and keyboard handling at the source, so it works consistently across assistive technologies. |
| Screen reader compatibility | Frequently conflicts with screen readers that have their own optimizations for standard HTML — reports of overlays making pages worse, not better, are well documented. | Works with screen readers because it produces standard, correctly-labeled markup rather than injecting a parallel interface. |
| Legal risk | In January 2025, the U.S. FTC reached a $1 million settlement with accessiBe over deceptive claims that its overlay made websites ADA/WCAG compliant using AI — a widely reported case that shows regulators don't treat overlay claims as equivalent to real compliance. | Doesn't eliminate legal risk by itself, but the remediation matches what regulators and courts actually expect: an accessible underlying product. |
| Performance | Adds a third-party script and runtime DOM manipulation on every page load. | No added runtime overhead — the fix is the page. |
| What happens if you remove it | Accessibility reverts instantly to the pre-overlay state — nothing was actually fixed. | The fix persists — it's part of your codebase. |
Our honest recommendation
We don't sell an overlay, and we don't think you should rely on one as your primary fix. Use an automated scan to find code-level issues, fix them in your actual HTML/CSS (or have a developer do it), and use manual audits for what a scan can't catch. That's slower than adding a script tag — but it's the only approach that produces a website that's genuinely usable by people with disabilities, and the only one regulators have treated as real compliance.
Find your real code-level issues, free →Are all accessibility overlays the same?
Did a court or regulator actually rule against overlays?
Is there ever a legitimate use for an overlay?
What should I do instead?
accessiBe alternative · UserWay alternative · AudioEye alternative · Scan vs. audit · EU (EAA) guide · Methodology