Skip to content
wcagc
Create account
←Back to blog
overlaycode-firstremediationWCAG

How to remove an accessibility overlay and fix the code

A practical plan to remove an accessibility overlay: find every install, baseline the real code, fix it in source, and replace the toolbar honestly.

P

Pavel Charkasau

To remove an accessibility overlay safely, take the script out of every place it loads, then fix in your source code the issues it was sitting on top of. The removal itself is the easy part. An overlay never edits your HTML; it patches a copy of the page in the visitor's browser on every load, so deleting the snippet changes nothing in your real markup. What you lose is the runtime patching and the floating toolbar. The work is in the order you do things: find every install (templates, tag manager, CMS plugin, security headers), take a baseline of what your code looks like without the widget, fix the issues in your components, cover the toolbar's features with what browsers and WCAG already provide, and correct any public claim that leaned on the widget. A scan finds the machine-detectable part of the list. A person with a keyboard and a screen reader still has to check the rest.

Why remove an accessibility overlay at all?

Because the barriers are in your code, and the overlay doesn't touch your code. A <div onclick> that should be a <button> is unreachable by keyboard with or without a script on top of it. The Overlay Fact Sheet, now signed by more than 1,000 accessibility practitioners, says it plainly: "No overlay product on the market can cause a website to become fully compliant with any existing accessibility standard." The same page notes that runtime repairs can "cause unexpected page changes for assistive technology users," and that some disabled users block overlays outright.

The people overlays are sold to aren't convinced either. In WebAIM's 2021 practitioner survey, 72% of respondents with disabilities rated overlays "not at all" or "not very" effective, and 2.4% called them very effective (WebAIM).

Then there's the claim problem. In April 2025 the US Federal Trade Commission approved a final order requiring accessiBe to pay $1 million and barring it from representing that its automated products can make any website WCAG-compliant without evidence to back that up (FTC). If your footer badge or accessibility statement repeats the vendor's promise, that promise is now yours. (The wider comparison is in overlay vs code-first accessibility; this post is only about the move.)

Will removing the overlay break my site?

No. Visually, nothing in your own layout changes: the toolbar disappears and the page renders exactly as your templates produce it. That's the uncomfortable part, because it shows you what was there all along.

Two things can change, and you should expect them:

  • Patched labels go away. If the overlay injected an aria-label on an icon button or guessed alt text for images, those attributes stop appearing. The button is back to having no accessible name until you fix it in the component.
  • Visitor preferences stop applying. Anyone who set a larger font or a contrast mode in the widget loses it on your site. Their browser and operating system settings still work, and that's where those preferences belong anyway (more on this below).

How do I find every place the overlay is installed?

Overlays rarely live in just one template. Before you delete anything, make an inventory. The snippet can sit in more than one place, added by different people in different years.

  1. Check the network, not just the code. Open DevTools, go to the Network tab, reload, and filter by the vendor's name or domain. Do this on the homepage, a product page, checkout, and a logged-in page. Whatever loads there is your list of script URLs.
  2. Search your templates and repository for that domain: layout files, the footer partial, anything just before </body>.
  3. Open your tag manager. A tag added in Google Tag Manager or a similar tool won't show up in a code search. Remove the tag and publish the container.
  4. Check your CMS or store platform. On WordPress, Shopify and similar platforms the overlay is often a plugin or app. Deactivate and uninstall it there, or it'll keep injecting the script.
  5. Clean up the leftovers. Remove the vendor's domain from your Content-Security-Policy script-src (and connect-src) allowlist, and from your cookie or consent manager's vendor list.

One practical note: removing a script doesn't cancel a subscription. Check your contract's renewal date and cancel through the vendor separately.

How do I see what the overlay was hiding?

Take a baseline of your real code before you change anything, so you know the size of the job.

The cleanest way is a staging copy with the overlay removed. If you can't do that yet, Chrome DevTools can block a request domain from the Network panel (right-click the overlay's request, then "Block request domain"), which lets you look at your own pages as they'd render without the widget.

Then run an automated scan across your important templates and flows, not just the homepage. Run a free scan to get the list of machine-detectable WCAG issues, each with the element and selector a developer can find. Expect much of that list to come from a few shared components that repeat on every page, such as an unlabeled search input in the header or an icon-only cart button. Fix the component once and the issue disappears everywhere it renders.

What should we fix first?

Fix by user journey, not by issue count. A scan report sorted by volume will push you toward the issue that appears 4,000 times in the footer. A screen reader user trying to pay doesn't care about the footer.

A sequence that works:

  1. Shared components first. Header, navigation, search, buttons, form fields, modals. These repeat on every page, so each fix pays off many times.
  2. The flows that make you money or that people depend on. Sign-up, login, checkout, booking, account settings. Our guide to accessible forms covers the most common failures here.
  3. Content templates. Product pages, articles, listing pages.
  4. The long tail. Old landing pages, PDFs, marketing microsites.

