Skip to content
wcagc
←Back to blog
accessiBeoverlayalternativesWCAG

accessiBe alternatives that fix code, not overlay it

accessiBe is an overlay, not a code fix. Here are the code-first accessiBe alternatives, what to look for, and why the FTC fined it $1M.

P

Pavel Charkasau

If you are looking for accessiBe alternatives, the choice that matters isn't which vendor's widget to swap in. It's whether you keep using an overlay at all. accessiBe's accessWidget is an overlay: one line of JavaScript that runs in the visitor's browser and tries to patch accessibility at runtime. A code-first alternative does the opposite. It scans your pages, reports the specific issues against WCAG, and leaves the fix in your source code, where it stays fixed. That distinction is not marketing. In April 2025 the US Federal Trade Commission approved a final order requiring accessiBe to pay $1 million and barring it from claiming its automated product can make a website WCAG-compliant without evidence (FTC). So the useful question is not "which overlay is better", but "what does a tool that fixes code instead of hiding it look like". This guide answers that: what accessiBe actually is, what a real alternative should do, how the two compare, and how to move off a widget without breaking your site.

What is accessiBe, and why look for an alternative?

accessiBe sells accessWidget, an accessibility overlay. You paste a script tag into your site and it loads a toolbar plus a set of automated adjustments that run in the browser: it tries to add labels, fix some contrast, and let users toggle font size or spacing. The promise is that one line of code handles compliance for you.

The FTC looked at that promise and found it false. In its January 2025 complaint, the Commission said accessiBe claimed accessWidget "makes a website compliant with 30% of WCAG's requirements immediately" and then uses AI to reach "full compliance with the remaining 70%... within 48 hours" (FTC). The agency called those representations false, misleading, or unsubstantiated, and the final order in April 2025 made the $1 million payment and the advertising ban stick.

The deeper reason to look elsewhere is technical, and it applies to every overlay, not just this one. Accessibility barriers live in your HTML, your ARIA, and your component code. A <div onclick> that should be a <button> is invisible to a keyboard whether or not a widget is loaded on top of it. The Overlay Fact Sheet, signed by more than 800 accessibility practitioners including people who write the WCAG, ARIA, and HTML specs, puts it directly: "No overlay product on the market can cause a website to become fully compliant with any existing accessibility standard." A script painted over the page after it loads cannot rewrite the page's real structure.

What should an accessiBe alternative actually do?

Judge the alternative by what it reports and what it refuses to promise. A code-first scanner does four things a widget does not.

  • It reports issues instead of patching them at runtime. You get a list mapped to WCAG success criteria: this image has no alt text, this control has no accessible name, this input has no label, with the element and the selector. Your developers fix it in the source. The fix is permanent and every assistive technology sees it, not just the ones the overlay's JavaScript happened to intercept.
  • It is honest about coverage. Automated testing catches part of the picture, not all of it. Deque's study of more than 2,000 audits put automation near 57% of issues by volume, while the older benchmark based on how many success criteria a tool can even evaluate sits closer to 30% (Deque). The W3C says the same in plainer words: evaluation tools "can not determine accessibility, they can only assist in doing so" (W3C WAI). An honest tool tells you the rest needs a human with a keyboard and a screen reader. A widget that claims to finish the job by itself is repeating the mistake the FTC just fined.
  • It maps findings to the law you are actually held to. In the EU that is EN 301 549, which incorporates WCAG 2.1 Level AA for the web and gives the EAA its presumption of conformity. In the US it is WCAG 2.1 AA under the ADA and Section 508. A scan that ties each finding to a clause is worth more than a green badge.
  • It helps with the paperwork. Under the EAA you have to publish an accessibility statement that documents your real level of conformance, known gaps, and a contact for feedback. A scanner that turns actual results into an honest draft does something no overlay can, because the overlay's whole pitch is that there are no gaps to document.

Here is the one opinion I will state plainly, as the person whose name is on this post: overlays don't fix code, they hide it from the scanner. We built the opposite on purpose. If a tool's main feature is a toolbar your visitors see, it is solving the wrong problem.

accessiBe vs a code-first alternative: how do they compare?

The two approaches differ at almost every step. This is the comparison that matters more than one widget versus another.

