A guide to accessibility overlays
Accessibility overlays are third-party scripts, usually shown as a toolbar, widget or plugin, that change how a web page appears in the browser without changing the page’s source code. Vendors sell them as a one-line route to accessibility compliance. They don’t deliver it. An overlay can adjust some display settings, but it can’t make a site conform to the Web Content Accessibility Guidelines (WCAG), and it often gets in the way of the assistive technology people with disabilities already use.
How overlays work
An overlay is a snippet of JavaScript added to a site’s templates. When a page loads, the script runs in the visitor’s browser and rewrites what’s displayed. It might add a menu for text size and contrast, inject labels or alt text it has guessed at, or change how elements announce themselves to a screen reader. Nothing in the site’s own code changes. Remove the script, and every “fix” goes with it.
Some vendors offer custom overlays tuned to a particular site. These are still a layer on top of the source code, and because they depend on the page structure they were built against, routine template and content changes can break them.
An overlay is also a third-party dependency you don’t control. If the vendor’s script loads slowly, so does your page, and browser extensions that block ads and scripts can block the overlay entirely.
Do overlays work?
Not for accessibility. Overlay widgets can toggle presentation settings, such as larger text, higher contrast or a different font. Most people who need those changes have already set them in their browser or operating system, where they work on every site, not just one.
What overlays can’t reliably do is fix the problems that actually block people, because those problems live in the source code and in judgments only a person can make. They include:
- Form fields without labels, and required fields or errors that aren’t identified
- Missing or incorrectly coded headings, and layout tables used for structure
- Alt text that’s missing, or present but meaningless
- Controls that can’t be reached or operated with a keyboard, and keyboard traps
- Focus order that doesn’t follow the page
- Link text that doesn’t say where the link goes
- Images of text, disabled zoom and locked screen orientation
- Missing captions and an incorrectly identified page language
An overlay that guesses alt text or adds labels on the fly can make some of these look fixed while leaving the experience broken. WCAG treats conformance as a property of the content people actually get, across full pages and complete processes, and a script that patches the rendering can’t establish it.
What overlays are like with a screen reader
Keith Bundy has used a screen reader for more than 35 years. Writing for Siteimprove in 2021, as a totally blind user and accessibility consultant, he described what overlays do to his experience of a site.
The first problem is conflict. People who rely on assistive technology have already configured their screen readers, browsers and devices. An overlay that adds its own keyboard shortcuts, menus or screen reader mode can override those settings and push the user into the overlay’s way of working. Bundy regularly found unlabeled graphics and buttons on sites whose overlays claimed full WCAG conformance.
The second is separation. Some overlays send users with disabilities to an alternate “accessible” version of the site, with reduced navigation, features and content. Bundy’s objection was direct: “I do not want a ‘separate but equal’ experience.” Title III of the Americans with Disabilities Act (ADA) promises people with disabilities the full and equal enjoyment of goods and services (42 U.S.C. § 12182(a)), and a stripped-down parallel site works against that.
The third is privacy. Overlays that respond to assistive technology appear to detect it, which leaves users wondering whether the site now knows they have a disability. Bundy didn’t believe that information was being passed on, but the uncertainty alone was reason enough for him to avoid these products.
The cost to the business follows from all three. Unless he had no alternative, Bundy said, “I will exit any site with an accessibility menu and go to a competitor’s site.”
His view isn’t an outlier. The European Disability Forum and the International Association of Accessibility Professionals have published a joint statement on accessibility overlays, and hundreds of accessibility practitioners have signed the Overlay Fact Sheet, which sets out why overlays don’t make sites accessible.
Do overlays protect against ADA lawsuits?
No. An overlay doesn’t remove the barriers a lawsuit is about, and sites with overlays installed continue to be named in digital accessibility lawsuits.
Regulators have acted on the marketing, too. In April 2025, the Federal Trade Commission approved a final order requiring accessiBe to pay $1 million over claims that its product could make any website WCAG-compliant. The order applies to that company’s advertising, not to overlays as a technology, but it treats the category’s central promise, automatic WCAG conformance, as a claim that needs evidence behind it.
Which rules apply depends on who you are. Under Title II of the ADA, the Department of Justice’s 2024 web rule sets WCAG 2.1 Level AA as the technical standard for state and local governments’ web content and mobile apps. Private businesses fall under Title III, which has no equivalent technical regulation, so courts decide case by case, and WCAG is the benchmark most often used. Federal agencies follow Section 508. Installing an overlay doesn’t satisfy any of them.
This section is general information, not legal advice.
What to do instead
The alternative to an overlay is accessibility built into the site itself, and kept there.
Fix issues in the source code. Labels, headings, alt text, keyboard support and focus management belong in templates, components and content, where every visitor and every assistive technology gets them.
Test in three ways. Automated accessibility testing finds many common issues quickly and at scale, but not all of them. Manual testing by people who know WCAG, including screen reader testing, covers what automation can’t judge. Testing with people with disabilities shows whether the site actually works for them.
Build it into the workflow. Catching barriers in design and development costs less than finding them after launch, so build accessibility into your workflow, from requirements through publishing.
Run it as a program. Digital accessibility has no end date. Every template change and new page can introduce barriers, so organizations that keep their sites accessible treat it as an ongoing program, with named owners, enforceable standards and monitoring. That’s also how you deliver what overlays promise and can’t: one site that works for everyone, which is the point of digital inclusion.
Frequently asked questions
Are accessibility overlays legal?
Yes, installing one is legal. The problem is that it doesn’t meet the obligation it’s sold for. The barriers in your site’s code stay in place, so an overlay isn’t a defense if the site is inaccessible.
Which accessibility toolbars are best for compliance?
None. No toolbar or widget makes a site compliant, because compliance depends on the site’s own content and code. The display controls these toolbars offer already exist in browsers and operating systems, where users set them once for every site they visit.
Should I use an overlay or hire an accessibility consultant?
The two aren’t equivalent. An overlay changes nothing in your code. A consultant, an audit or a trained in-house team can find and fix the barriers, and ongoing testing keeps them from coming back.
Is there ever a place for an overlay?
At most as a short stopgap while the real fixes are made, and even then it may push away the users it’s meant to help.