What Happened: The FTC vs accessiBe Case
In January 2025, the Federal Trade Commission filed a formal complaint against accessiBe, Ltd., the company behind the widely marketed "accessWidget" AI overlay product. The complaint alleged that accessiBe had engaged in deceptive marketing practices by making claims its product could not substantiate: specifically, that the widget could make any website compliant with the Web Content Accessibility Guidelines (WCAG) and the Americans with Disabilities Act.
The FTC's complaint stated that accessiBe "represented, directly or indirectly, expressly or by implication, that accessWidget makes websites fully compliant with the Americans with Disabilities Act and the Web Content Accessibility Guidelines." The agency found these representations to be false and misleading.
In April 2025, accessiBe settled the complaint. The terms included a $1 million civil penalty and a consent order permanently prohibiting the company from making unsubstantiated compliance claims. Under the consent order, accessiBe is required to have competent and reliable scientific evidence to support any future claims about the effectiveness of its products — a standard it had not met for years of marketing.
The significance of this action extends well beyond one company. The FTC's enforcement sends a clear regulatory signal: claiming that an automated tool can make a website accessible is not just technically incorrect, it is legally actionable deception. Any business that adopted accessiBe or a similar overlay product based on compliance representations made during this period was misled.
The case also drew direct attention to the business customers. While the FTC action targeted accessiBe, courts evaluating ADA lawsuits against websites using overlay products have consistently found that the overlay's presence is not a defense. Businesses that paid for accessiBe and believed they were covered faced — and continue to face — ADA litigation regardless.
What accessiBe Actually Claimed
The specific claims at the center of the FTC complaint were remarkable in their precision and confidence. accessiBe's marketing materials stated that accessWidget "makes a website compliant with 30% of WCAG requirements immediately and the remaining 70% within 48 hours." The clear implication was full WCAG compliance within two days of installing a JavaScript snippet.
This claim was not a vague aspiration. It was quantified marketing copy, repeated across landing pages, sales materials, and third-party affiliate content. The FTC found the claim to be false on its face: no automated client-side JavaScript overlay can achieve full WCAG compliance, because compliance requires structural changes to the underlying HTML, content, and application logic that a client-side injection cannot make.
Beyond the core compliance claims, the FTC's complaint also addressed related deceptive practices. These included the use of fake or misleading third-party reviews designed to appear as independent validation of the product's effectiveness. The complaint also found that accessiBe had undisclosed affiliate relationships with publishers who promoted the product as an impartial recommendation while receiving compensation — a violation of FTC disclosure requirements.
Taken together, the picture the FTC painted was of a company that built its business on claims it knew or should have known were false, amplified by a marketing network with undisclosed financial interests in pushing those claims. For the thousands of small businesses that purchased accessWidget in good faith, this was a significant breach of trust.
Why Overlay Widgets Cannot Make Websites Compliant
The FTC enforcement action confirmed a conclusion that accessibility professionals and disability advocacy organizations had reached years earlier: overlay widgets are technically incapable of delivering WCAG compliance. Understanding why requires understanding what accessibility actually means at the code level.
Client-side overlays cannot fix server-rendered issues. An overlay is JavaScript that runs in the user's browser after the page has already loaded. It can modify what is displayed, but it cannot change the actual HTML document that search engines index, that assistive technologies parse, or that gets served to users who have JavaScript disabled or who use browser extensions that block third-party scripts. The underlying inaccessible code remains exactly as it was.
AI-generated alt text is frequently wrong or inadequate. accessiBe's marketing prominently featured its AI's ability to automatically generate image descriptions. In practice, automated alt text generation produces descriptions that are often generic, inaccurate, or misleading. WCAG 1.1.1 requires that alt text convey the purpose and information content of an image in context. An AI that labels a chart image as "a graph" or an employee photo as "a person" fails this criterion. Screen reader users report encountering these generated descriptions and finding them more confusing than no description at all.
Heading hierarchy cannot be restructured from the outside. Proper document structure — a logical heading outline from H1 through H6 — is fundamental to screen reader navigation. Users of NVDA, JAWS, and VoiceOver navigate by heading to understand document structure and jump to relevant sections. An overlay cannot reorganize a page's heading structure without rebuilding it from scratch. Adding an ARIA attribute over a broken heading hierarchy does not fix the underlying semantic failure.
Keyboard navigation logic in custom components requires code changes. Interactive widgets like custom dropdowns, date pickers, modal dialogs, and carousels require specific keyboard interaction patterns defined in the ARIA Authoring Practices Guide. These patterns — arrow key navigation within a combobox, Escape to close a modal, Tab to move between toolbar items — must be implemented in the application's JavaScript. An overlay running on top of a non-keyboard-accessible widget cannot inject the correct keyboard event handlers into that widget's existing code.
PDFs, videos, and third-party embeds are outside the overlay's reach entirely. WCAG requires that PDF documents be properly tagged with reading order, heading structure, and alt text for images. It requires that videos have accurate captions and audio descriptions. It requires that third-party embedded content (maps, forms, widgets, payment processors) meet the same standards as first-party content. An overlay has no access to any of these. The PDF is a separate file. The video is on a third-party server. The embedded content runs in its own iframe with its own security context.
The 30-40% ceiling on automated tools. Research consistently finds that automated accessibility testing tools — including the most sophisticated ones — identify approximately 30 to 40 percent of WCAG violations. The remaining 60 to 70 percent require human judgment: understanding the purpose of an element in context, evaluating whether a description is meaningful, testing actual keyboard interaction flows, or assessing whether visual presentation conveys hierarchy. An overlay that claims to fix violations using automation is, at best, addressing the minority of issues that automation can identify, and doing so imperfectly.
Screen reader users report that overlays make sites harder to use. This is not a theoretical concern. The National Federation of the Blind and individual screen reader users have published accounts of overlay products actively interfering with assistive technology. When an overlay attempts to modify ARIA attributes, rewrite DOM structure, or inject its own keyboard handling, it conflicts with the user's actual assistive technology configuration. The overlay assumes it knows better than the user's own tools — and it is wrong.
The Overlay Trap: More Lawsuits, Not Fewer
The marketing premise behind overlay products was that paying a few hundred dollars per year would eliminate ADA litigation risk. The data shows the opposite is true.
Plaintiffs' attorneys have learned to identify overlay products through their distinctive script tags and interface elements. Far from deterring lawsuits, the presence of an overlay can signal to experienced plaintiffs' firms that the website owner is aware of accessibility issues — aware enough to purchase a remediation product — but chose a solution that does not work. This signals awareness without remediation, which in legal terms can support a finding of knowing non-compliance.
California courts, which handle a significant share of ADA website litigation, have specifically addressed the overlay defense. In multiple cases, courts have rejected arguments that an overlay widget constituted meaningful remediation. Judges have noted that the relevant question is not whether the defendant purchased an accessibility product, but whether the website is actually accessible to users with disabilities. An overlay that fails to make the site accessible does not satisfy this standard regardless of the product's cost or the vendor's marketing claims.
Serial plaintiffs — individuals who file dozens or hundreds of ADA website claims per year — have documented targeting patterns that include sites using overlay products. The reasoning is straightforward: if a site uses an overlay and the overlay does not fix the underlying issues (which it cannot), the site still has the same violations it had before the overlay was installed. The overlay provides documentation that the owner was aware of accessibility obligations, which can strengthen rather than weaken a plaintiff's case.
What Courts Actually Accept as Compliance
If overlay widgets do not constitute meaningful remediation, what does? The pattern across court decisions, consent decrees, and DOJ settlement agreements points to several consistent requirements.
Manual audit and remediation by qualified professionals. Courts and enforcement agencies consistently look for evidence that a qualified accessibility professional evaluated the site against WCAG criteria and that identified violations were fixed in the underlying code. The key phrase is "in the underlying code" — the fix must be in the HTML, CSS, and JavaScript, not in a client-side layer on top of it.
Automated scanning as ongoing monitoring, not as the solution. Automated scanning tools, including AdaScanPro, play an important role in accessibility compliance — but as a continuous monitoring mechanism that catches regressions and new violations, not as a one-time solution. Courts look favorably on evidence of ongoing monitoring because it demonstrates a systematic commitment to maintaining accessibility, not a checkbox mentality.
VPAT documentation. A Voluntary Product Accessibility Template is a structured disclosure of how a product or website meets each WCAG criterion. VPATs are required in federal and many state procurement processes. In litigation, a well-documented VPAT demonstrates that the organization has evaluated its accessibility status against specific criteria and has a roadmap for addressing gaps. It does not guarantee immunity, but it demonstrates good faith engagement with the standard.
Published accessibility statement with a feedback mechanism. WCAG 2.2 itself includes a conformance claim structure, and the DOJ's guidance and settlement agreements consistently require a published accessibility statement on the website that identifies the standard being targeted, the date of last evaluation, any known limitations, and a contact mechanism for users to report barriers. This statement is not a legal shield, but its absence is noted negatively by courts.
Ongoing monitoring and re-scanning. Website content changes. Code is deployed. Third-party tools are updated. A compliance posture established at one point in time will degrade without continuous monitoring. Courts look for evidence of ongoing attention to accessibility, not a single audit followed by nothing.
The Real Cost Comparison
The economic argument for overlay products has always been their low apparent cost: a few hundred dollars per year versus thousands of dollars for a real audit. The FTC case and the litigation data reveal the actual cost picture.
| Approach | Annual Cost | Legal Protection | Actual Effectiveness |
|---|---|---|---|
| Overlay widget (e.g., accessiBe) | ~$500/year | None — FTC confirmed claims are false; courts reject as defense | 30–40% of issues at best, introduces new barriers for screen reader users |
| One-time automated scan only | $49–$99 one-time | Partial — identifies violations but provides no evidence of remediation | Identifies all major machine-detectable issues; 60–70% still require manual review |
| Full manual audit + remediation | $5,000–$30,000 | Strong — demonstrates qualified professional review and code-level fixes | Comprehensive when done by a qualified auditor |
| AdaScanPro continuous monitoring | $97–$197/month | Strong — combines automated scanning, ongoing monitoring, compliance certificate, and remediation guidance | Continuous coverage; catches regressions; provides documented compliance trail |
The comparison that matters is not overlay versus audit. It is the cost of any proactive approach versus the cost of a single ADA lawsuit settlement, which averages $25,000 to $50,000 before attorney's fees. A single settlement costs more than three to five years of comprehensive monitoring. Two settlements — which are common for businesses targeted by serial plaintiffs who return when violations recur — exceed a decade of professional compliance management.
The overlay product's low sticker price is a false economy when it provides no legal protection and may actively increase litigation risk by signaling awareness without remediation.
How to Actually Protect Your Business
The accessiBe FTC settlement closes the chapter on a period when businesses could claim good faith reliance on an overlay product's compliance representations. Those representations have been formally found to be false. Any business currently using an overlay product should treat it as what it is: a visual interface modification with no legal standing as an accessibility solution.
The path forward is straightforward, if not instantaneous.
Start by knowing where you actually stand. Run an automated scan to identify the machine-detectable violations on your site. This gives you an honest baseline and a prioritized list of issues to address. The violations found by a scan — missing alt text, color contrast failures, form label errors, keyboard navigation barriers — are the same violations that appear in ADA demand letters and complaints. Knowing them before a plaintiff does puts you in a different legal position.
Fix the issues in the code. For most websites, the high-priority violations identified in an automated scan can be addressed by a developer in hours to days, not weeks. Missing alt text, form labels, language attributes, and skip navigation links are mechanical fixes. Color contrast issues require design attention but are predictable and bounded.
Implement ongoing monitoring. Accessibility is a continuous practice, not a one-time project. New content introduces new violations. Code deployments introduce regressions. Third-party tools change. Monthly scanning catches these issues before they accumulate into the kind of violation count that attracts litigation.
Document your compliance efforts. Publish an accessibility statement. Maintain records of scans, remediation actions, and monitoring activity. In the event of a demand letter or lawsuit, this documentation demonstrates good faith engagement — the standard that courts weigh alongside technical compliance status.
Do not rely on a JavaScript band-aid. The FTC has confirmed what accessibility professionals have said for years: no client-side injection script can make a website compliant. The solution to an inaccessible website is an accessible website.
Scan your website free to see exactly where you stand — and start fixing the actual issues, not covering them up.
Tags
Share this article