You installed the widget because someone told you it would make the lawsuits stop. Maybe it was a sales rep. Maybe it was a blog post. Maybe it was a friend who runs a Shopify store and figured the $49/month badge was cheaper than thinking about accessibility.
And then the envelope showed up anyway.
If that hasn't happened to you yet, you're reading this because you suspect it might. You're right to be nervous. Over 1,000 websites with an overlay widget installed were named in ADA demand letters or lawsuits across 2023 and 2024, according to UsableNet's annual tracking data. That number went up, not down.
This article is about why the widget didn't help, what the demand letters actually say, and what you can do instead that has a real shot at keeping you out of trouble. It is not legal advice. If you already have a letter in hand, call an ADA defense attorney before you do anything else.
The architecture problem nobody explained to you
An overlay widget is a JavaScript file that loads after your page loads. It sits on top of your website like a coat of paint on a cracked wall. The toolbar it adds -- bigger fonts, higher contrast, a dyslexia-friendly typeface -- those are cosmetic preferences. Useful for some users, sure. But they have almost nothing to do with the things that make a website legally accessible.
WCAG 2.1 Level AA, the standard courts use as a benchmark, has dozens of success criteria. Most of them are about the structure of your HTML: whether a screen reader can tell that a button is a button, whether your form fields have labels a blind user can hear, whether someone who can't use a mouse can tab through your page in a logical order, whether your heading hierarchy actually makes sense.
That structure is baked into your source code. It's decided when the page is built, before any JavaScript runs. A script that loads afterward can try to guess at what's missing and inject attributes, but it can't turn a clickable <div> into a real <button> that responds to keyboard events correctly. It can't reorder your tab sequence without breaking something else. It can't fix a form that was never wired up with <label> elements in the first place -- not reliably, not across every browser and assistive technology combination.
Independent analyses put the share of WCAG 2.1 AA criteria that an overlay can meaningfully address at roughly 10 to 16 percent. The other 84 to 90 percent requires changes to the actual source code.
That's not a knock on any one product. It is a constraint of the architecture. Every overlay in the category ships the same kind of JavaScript, and every one hits the same ceiling.
What demand letters actually cite
Here's the part that matters if you're trying to understand your risk. ADA demand letters don't say "you failed to install an overlay widget." They cite specific failures against specific WCAG success criteria. The most common ones we see referenced:
Missing form labels. A screen reader user lands on your contact form and hears "edit text, edit text, edit text" instead of "name, email, message." That is a 1.3.1 (Info and Relationships) and 3.3.2 (Labels or Instructions) violation. It happens because the HTML has <input> elements with no associated <label>.
No keyboard access. A user who navigates with a keyboard can't open your dropdown menu, can't close your modal, can't complete checkout. That's 2.1.1 (Keyboard). Usually caused by custom JavaScript widgets built with <div> and <span> instead of native interactive elements.
Missing alt text or decorative images not hidden. Screen readers announce every image. If you have 40 product photos with no alt text, that's 40 instances of "image, image, image." Criterion 1.1.1 (Non-text Content).
Broken focus order. The user tabs through the page and the focus jumps from the header to the footer, skipping the main content. Criterion 2.4.3 (Focus Order). This is a DOM structure issue.
Low color contrast. Text that doesn't meet a 4.5:1 contrast ratio against its background. Criterion 1.4.3. This one an overlay could theoretically fix with a high-contrast toggle, but the user has to find and activate the toggle first, and WCAG requires the default state to be accessible.
Notice what all of these have in common: they're about what your website is, not what's bolted on top of it. The demand letter plaintiff doesn't care whether you have a toolbar. They care whether their screen reader could use your checkout.
The FTC already weighed in
In early 2025, the Federal Trade Commission settled with an overlay vendor over deceptive marketing claims. The FTC's position, in the consent order, was that the vendor's promises about achieving full WCAG compliance were not substantiated. That's a public record. We're not characterizing it beyond what the consent order says.
What it means for you: even the federal agency responsible for truth-in-advertising found that the compliance claims were overstated. If the marketing promise was the reason you bought the widget, the premise you relied on has been officially questioned.
700+ professionals said the same thing
The Overlay Fact Sheet at overlayfactsheet.com has been signed by over 700 accessibility professionals, researchers, developers, and disabled technologists. Their position is straightforward: overlay widgets do not provide meaningful accessibility, they often make the experience worse for disabled users, and they should not be marketed as a compliance solution.
You can read their reasoning on the site. We don't need to editorialize it -- the signatory list speaks for itself.
What actually reduces your lawsuit risk
There's no product you can buy that eliminates the risk entirely. Anyone who tells you otherwise is selling something. But there are concrete things that demonstrably lower your exposure, and they all share one trait: they fix the source code.
Run a real scan of your site. Use a free tool like axe DevTools, WAVE, or Lighthouse. These catch maybe 30 to 50 percent of issues automatically, but that 30 to 50 percent includes the most common violations cited in demand letters: missing alt text, missing form labels, low contrast, missing document language. Ten minutes gets you a list.
Fix the top five violations first. You don't need to fix everything at once. The data from WebAIM's Million analysis shows the same handful of issues appear on the vast majority of sites. Missing alt text. Low contrast. Missing form labels. Empty links. Missing document language. Fix those five categories and you've addressed the issues that appear in most demand letters.
Test with a keyboard. Unplug your mouse and tab through your whole site. Can you reach every interactive element? Can you tell where the focus is? Can you open and close modals, dropdowns, menus? If you get stuck anywhere, that's a violation. This takes 15 minutes and catches things no automated scanner will find.
Add an accessibility statement. A page on your site that says what standard you're working toward (WCAG 2.1 AA), what you know still needs work, and how users can contact you if they hit a barrier. This doesn't prevent a lawsuit, but it demonstrates good faith -- and some courts have considered it as a factor. We have a full guide to writing one.
Set up a recurring check. Accessibility isn't a one-time project. Every new page, every new feature, every CMS update can introduce new violations. A CI scanner that runs on every deploy (even just axe-core in a GitHub Action) catches regressions before they go live. We wrote a step-by-step guide for that.
The five things to do this week
If you're reading this because you're worried -- or because the letter already arrived -- here's a triage list. Not aspirational. Practical.
Run axe DevTools or WAVE on your homepage, your checkout page, and your contact form. Export the results. You now have a baseline.
Fix every missing
altattribute and every missing form<label>. These are usually the easiest fixes and the most commonly cited violations. If you use WordPress, Shopify, or Squarespace, your theme settings or a plugin can handle most of this without touching code.Check your color contrast. Use WebAIM's contrast checker. Anything below 4.5:1 for body text needs to change. This is a CSS fix.
Tab through your site with your keyboard. Note everywhere you get stuck. Those are your priority fixes after the quick wins above.
Publish an accessibility statement. Even a short one. State your commitment, acknowledge known issues, provide a contact method. Here's our guide if you want a template.
None of this requires a $49/month subscription. None of it requires a JavaScript snippet. All of it addresses the things demand letters actually cite.
The real question
If you already have an overlay installed, we're not telling you to rip it out tomorrow. The contrast toggle and font controls may be genuinely useful to some of your visitors. But you should know that it is not doing what you were told it would do, and it is not protecting you from the thing you were told it would protect you from.
The protection comes from fixing the source. It always has.
If you've received a demand letter and want to understand what a real remediation plan looks like, we built a demand letter response walkthrough that breaks down the typical timeline and what to prioritize first. And if you want to understand the full cost picture, our breakdown of what ADA lawsuits actually cost has the 2024-2025 numbers.
This article is for informational purposes only and does not constitute legal advice. Consult an attorney licensed in your jurisdiction for guidance specific to your situation.
Top comments (0)