The Federal Trade Commission did not ban accessibility overlays. It barred a claim, that automation alone can make any website conform to WCAG, and that claim was always the weak part, because a script that runs after your page loads can reach only a thin slice of what WCAG asks.
In 2025 the FTC finalized an order requiring accessiBe to pay $1 million. If you pay for a widget today, the order doesn't make it illegal, and it doesn't make it useful. It does make this a good moment to ask what the widget actually does on your pages, what it can't do, and how to take it out without leaving your users worse off for a month. This piece covers all three, plus the paragraph you'll need for your board.
What the order says, and what it doesn't
The order is about advertising. Besides the payment, it bars the company from claiming, without supporting evidence, that its automated product can make any website conform to WCAG. It also bars the company from presenting reviews or articles as independent when it has a material connection to them.
It does not regulate your website. It doesn't declare overlays unlawful, and it names one vendor, not a category. But the reasoning travels. If a claim of automated conformance needs evidence, the only evidence that would count is an evaluation of real pages against real success criteria, with real assistive technology. That is an audit, and an audit reads the source code the overlay leaves unchanged.
Two practical checks follow:
- Read your vendor's promises. If the contract or sales deck says the product delivers conformance or legal protection, ask for the evidence in writing.
- Read your own accessibility statement. If it says your site is accessible because of a widget, that is now your claim, made in public.
What a script injected after load can change
An overlay is JavaScript that loads with your page, inspects the DOM, and edits it. That gives it real, if limited, powers:
- Attributes. It can add
alttext to images, often generated by image recognition, andaria-labelvalues to unlabeled buttons, usually guessed from class names likeicon-cart. It can addroleattributes and a pagelang. - Presentation. It can offer a toolbar that changes font size, spacing, or colors, which browsers and operating systems already do.
- Additions. It can insert a skip link or a focus outline.
These are mostly problems a scanner can detect, which is no coincidence: the overlay finds them with the same kind of rules. Automated detection has known limits. When the UK Government Digital Service tested ten automated tools against a deliberately inaccessible page in 2017, the best tool found 41% of the known barriers. An overlay can't repair what its detection never sees.
What it can't change reliably
The table is the short version. The long version is that accessibility lives in meaning, order, and behavior, and all three are set by your source code.
| Problem | Can a post-load script fix it? | Why not |
|---|---|---|
| Unlabeled icon button | Sometimes | The label is a guess from class names or position |
| Alt text that conveys meaning | Rarely | Recognition says "chart"; the user needed the numbers |
| Custom dropdown with no keyboard support | No | It needs event handling and state logic in your code |
| Focus order that jumps around the page | No | Order comes from your templates |
| Video without captions, PDF without tags | No | Neither is in the DOM to edit |
| Payment form in a third-party iframe | No | Scripts can't edit other origins |
Custom widgets are where an overlay's fix can be worse than nothing. Here is a typical one:
<!-- After the overlay runs -->
<div class="btn-cart" role="button" aria-label="cart">…</div>
<!-- The source fix -->
<button type="button" class="btn-cart" aria-expanded="false" aria-controls="mini-cart">
Cart, <span id="cart-count">2</span> items
</button>The first version announces "cart, button" to a screen reader. It still can't receive keyboard focus, and Enter and Space still do nothing, because a role is a promise and the overlay can't write the JavaScript that keeps it. The second version gets focus, keyboard activation, and an accurate name from the browser, for free. The W3C's ARIA Authoring Practices Guide lists the keyboard behavior each widget role promises. None of it can be inferred from the outside.
Single-page apps add a timing problem. Your framework re-renders a component, the injected attributes vanish, and the overlay patches the new nodes a moment later, or doesn't. A screen reader user who arrives during that moment hears the unpatched version.
When the widget argues with the user's own tools
People who rely on assistive technology have already configured it. A screen reader user has set NVDA, JAWS, or VoiceOver to a speech rate, a verbosity level, and a set of keystrokes they may have used for years. A low-vision user has set a Windows contrast theme or browser zoom. The page's job is to cooperate with those tools, and the way a page cooperates is correct semantics in the HTML.
An overlay sometimes competes instead. Its own keyboard shortcuts can collide with screen reader commands. A toolbar's contrast mode can fight the operating system's forced colors. A "screen reader mode" that changes the page when it suspects assistive technology means those users see a different site from the one you tested. And a script that tries to detect assistive technology is processing a signal about disability, which your privacy counsel will want to hear about.
How to remove an overlay without a bad month
Removing the script is one line. Removing it well takes four steps.
- Inventory what it was "fixing." Export the vendor's list of configured fixes if it has one. Then capture what it changes on your key templates: block the overlay's domain with DevTools request blocking, run the snippet below, unblock it, run the snippet again, and diff the two outputs.
- Audit without it. The blocked version is the site some of your users already get, because overlays load late or fail. Test it with automated tools, a keyboard, and at least one screen reader, starting with checkout, login, and forms.
- Fix the source. Move each injected label into the template, alt text into the CMS field it belongs in, contrast into your design tokens, and widget behavior into the component. Rank the work by who is blocked, not by how many pages a rule fires on.
- Remove and verify. Take the script out of templates and your tag manager, delete its Content-Security-Policy entries, retest the critical journeys, and update your accessibility statement with a contact route for anyone who hits a problem.
// Paste into the DevTools console. Run once with the overlay blocked, once without, then diff.
const path = (el) => {
const parts = [];
for (; el && el !== document.body; el = el.parentElement) {
const i = [...el.parentElement.children].indexOf(el) + 1;
parts.unshift(`${el.tagName.toLowerCase()}:nth-child(${i})`);
}
return parts.join(' > ');
};
const watched = /^(aria-|role$|alt$|tabindex$|lang$)/;
const snapshot = {};
document.body.querySelectorAll('*').forEach((el) => {
const attrs = [...el.attributes].filter((a) => watched.test(a.name));
if (attrs.length) snapshot[path(el)] = Object.fromEntries(attrs.map((a) => [a.name, a.value]));
});
copy(JSON.stringify(snapshot, null, 2)); // copies the result to your clipboardThe diff is the first draft of your remediation backlog. Order matters: ship the fixes for the critical journeys, then remove the overlay. Don't wait for every last finding, though. Once the journeys work, the widget is only adding weight.
What to tell your board
Boards don't need the DOM. They need to know what changed, what it means, and what you propose. Something like this works:
Our website runs an accessibility overlay. In 2025 the FTC ordered one overlay vendor to pay $1 million and to stop claiming, without evidence, that its automated product makes websites conform to WCAG. Our overlay doesn't change our underlying code, so it doesn't change our conformance. We propose a WCAG 2.2 AA audit, fixes to checkout and account pages first, and removal of the overlay once those fixes are verified. We will report progress each quarter with evidence: retest results and monitoring data.
Leave two things out. Don't say "we're covered" about anything, before or after; legal exposure is a question for your attorney. And don't promise a finish date before the audit tells you the size of the job. The subscription you cancel is a reasonable first line in the remediation budget.
A sensible first week
Block the overlay in DevTools and try to buy something, book something, or log in using only a keyboard. Write down where you get stuck. That list, ranked by who it blocks, is where a WCAG 2.2 accessibility audit would start, and fixing it in your templates is what our source-code remediation sprints do. Either way, the goal is a site that works with the tools your users already brought.