Why Accessibility Overlay Widgets Don't Work (And What Actually Does)
Accessibility overlay widgets do not make a website WCAG-compliant, and they do not prevent ADA lawsuits — 22.6% of websites sued for ADA violations already had an overlay installed at the time of suit. Overlays are JavaScript toolbars that patch the rendered page at runtime; the theme source code that creates the barriers is never changed. This guide explains why that architecture fails, how plaintiff attorneys actually test stores, and what source-code remediation looks like instead.
What Overlay Widgets Are
Overlay widgets are third-party JavaScript snippets that inject a toolbar or panel onto your website. They typically offer options like font size adjustments, high contrast mode, screen reader "optimization," and various visual modifications. The pitch is simple: add one script tag, and your site becomes compliant with the ADA and WCAG standards.
The reality is far more complicated.
Why Overlays Fail
They Do Not Modify Source Code
WCAG compliance is defined at the source code level. An image without an alt attribute is a violation regardless of what a JavaScript widget does after the page loads. Overlays manipulate the DOM at runtime but do not change your theme files, your Liquid templates, or your HTML output. When the overlay script fails to load (network issues, ad blockers, JavaScript errors), every underlying violation is fully exposed.
They Can Break Screen Readers
Screen readers like JAWS, NVDA, and VoiceOver have been refined over decades to parse standard HTML semantics. When overlays inject additional ARIA attributes, modify focus order, or restructure the DOM at runtime, they frequently conflict with the screen reader's own processing. Disability advocacy organizations have documented cases where overlays made websites less accessible, not more.
Regulators Have Challenged Unsupported Overlay Claims
The U.S. Federal Trade Commission finalized a $1 million order against accessiBe in 2025 over unsupported accessibility claims. Public accessibility guidance also points merchants back to the same practical requirement: the underlying content and functionality needs to be accessible to people using assistive technology.
The Lawsuit-Protection Myth
Overlay vendors frequently market their products as lawsuit protection. The data tells a different story. Websites using popular overlay products have been named in ADA lawsuits. In some cases, the presence of an overlay has been cited by plaintiffs as evidence that the website owner was aware of accessibility issues but had not remediated the underlying source.
Performance and Privacy Impact
Overlay scripts add JavaScript payload to every page load, increasing load times and consuming client-side resources. Some overlay products also track user interactions and disability-related preferences, raising significant privacy concerns under GDPR and state privacy laws.
How Plaintiff Attorneys Actually Test Websites
Plaintiff attorneys use the same testing tools as accessibility professionals:
- axe-core (the open-source engine used by Accessibility Insights and AccessComply)
- NVDA + Firefox and JAWS + Chrome for screen reader testing
- Lighthouse for automated auditing
- Manual keyboard navigation testing
These tools test the underlying source code, not the marketing promise. axe-core runs against the DOM and can distinguish HTML-native accessibility from JavaScript-patched accessibility — and actual screen reader users often navigate your page before the overlay's JavaScript has fully executed. Plaintiff counsel typically runs an automated scan to identify violations, then manual screen reader testing to demonstrate the experience is actually broken. Overlays fail both tests in many cases.
The JavaScript-disable test
Here is a test you can run right now on any site using an overlay:
- Open your browser's developer tools
- Disable JavaScript
- Reload the page
- Run an accessibility check
Without JavaScript, all of the overlay's "fixes" disappear. Every untagged image becomes inaccessible again. Every button without an ARIA label loses it. Every form without a label association breaks. Plaintiff attorneys know this test, courts can see it, and the underlying violations — the ones in your actual HTML — are still there. Alternatively, run a free scan — AccessComply evaluates the served source, not the overlay's runtime patches.
The Settlement Pattern for Sites With Overlays
Attorneys who defend ADA cases report a consistent pattern. When a defendant has no overlay, settlement negotiations center on a remediation commitment plus a monetary settlement. When a defendant has an overlay, the negotiation gets more complicated:
- The defendant believes (incorrectly) that they have already addressed the problem
- The plaintiff's attorney has to spend time explaining why the overlay doesn't count
- Courts are less sympathetic to defendants who paid for a product that claimed compliance but didn't deliver it — it suggests they knew about the problem and chose a superficial fix over genuine remediation
Disability rights organizations have filed amicus briefs arguing specifically that overlays do not constitute compliance, and the Overlay Fact Sheet — signed by hundreds of accessibility professionals, including people with disabilities — urges businesses to avoid overlay products entirely.
The Cost-Benefit Calculation
- An overlay subscription runs
$49/month ($588/year) and produces zero source-code remediation. - A source-code fix tool at the same price — AccessComply Starter is $49/month — produces eligible theme fixes, backups before every write, and verification re-scans.
- The average ADA lawsuit settlement for a small ecommerce store is $5,000–$25,000, plus $10,000–$50,000 in defense fees.
The subscription price is similar either way. The remediation record is completely different.
What Actually Works: Source-Code Fixes
Genuine WCAG compliance requires fixing the code that generates your web pages. This means:
- Adding
altattributes to images in your Liquid templates, not injecting them via JavaScript after the page renders. - Modifying CSS to meet contrast ratios, so compliance persists even when JavaScript is disabled.
- Adding
<label>elements to form fields in your HTML, creating proper semantic associations that screen readers understand natively. - Implementing skip navigation links, proper heading hierarchy, and ARIA landmarks in your theme's layout files.
- Ensuring keyboard focus management works at the template level, not through fragile runtime patches.
How AccessComply Differs
AccessComply is not an overlay. It is a Shopify app that scans your store for WCAG 2.1 AA violations using axe-core, then generates real source-code fixes that modify your theme's Liquid, CSS, and HTML files. Fixes are written directly to your theme through the Shopify API, verified by a post-fix re-scan, and can be rolled back at any time.
The result is remediation that does not depend on a third-party JavaScript widget loading successfully. Your theme serves improved markup, CSS, and Liquid output before any overlay script has a chance to run.
The Accessibility Community's Position
The overlay controversy is not new in the accessibility industry. Hundreds of accessibility professionals have signed the Overlay Fact Sheet explicitly stating that overlays cannot substitute for genuine accessibility. The National Federation of the Blind, the American Foundation for the Blind, and disability advocacy organizations across the US and EU have all called for bans or disclosures around overlay marketing claims.
For Shopify merchants, the practical takeaway is clear: use overlays only as optional display controls, not as the accessibility plan. The work that matters is scanning the storefront, fixing the source where it is safe to do so, and keeping a clear record of what changed.
Further Reading
Scan your store first, then fix issues in the theme
AccessComply finds WCAG issues by page, creates backups before paid fixes, and re-scans before marking violations resolved. No overlay widget.