accessiBe (overlay)Code-first scanner
Where it actsIn the visitor's browser, at runtimeOn your source code, before you ship
What you getA toolbar and automated adjustmentsA report of issues with selectors and WCAG clauses
Who fixes the issueThe script tries to, on the flyYour team, in the code
Does the fix persistOnly while the script runsYes, it is in your HTML
Honest about the 30–57% gapClaimed full compliance (FTC disagreed)States it and points you to manual review
Supports an accessibility statementImplies none is neededTurns findings into a documented draft

Notice what the right-hand column does not include: a widget, a badge, or a claim that installation equals conformance. That absence is the point. If you want the full feature-by-feature breakdown, we keep a running accessiBe alternative comparison and a wider alternatives hub that holds the same line for other overlays.

Does switching from accessiBe reduce legal risk?

Fixing the barrier in your code addresses the thing a complaint is actually about; an overlay leaves the barrier in place. That is the honest version of the answer, and it is worth stating carefully because the opposite has been oversold.

Overlays did not deflect lawsuits. In UsableNet's tracking, roughly a quarter of 2024 US digital accessibility lawsuits, more than 1,000 cases, were filed against sites that already had an accessibility widget installed (Accessibility.Works, on UsableNet data). In many complaints the widget itself was named as a barrier. So the presence of a widget offered no protection, and sometimes made the site a target.

No tool removes legal exposure, and any alternative that says it does is making the exact claim that cost accessiBe $1 million. What real fixes do is remove the cause: a labelled form and a keyboard-reachable checkout are not just safer, they let disabled customers finish buying from you. That is the reason the requirement exists.

How do I move off accessiBe without breaking my site?

Removing the script is safe, because the overlay was never load-bearing for your real markup. Work in this order.

  1. Scan first, while the widget is still installed. Run a free scan to get a baseline list of the machine-detectable issues on your key pages. This tells you what the overlay was papering over.
  2. Remove the overlay script. Delete the accessWidget snippet from your templates. Your underlying HTML does not change, so nothing visible breaks; the toolbar just disappears.
  3. Fix the reported issues in source. Work through the scan report: real <button> elements, <label> on inputs, alt text that describes the image, contrast that passes. Re-scan after each release. Use the WCAG checklist for the criteria a scan can't judge.
  4. Do the manual pass. Tab through every flow with the keyboard. Run a screen reader across login, onboarding, and checkout. This is the 40-plus percent a scanner won't catch, and it is where most real barriers hide.
  5. Document it. Turn your results into an accessibility statement that records what conforms, what doesn't yet, and how to report a problem. Honest documentation is what the EAA asks for, and it beats a badge that claims there is nothing to report.

Frequently asked questions

What is the best accessiBe alternative?

The best alternative to accessiBe is a code-first scanner rather than a different overlay. A scanner reports the specific WCAG issues on your pages so your team fixes them in the source, instead of a widget that patches the page at runtime and claims compliance on its own. Any overlay carries the same structural problem the FTC flagged with accessiBe.

Is accessiBe WCAG compliant?

No automated overlay makes a site WCAG-compliant by itself, and the FTC ordered accessiBe to stop claiming otherwise. In its April 2025 final order the FTC required a $1 million payment and barred accessiBe from representing that its product can make any website WCAG-compliant without evidence (FTC).

Can I just replace accessiBe with UserWay or EqualWeb?

Swapping one overlay for another keeps the same limitation. UserWay and EqualWeb are also overlays, and the Overlay Fact Sheet's finding covers the category, not one vendor. The change worth making is from a runtime widget to fixing the code the widget was hiding.

Will removing accessiBe break my website?

No. The overlay runs on top of your existing HTML and does not alter your source, so removing the script only removes the toolbar. Your pages render exactly as they did, minus a layer that wasn't fixing the underlying code anyway.

Does a scanner make my site EAA compliant on its own?

No. A scanner measures your site against WCAG 2.1 AA, which is the web bar EN 301 549 sets and the EAA relies on (EUR-Lex, Directive (EU) 2019/882). Full conformance also needs manual testing and a published accessibility statement. The scan finds the machine-detectable issues and supports the documentation; it does not replace the human review.

See where your site actually stands

If you are weighing accessiBe alternatives, start with the evidence. Run a free scan to get the real list of WCAG issues on your pages, mapped to the criteria you're held to, with no toolbar and no compliance badge. Fix what it finds in your code, review the rest by hand, and document where you stand. That is the honest route, and it is the one that holds up.

Written by Pavel Charkasau, founder of wcagc.com. Last updated 19 July 2026.

Sources