Key takeaways
- Accessibility overlays add a toolbar or script on top of your site but leave the underlying code unchanged, so most barriers remain for screen reader and keyboard users.
- Overlays do not protect against lawsuits. UsableNet counted more than 1,400 digital accessibility lawsuits in 2025 against companies that had accessibility widgets installed.
- Regulators have stepped in: the FTC approved a final order in April 2025 requiring overlay vendor accessiBe to pay $1 million over claims that its widget could make any website WCAG-compliant.
- The reliable alternative is fixing the source code against WCAG 2.1 Level AA, confirmed with manual keyboard and screen reader testing.
- Accessibility is ongoing work. Build checks into design, content and development so fixes stay fixed.
Accessibility overlay widgets promise a quick fix: add one line of JavaScript and your website becomes ADA compliant. The pitch is appealing, but overlays rarely deliver it, and some disabled users say the widgets make sites harder to use. This Emulent guide explains why overlays fall short, what compliance actually requires and how to fix accessibility properly. It is general guidance, not legal advice.
Why don’t accessibility overlays work?
Overlays try to repair a page in the browser after it loads, but they cannot reliably fix problems rooted in the site’s code, content and design. A script cannot know what an image means, what a custom button does or what order a form should be read in.
- Guessed alt text: automated image descriptions often miss the purpose of the image, such as a product detail or a chart’s data.
- Broken custom components: menus, carousels, date pickers and modals built without proper markup still trap keyboard users.
- Conflicts with assistive technology: screen reader and magnifier users already have tools set up the way they like, and overlays can interfere with them.
- Toolbar fatigue: a contrast or font-size button does not help someone who cannot reach it by keyboard or whose screen reader announces it poorly.
- No change to the source: when the script fails to load or a new page is published, the original barriers are still there.
Accessibility professionals and disabled users have pushed back publicly. More than 800 practitioners have signed the Overlay Fact Sheet, which urges site owners not to rely on overlays and asks vendors to stop claiming they deliver compliance.
What does accessibility compliance actually require?
Compliance means meeting WCAG success criteria in the code and content of your site. WCAG 2.1 Level AA is the version courts and regulators cite most often, and WCAG 2.2 adds a few newer criteria. The standard rests on four principles: content must be perceivable, operable, understandable and compatible with assistive technology.
| Requirement | What it means |
|---|---|
| Alt text | informative images carry descriptions that convey their purpose; decorative images use empty alt text. |
| Keyboard access | every link, button, menu, form, modal and accordion works with a keyboard alone and shows a visible focus indicator. |
| Color contrast | at least 4.5:1 for normal text and 3:1 for large text. |
| Heading structure | a logical H1, H2, H3 order so screen reader users can scan the page. |
| Forms | labels tied to each field and error messages that explain how to fix the problem. |
| Media | synchronized captions on prerecorded video and transcripts for audio such as podcasts and webinars. |
Each of these lives in your templates and content. An overlay sitting on top cannot write a meaningful product description into an image or rebuild a menu that was coded without keyboard support.
How do you find the real accessibility problems on your site?
Combine automated scanning with manual testing on a sample of templates and your most important tasks, such as a lead form or checkout.
- Automated scans: WAVE, axe DevTools and Google Lighthouse flag missing alt text, contrast failures and empty links for free.
- Keyboard testing: put the mouse aside and use Tab, Shift+Tab, Enter, Space and the arrow keys to reach and operate everything.
- Screen reader testing: try NVDA on Windows, VoiceOver on Mac and iPhone and TalkBack on Android, listening for unlabeled buttons and unannounced errors.
- Content review: replace vague link text like “click here” with descriptive labels and check that page titles are unique.
- Rank by severity and traffic: fix barriers that block a task on high-traffic pages first.
The scale of the problem is large. The 2026 WebAIM Million report found detectable WCAG 2 failures on 95.9% of the top one million home pages, with low-contrast text the most common issue. Automated tools catch only part of what a manual review finds, so a clean scan does not mean a site is accessible.
What should you do instead of installing an overlay?
Fix the source, assign owners and keep testing. Remediation in the code removes barriers for every visitor, whether or not a script loads.
- Group issues by severity: fix anything that prevents task completion first, then issues that slow users down, then minor problems.
- Fix shared components: one repaired header menu, form or button style can clear the same error across hundreds of pages.
- Assign ownership: content teams handle alt text, link text and headings; designers handle contrast and focus styles; developers handle markup and custom widgets.
- Publish an accessibility statement that names the standard you target, known limitations and a contact for reporting barriers.
- Build accessibility into workflows: alt text on every upload, contrast checks in design review and keyboard testing before each release.
If you already pay for an overlay, removing it is a decision to make after the underlying fixes are in place, not before. The goal is a site that works without it.
The same work pays off in search and conversions. Many accessibility fixes also improve search performance and make sites easier for everyone to use. Search crawlers and screen readers both read the underlying HTML, so the same improvements help both.
- Alt text helps screen reader users and gives search engines context for image search.
- Logical headings help assistive technology users move through a page and help search engines and AI answer engines understand page structure.
- Descriptive link text tells users and crawlers where a link goes.
- Readable text, adequate tap targets and a logical focus order support mobile usability.
The audience is large. The CDC reports that more than one in four US adults has some type of disability. On WordPress sites built with a page builder, most fixes happen at the template and element level, so one change can carry across the whole site. Pair that work with solid SEO and the same improvements support rankings and leads.
How the Emulent team can help
Emulent builds accessibility into every website design project and audits existing sites with automated scans plus manual keyboard and screen reader testing. We turn the findings into a ranked fix list, remediate the code and set up checks so new content stays accessible, with no overlay required. Results depend on the size and age of each site. If you want to know where your website stands, contact the Emulent team.