You Can't Buy ADA Compliance With a Widget. The FTC Just Put a Price on Proving It.
For years, an entire category of software sold businesses a simple, seductive promise: paste one line of JavaScript into your website, and you are ADA compliant. No redesign, no developer time, no audit. Just a small accessibility icon in the corner of the page and, supposedly, protection from lawsuits.
The US Federal Trade Commission put a price on that promise. It ordered accessiBe, one of the largest sellers of these "accessibility overlay" widgets, to pay $1 million over allegations that it misrepresented what its automated tool could do - specifically, the claim that it could make any website fully compliant with the Web Content Accessibility Guidelines and the Americans with Disabilities Act. It could not.
If your accessibility strategy is a widget in the corner of your site, this is the moment to understand why that is not a strategy at all.
What an overlay actually does - and does not do
An accessibility overlay is a script that loads on top of your existing website. It typically adds a toolbar where a visitor can change font size, adjust contrast, or trigger a screen-reader mode. Marketed well, it looks like a complete accessibility solution. In practice, it is a layer of paint over the structure underneath.
Here is what an overlay does not do:
It does not add the alternative text a screen reader needs to describe your images. If the alt text is missing in your markup, it is still missing.
It does not make a mouse-only menu operable by keyboard. Someone using a switch device or a screen reader is still locked out.
It does not fix form fields that have no accessible label, so a screen-reader user still cannot tell what to type where.
It does not repair low color contrast, heading structure, or focus order in the underlying page.
The accessibility barriers that get sites sued live in the HTML. An overlay sits above the HTML. It cannot reach the thing that is actually broken.
Why the lawsuits kept coming
The clearest evidence that overlays do not deliver compliance is that the lawsuits never stopped. ADA website accessibility cases have continued to climb, rising sharply year over year, and plaintiffs' firms now specifically point to the presence of an overlay widget as a signal worth investigating - not as a defense. In some cases the overlay itself interferes with the assistive technology a user already has installed, creating new problems on top of the old ones.
Disability advocates and screen-reader users have said this for years. A widget that claims to fix accessibility automatically does not match the lived experience of the people it is supposed to help. The FTC's action simply made the legal consequence of the marketing explicit: telling customers a tool guarantees compliance, when it does not, is a problem in its own right.
The pattern underneath: buying a claim instead of testing reality
The overlay story is a specific example of the most common mistake in compliance generally. Companies buy a tool that tells them they are compliant, instead of testing whether they actually are. A badge, a certificate, a widget, a policy document - each one feels like protection, and none of them describes what the live site does when a real person uses it.
Accessibility is not a claim you can install. It is a property of the actual page: whether a screen reader can announce your content, whether every control works from a keyboard, whether text is readable, whether a form can be completed without sight. Those are testable facts, and they have nothing to do with whether a toolbar is present.
What real accessibility testing looks like
To know whether a website is accessible, you have to examine the site itself, the way a person using assistive technology - or a plaintiff's expert preparing a case - would. That means checking, on the rendered page:
Whether images carry meaningful alternative text (WCAG 2.1 Success Criterion 1.1.1), the single most-cited issue in ADA website suits.
Whether every interactive element is reachable and operable by keyboard alone (SC 2.1.1).
Whether form fields have programmatically associated labels (SC 1.3.1 and 4.1.2).
Whether text meets the minimum contrast ratio (SC 1.4.3).
Whether a skip-navigation link lets assistive-tech users bypass repeated content (SC 2.4.1).
None of these can be answered by looking at a widget. All of them can be answered by looking at the page.
How Complyy tests it
Complyy checks accessibility the way it is actually experienced. We load your live site and inspect the rendered markup for the WCAG failures that drive ADA lawsuits - missing alt text, keyboard traps, unlabeled forms, insufficient contrast, missing skip links - and we report each one with the specific element and the evidence behind it.
We also explicitly flag accessibility overlay widgets when we find them, and we say plainly what their presence means: an overlay is an on-page toolbar, not a remediation of the underlying markup. Its presence does not establish WCAG or ADA compliance, and the site is still assessed on its actual, native accessibility. In other words, we grade the page, not the badge.
Every finding comes with a timestamped, verifiable record of what we observed, so you can see exactly where your site fails, fix the real markup, and confirm the fix - rather than trusting a claim that a regulator has now shown was worth a million-dollar penalty to make.
The badge is not a defense
The lesson of the accessiBe order is not that automated accessibility tooling is worthless. It is that a tool which tells you that you are compliant is not the same as a site that is. If your ADA solution is a widget in the corner, you do not have a solution. You have a sticker on a page that a screen-reader user still cannot use, and a court will look straight through it.
Accessibility, like every other kind of compliance, is a fact about your live website. The only way to know it is to test the website. Everything else is decoration.