How to Remove accessiBe From Your Website
Decided the widget goes? Here is how to actually get it off, on every platform, and what to do about the problems it was covering.
Before you touch anything
Two minutes of preparation saves an afternoon. Check the renewal date on the subscription first: if you have already paid for a year, there is no urgency to rip the script out today, and you may prefer to leave it running while you fix what is underneath. Removal and cancellation are separate actions and neither one performs the other.
Then take a note of what the page looks like now. A screenshot of the homepage, and of one page with a form on it, is enough. If anything shifts after removal you will want to compare against something rather than rely on memory.
Step 1: find where the script was installed
The widget is a single line of JavaScript. It was added in one of five places, and it is worth identifying which before you start editing, because removing it from the wrong place leaves it loading from the right one.
Open your site in a private browsing window, press F12 to open developer tools, and choose the Network tab. Reload the page and type the vendor domain into the filter box:
- accessiBe —
acsbapp.com - UserWay —
cdn.userway.org - AudioEye —
ws.audioeye.com - EqualWeb —
equalweb.com - Recite Me —
reciteme.com
Click the request that appears and look at the Initiator column. If it was loaded by Google Tag Manager you will see gtm.js there — that tells you to go to step 2e rather than editing your theme.
Step 2: remove it
a. WordPress
Most installs use the vendor plugin. Go to Plugins, find the accessiBe or UserWay plugin, Deactivate, then Delete. Deactivating alone leaves the files on the server; deleting is the clean end state.
If there is no plugin, the script was pasted directly. Look in Appearance → Theme File Editor → header.php for the vendor domain and remove the whole <script>…</script>block. Also check any “insert headers and footers” plugin you may have, and Appearance → Widgets for a custom HTML block. Edit a child theme if you have one, or your change disappears at the next theme update.
b. Shopify
Online Store → Themes → … → Edit code, open layout/theme.liquid, search for the vendor domain and delete the script block. Then check Apps — if the widget was installed as an app, remove the app as well, because some apps re-inject the script on the next theme save.
c. Squarespace
Settings → Advanced → Code Injection, and clear the script from the Header box. Also check individual pages under Page Settings → Advanced, where a per-page copy is sometimes added and then forgotten.
d. Wix and Webflow
In Wix: Settings → Custom Code, find the entry and delete it. In Webflow: Project Settings → Custom Code, clear the Head Code field, then publish — in Webflow the change does not take effect until you publish again.
e. Google Tag Manager
This is the one people miss, because nothing in the website’s own code will look wrong. In GTM, find the Custom HTML tag containing the vendor snippet. Pause it first rather than deleting, publish the container, and confirm the widget is gone. Once you have confirmed, delete the tag and publish again. Pausing first means one click restores it if something unexpected breaks.
f. Hard-coded HTML
Search your whole codebase for the vendor domain — grep -rn "acsbapp" . will find every copy. The snippet often sits in a shared header include, so removing it in one file usually clears every page at once. Deploy as normal.
Step 3: confirm it is actually gone
Purge your CDN or caching plugin first, then open the site in a private window — your own browser will happily keep serving you a cached copy and tell you a comforting lie.
Repeat the Network-tab check from step 1. Nothing should load from the vendor domain. Check the homepage, one interior page and one page with a form, because installations are sometimes template-specific. The floating accessibility icon disappearing is a good sign, but it is not proof by itself: confirm at the network level.
Step 4: find out what was underneath
This is the part that matters, and it is the reason the removal was worth doing.
An overlay operates in the visitor’s browser, after your page has loaded. It does not edit your source, so whatever it was patching over is still exactly as it was built. Removing the widget does not create accessibility problems; it stops concealing them.
Run an automated scan on your busiest pages — your homepage, your main service or product page, your contact form and your checkout. That will find the mechanical failures: images with no text alternative, form fields with no label, insufficient colour contrast, missing page language. You can use our free scanner for this. It labels every finding as confirmed, potential, or needing a human, and it tells you plainly which parts of the guidelines it cannot check at all.
Then do the part no scanner can do. Put the mouse away and try to complete your own contact form or checkout using only Tab, Shift+Tab, Enter and the arrow keys. You will discover within a couple of minutes whether a keyboard user can buy from you. Our ten-minute keyboard check walks through it.
Fix in order of what blocks a transaction. An unlabelled checkout field costs you a customer today. A decorative image with a weak description does not.
Why people are removing them
In January 2025 the Federal Trade Commission announced that accessiBe would pay $1,000,000 to settle allegations that it had misrepresented what accessWidget could do; the final order was approved in April 2025. The complaint alleged the product did not make all customer websites WCAG-conformant despite marketing that said it would, and separately that the company had presented paid or connected articles as though they were independent reviews. accessiBe settled without admitting or denying the allegations, and the order bars it from repeating the compliance claims without evidence to support them.
The lawsuit numbers point the same way. UsableNet, which tracks these filings, counted 1,023 companies running an accessibility widget that were sued in 2024, and 1,416 in 2025 — 703 of them in the first half of the year alone. Those counts cover any accessibility widget rather than one vendor, but the direction is not the one a legal-protection product would predict.
Our full write-up on overlay widgets covers the technical reasons as well as the legal ones.
None of this is legal advice. If you are responding to a demand letter, talk to a lawyer — and do the re-test regardless, because a fixed site is the only thing that helps in either direction.
Frequently asked questions
Will removing the widget make my site less accessible?
It removes whatever automated corrections the widget was applying, so anything it genuinely was fixing goes back to how the page was built. That is the point of re-testing straight after removal: you find out what the widget was covering rather than assuming either that it was doing everything or that it was doing nothing. In most cases the underlying markup is unchanged, because an overlay works in the visitor’s browser and does not edit your source.
Do I have to cancel the subscription separately?
Yes. Deleting the script stops the widget loading, but it does not end the contract. Cancel in the vendor’s dashboard or by email, and keep the confirmation. Check the renewal date before you remove the code — if you have paid for a year you may prefer to leave it running until the term ends while you fix the real issues underneath.
Does removing an overlay increase my legal risk?
There is no evidence that having one lowers it. UsableNet, which tracks these filings, counted 1,023 companies running an accessibility widget that were sued in 2024 and 1,416 in 2025. An overlay is not a recognised legal defence, and in some complaints the widget itself has been cited as part of the barrier. What reduces risk is fixing the failures, which is what the re-test is for.
How do I know the widget is really gone?
Open the page in a private window, press F12 for developer tools, and search the Network tab for the vendor’s domain — acsbapp.com for accessiBe, cdn.userway.org for UserWay, ws.audioeye.com for AudioEye. If nothing loads from it, the widget is gone for real visitors and not just hidden from your own cached view.
Keep reading
- ADA Website Compliance, Explained Without the Legalese — There is no federal web rulebook, yet thousands of suits get filed every year. Here is what is actually being enforced, and against whom.
- WCAG 2.2 Level AA in Plain English — The spec is written for standards bodies. This is the same requirements written for whoever has to go and change the site.
- Why Accessibility Overlay Widgets Do Not Work — One line of JavaScript, compliance solved. Except the lawsuit numbers went up, and the FTC fined the biggest vendor $1M.
Nothing here is legal advice. Accessibility obligations vary by jurisdiction and by how a site is used. If you have received a demand letter, talk to a lawyer.