Fix in the source, the way a developer would want to read it later:

<!-- Before: the overlay was guessing a name for this at runtime -->
<div class="cart-icon" onclick="openCart()"><svg>…</svg></div>

<!-- After: a real control with a real name, no script needed -->
<button type="button" class="cart-icon" aria-label="Cart, 3 items" onclick="openCart()">
  <svg aria-hidden="true" focusable="false">…</svg>
</button>

Then stop the same bug from coming back. Add an automated check to your pipeline so a pull request that reintroduces an unlabeled control fails before it ships (accessibility testing in CI shows how).

What replaces the overlay's toolbar?

Mostly, things that already exist. The toolbar's font-size and spacing buttons duplicate features that browsers and operating systems provide, and WCAG doesn't ask you to build them yourself.

  • Text size. WCAG 1.4.4 requires that text can be resized up to 200 percent without loss of content or functionality, and the W3C's Understanding document says "the scaling of content is primarily a user agent responsibility" (W3C, Understanding 1.4.4). Your job is to make sure browser zoom doesn't break your layout. Use relative units and test at 200%.
  • Text spacing. WCAG 1.4.12 lists four values a user may apply (line height 1.5 times the font size, paragraph spacing 2 times, letter spacing 0.12 times, word spacing 0.16 times). The Understanding document is explicit that it "does not dictate that authors must set all their content to the specified metrics, or provide a mechanism to do so" (W3C, Understanding 1.4.12). What matters is that your content doesn't clip or overlap when a user's own stylesheet or extension applies them.
  • Contrast. Fix the colours in your design tokens so they pass in the first place. The contrast checker gives you the ratio for any pair.

It's tempting to keep "something" in the corner. I'd resist that. People who need larger text or more spacing have already set it up in their browser, and a site that respects those settings serves them better than a second, site-specific control panel.

How do I update our accessibility statement and public claims?

Rewrite anything that relied on the widget. Search your site for the vendor's badge, "compliance" claims in the footer, and statement text along the lines of "this site uses [vendor] to meet WCAG."

Replace it with what's true: the standard you're targeting (WCAG 2.1 or 2.2 Level AA), which parts conform, which known issues remain and when you plan to fix them, and how to report a problem. Under the EAA, service providers have to make information on how their service meets the accessibility requirements available to the public (Article 13(2) and Annex V of Directive (EU) 2019/882). In the US, the ADA pillar and our post on whether the ADA requires WCAG cover where the benchmark comes from. A statement documents your efforts and known gaps. It isn't a guarantee, and it shouldn't read like one. The accessibility statement generator drafts one from your scan results, and the accessibility statement page explains what each section is for.

How much of the work can a scanner do?

Part of it, and you should plan for the rest. Deque's analysis of more than 2,000 audits found automated testing fully covered 57% of issues by volume on average (Deque); counted by how many success criteria a tool can test, the figure is closer to 30%. The W3C puts it bluntly: evaluation tools "can not determine accessibility, they can only assist in doing so" (W3C WAI).

So the scan gives you the detectable list and a way to catch regressions. Whether your alt text is accurate, whether focus order makes sense in a checkout, whether a screen reader announces an error at the right moment: those need a person. Our scanner won't judge them, and neither will any other. The WCAG checklist lists the criteria you'll check by hand.

Frequently asked questions

Is it safe to remove an accessibility overlay?

Yes. An overlay doesn't modify your source code, so removing it leaves your own markup and layout unchanged. You lose its runtime patches and toolbar, which is why you take a baseline scan and fix the underlying issues in your components.

Do I need to fix everything before removing the overlay?

No. The overlay wasn't fixing your code, so leaving it in place while you remediate doesn't protect your users. Remove it, fix shared components and key flows first, and document known issues in your accessibility statement while you work through the rest.

What should replace the overlay's font-size and contrast buttons?

Browser and operating system settings, plus a site that respects them. WCAG 1.4.4 treats text scaling as primarily a user agent responsibility, and 1.4.12 doesn't require authors to provide spacing controls (W3C). Your job is that zoom and user spacing don't break the layout.

Will a scanner tell me everything the overlay was hiding?

No. Automated testing covers roughly 30 to 57% of issues depending on how you count (Deque). It finds missing labels, alt text and contrast failures; keyboard flow, focus order and screen reader behaviour need manual testing.

Should I remove the vendor's compliance badge too?

Yes, along with any statement text that credits the overlay for conformance. The FTC barred accessiBe from claiming its automated products make sites WCAG-compliant without evidence (FTC). Replace it with an honest statement of what conforms and what doesn't yet.

See what your code looks like without the widget

Before you pull the script, find out what's underneath it. Run a free scan on your key templates and flows to get the WCAG issues in your real markup, with the element and selector for each. Fix those in source, check the rest by hand, and write down where you stand.

Written by Pavel Charkasau, founder of wcagc.com. Last updated 18 October 2026.

Sources