Skip to content
wcagc
←Back to blog
accessiBeFTCoverlayWCAG

The accessiBe FTC settlement, explained

The accessiBe FTC settlement, explained: what the $1M order found, what it bars, and what it means if you use an accessibility overlay.

P

Pavel Charkasau

The accessiBe FTC settlement is the US Federal Trade Commission's 2025 enforcement action against accessiBe, the company behind the accessWidget accessibility overlay. The FTC charged that accessiBe misrepresented what its automated product could do. The company told customers that one line of code made a site meet 30% of WCAG immediately, and that an AI process would handle the remaining 70% within 48 hours (FTC complaint). The FTC said that was false and unsubstantiated, and that accessiBe also dressed up paid endorsements as independent reviews. The Commission voted to accept the consent order on 3 January 2025 and approved the final order on 22 April 2025 (FTC). accessiBe agreed to pay $1 million and is now barred from claiming its automated products can make any website WCAG-compliant, or keep it compliant over time, without competent and reliable evidence. The company did not admit liability. The short version for anyone running an overlay: the regulator has put in writing that a script alone does not make your site meet the standard, and the marketing that said it did is the thing that got penalized.

What did the FTC actually find?

The FTC's complaint has two halves, and both matter.

The first is about capability. accessiBe marketed accessWidget as an AI product that could make "any website" conform to WCAG. According to the complaint, the specific pitch was that pasting one line of code made a site compliant with 30% of WCAG's requirements right away, and that an automated process finished the other 70% within 48 hours. The FTC alleged this was false: the widget left basic components like menus, headings, tables, images, and recordings inaccessible to people with disabilities (FTC complaint). The number that should stop you is the 48-hour full-conformance claim, because no automated tool reaches that. Independent testing puts automation at roughly 30 to 57% of issues by volume, and the ceiling exists because a machine cannot judge whether alt text is meaningful or whether a form's error message makes sense to a screen reader user (Deque).

The second half is about reviews. The FTC said accessiBe "deceptively formatted third-party articles and reviews to appear as if they were independent opinions by impartial authors and failed to disclose the company's material connections to the supposedly objective reviewers" (FTC). In plain terms: some of the glowing coverage was paid for, and it did not say so. Samuel Levine, then director of the FTC's Bureau of Consumer Protection, put the principle bluntly: "Overstating a product's AI or other capabilities without adequate evidence is deceptive, and the FTC will act to stop it" (FTC).

What does the accessiBe FTC settlement order bar?

The final order, approved on 22 April 2025, is the operative document. It bars accessiBe from representing that its automated products can make any website WCAG-compliant, or can keep a site compliant over time, unless the company has competent and reliable evidence to back the claim (FTC). It also stops the company from passing off endorsements as neutral: it cannot present reviews, blog posts, or articles as the independent opinions of impartial users, or present a paid endorser as an ordinary customer, without disclosing the connection.

accessiBe agreed to pay $1 million, money the FTC can use to refund businesses that bought the product (FTC). The consent order also carries the usual FTC monitoring: recordkeeping and compliance reporting so the Commission can check the promises are kept. What the order does not do is ban the accessWidget product or declare overlays illegal. It targets the claims, not the code.

Does the settlement mean overlays are illegal?

No. The FTC did not outlaw accessibility overlays, and it did not rule that installing one breaks any law. What it penalized was saying an overlay makes a site conform to WCAG when the evidence doesn't support that. You can still run accessWidget. You just can't be told it does something it doesn't.

That distinction matters because the settlement lines up with what accessibility practitioners have said for years. The Overlay Fact Sheet, now signed by more than 800 practitioners including editors of the WCAG, ARIA, and HTML specifications, states the limit directly: "No overlay product on the market can cause a website to become fully compliant with any existing accessibility standard." And in WebAIM's 2021 survey of accessibility practitioners, 67% rated overlays "not at all" or "not very" effective; among respondents who have disabilities themselves, that rose to 72% (WebAIM). The FTC didn't invent a new critique. It gave the existing one legal teeth.

What does this mean if you use accessiBe or another overlay?

Start by separating the tool from the claim. If you bought an overlay because a vendor told you it would make your site meet the ADA or the EAA, that specific promise is now the thing a US regulator has called deceptive. Removing the script is safe, by the way: an overlay never edits your real HTML, so deleting it leaves your source exactly as it was, no better and no worse.

Here is the practical sequence I'd follow. First, scan your pages against WCAG and get the actual list of issues, each mapped to the success criterion it fails, with the element and selector. Second, fix those in your source so the change survives a redeploy and every assistive technology reads it as native markup. Third, get a person with a keyboard and a screen reader to check the flows a scanner can't judge, because the WCAG checklist has criteria no machine can evaluate. Fourth, write an honest accessibility statement that documents what you tested and what you found, rather than a badge that claims a result you can't show.

My honest take, and it's why we built the product the way we did: an overlay optimizes for the vendor's dashboard, not for the disabled customer trying to finish a checkout. The FTC case is the clearest signal yet that the dashboard number was never the point. Whether you're held to the ADA, Section 508, or the EAA, the standards care about the outcome a real user gets, and an auditor can inspect your markup but not a script's runtime guesses.

Frequently asked questions

How much did accessiBe pay in the FTC settlement?

accessiBe agreed to pay $1 million. The FTC can use that money to refund businesses that bought accessWidget on the strength of the claims the Commission called deceptive (FTC). accessiBe settled without admitting liability.

What did accessiBe do wrong, according to the FTC?

The FTC alleged two things. accessiBe claimed its widget could make any website meet WCAG, including a claim that an AI process reached full conformance within 48 hours, which the FTC said was false and unsubstantiated. It also presented paid endorsements as if they were independent reviews without disclosing the connection (FTC complaint).

Does the FTC settlement ban accessibility overlays?

No. The order targets accessiBe's marketing claims, not the product. It bars the company from saying its automated tools make a site WCAG-compliant without competent, reliable evidence (FTC). Overlays remain legal to sell and to install.

Do I need to remove accessiBe from my site?

Not for legal reasons, and you can if you want to. An overlay doesn't change your source HTML, so removing the script leaves your code as it was. The more useful step is to scan your real markup, fix the issues in the source, and review the rest by hand.

Can any automated tool make my site WCAG-compliant on its own?

No, and that limit is the heart of the case. Automated testing catches roughly 30 to 57% of issues; the rest needs manual review with a keyboard and a screen reader (Deque). The W3C says the same: evaluation tools "can not determine accessibility, they can only assist in doing so" (W3C WAI).

See what your real markup reports

If you've been relying on a widget's score, look at the evidence instead. Run a free scan to get the actual list of WCAG issues on your pages, each mapped to the criterion you're held to, with the element and selector your developers need. Fix what it finds in your code, review the rest by hand, and document where you stand. That's the record that holds up when someone reads your markup, which is exactly what the accessiBe case is about.

Written by Pavel Charkasau, founder of wcagc.com. Last updated 8 August 2026.

Sources