Accessibility Overlays and Widgets: Why They Don't Make Your Website Compliant

Accessibility overlays are third-party scripts you add to a website, usually with a single line of code, that put an accessibility toolbar on the page or try to repair accessibility problems automatically as the page loads. Many are sold with the promise that installing them will make a site compliant with WCAG, and by extension with laws like Ontario's AODA.

They don't, and the reason is simple. Compliance with WCAG means the page meets every applicable success criterion. An overlay doesn't change your underlying code, templates, PDFs or videos. It sits on top and guesses. Some issues it can't reach at all, and many it can only patch inconsistently. The people who most need an accessible site, screen reader and keyboard users, already bring their own tools, and an overlay can get in their way.

None of this means the people who bought one did anything wrong. Overlays are marketed hard to busy owners who want a quick answer. This article explains what they are, why accessibility specialists have pushed back on them so strongly, and what to do with your budget instead.

What is an accessibility overlay?

"Overlay" is an umbrella term for front-end code, typically JavaScript, that alters how a website looks or behaves in the browser in the name of accessibility. They generally come in three forms, often combined in one product:

• Toolbars or widgets with buttons for larger text, higher contrast, greyscale, highlighted links, a "dyslexia font" or paused animations.
• Built-in text-to-speech that reads the page aloud.
• Automated repair scripts that scan the page and try to fix problems in the browser: adding alt text with image recognition, guessing form labels, adding ARIA attributes or keyboard handlers.

An "accessibility plugin" for WordPress, Shopify or another platform is often the same thing packaged for that system. The question to ask of any of them is the same: does it change the content and code your site serves, or does it run a script on top of it?

Do accessibility widgets work?

They do something, but not what most buyers think they're paying for. There are three separate problems.

The toolbar duplicates what users already have

People who need larger text, more contrast or speech output already have it, in their browser, their operating system or their assistive technology. Browser zoom, Windows contrast themes, macOS display settings, screen readers like NVDA and VoiceOver, and screen magnifiers all work across every site they visit. A toolbar that only works on your site, and works differently from the next site's toolbar, adds little for them.

Automated repair can't make judgement calls

Many WCAG requirements depend on meaning. A script can attach a machine-generated description to an image, but it can't know that the photo on your services page is meant to show your team at a client site. It can guess at a label for an unlabelled field, but guessing wrong is worse than nothing. It can't rewrite an error message to explain the fix, reorder content that only makes sense visually, or redesign a custom menu that traps keyboard focus.

Modern sites also change after they load. Pages built with frameworks such as React, Angular or Vue re-render content as people interact with them, which can undo or outrun a repair script's changes. This is the same limit that applies to any automated testing tool, covered in our article on automated vs manual accessibility testing, except that an overlay is trying to fix the problems as well as find them.

Some content is out of reach

Overlays work on the HTML of a page. They don't fix your PDFs and Word documents, add accurate captions to your videos, or repair content inside canvas elements, embedded third-party tools and most media players.

How overlays can conflict with assistive technology

This is the part that worries accessibility practitioners most. Screen reader users have their software configured the way they like it: speech rate, verbosity, navigation keys. When an overlay changes how a page is exposed to assistive technology, it can override those choices or introduce new problems. Common complaints include:

• Extra buttons, announcements or focusable elements added to every page, which keyboard and screen reader users have to get past.
• ARIA attributes added by guesswork that change how a control is announced, sometimes incorrectly.
• Slower pages, or content and controls that change unexpectedly while someone is using them.
• Features that try to detect whether someone is using a screen reader. Detecting assistive technology effectively reveals that a visitor has a disability, which is sensitive personal information.

Some assistive technology users block overlays entirely. For them, the experience is your underlying code, with no overlay at all.

The Overlay Fact Sheet

In response to aggressive overlay marketing, accessibility practitioners published the Overlay Fact Sheet. It explains what overlays are, sets out the technical reasons automated repair is unreliable, and states that full compliance can't be achieved with an overlay. It also raises the privacy concerns above, including settings cookies that can follow a user to other sites running the same overlay.

More than 1,000 people have signed it, including contributors to WCAG, ARIA and HTML, in-house accessibility specialists, lawyers, assistive technology developers and people with disabilities. Signatories commit to never recommending an overlay that makes deceptive compliance claims, to pushing for fixes at the source, and to encouraging site owners toward more durable accessibility work.

The FTC's 2025 order against accessiBe

Overlay marketing claims have also drawn regulatory attention in the United States. On January 3, 2025, the U.S. Federal Trade Commission announced a proposed order against accessiBe, maker of the accessWidget overlay. On April 22, 2025, the Commission approved the final order by a 3-0 vote.

According to the FTC's announcement:

• The FTC alleged that accessWidget did not make all user websites WCAG-compliant, and that accessiBe's claims that it could were false, misleading or unsubstantiated.
• It also alleged that accessiBe formatted third-party articles and reviews to look like independent opinions, without disclosing its material connections to the reviewers.
• The order requires accessiBe to pay $1 million, and bars it from claiming its automated products can make any website WCAG-compliant, or keep it compliant over time, unless it has evidence to support the claim. It also bars it from misrepresenting reviews or endorsers as independent.

Two points of fairness. The FTC is a U.S. regulator and its order applies to one company's marketing claims; it isn't a ruling on every product in the category. And the order doesn't ban overlays. What it does show is that "install this and you're compliant" was a claim a regulator found it needed to act on.

Accessibility overlays and the AODA

Under the AODA's Integrated Accessibility Standards, organizations covered by the website requirement need their public websites and web content to conform to WCAG 2.0 Level AA. Our page on AODA requirements, deadlines and penalties covers who that applies to. Nothing in the regulation treats an installed widget as meeting that standard. What counts is whether your site's content actually conforms.

That matters if your organization files AODA compliance reports, responds to a customer complaint, or answers an accessibility question in a procurement process. In each case you're describing what your site really does, and a plugin licence doesn't answer the question.

Overlay vs fixing the source: a comparison

What to do instead of an accessibility overlay

1. Start with a baseline. Run an automated scan to find the machine-detectable issues. Our free accessibility scan is a reasonable first pass, though it isn't a compliance check.
2. Get a manual audit of your key templates and journeys. Keyboard and screen reader testing finds the barriers that matter most and that no script can fix for you.
3. Fix issues at the source. Most problems live in a handful of templates and components. Fixing them once fixes every page that uses them.
4. Train the people who publish content. Alt text, headings, link text and documents are written by editors, not developers.
5. Publish an accessibility statement and a feedback route. Tell visitors how to report a barrier and get information in another format. Our guide on writing an accessibility statement walks through it.
6. Keep testing. Run automated checks when content changes, and repeat manual review when templates or key journeys change.

If you already have an overlay installed

Don't panic, and don't assume the site is fine either. Have the site evaluated on what its underlying code does, and check with a screen reader whether the overlay is interfering. Plan the fixes, and once the real issues are resolved, decide whether the overlay is still adding anything. Check your contract terms before you cancel.

Frequently asked questions