Do Accessibility Overlays Make You ADA Compliant? What the FTC and DOJ Actually Say

Somewhere in most public agencies there is a line item for an accessibility widget — the little icon in the corner of the site that opens a panel of contrast, font-size, and “screen reader mode” toggles. It was inexpensive, it installed in an afternoon, and somebody wrote “ADA compliance” next to it on a status report. With the ADA Title II web rule deadlines ahead, it is worth being blunt about what that line item did and did not buy.

What an overlay actually does

An overlay is third-party JavaScript. When a visitor loads your page, the script executes in their browser and attempts to patch what it finds: guessing at missing alternative text, injecting ARIA attributes, adjusting contrast, offering a font-size slider. Your source code is untouched. The next time your CMS renders that page, the same defects are still there, and the script tries again.

That architecture creates three problems that matter legally. First, the fixes are inferences — an image of a signed resolution is not meaningfully described by a machine-generated label. Second, anything the script cannot reach, it cannot patch, and that includes the document formats that make up most of a public entity’s content. Third, conformance is evaluated against your content as delivered; a runtime layer that may or may not load, and that behaves differently across browsers and assistive technologies, is not a durable answer to “does this page meet 1.1.1, 1.3.1, and 2.4.7?”

The FTC action, in plain terms

This is the part that changed the conversation. The FTC alleged that accessiBe marketed its accessWidget product as able to make any website WCAG-compliant, and that the claim was false, misleading, or unsubstantiated. The complaint also alleged the company presented third-party articles and reviews as independent opinion while failing to disclose its material connections to those reviewers. The Commission approved the final order in April 2025: $1 million, plus a prohibition on representing that its automated products make a website WCAG-compliant — or keep it that way — absent evidence.

Note what that order does not say. It does not outlaw overlays or declare the category worthless. It says the compliance claim was the problem. If you bought the product because of that claim, the federal agency responsible for policing advertising has now said on the record that the claim was not supported.

DOJ has already answered the automation question

The Department of Justice’s guidance for state and local governments taking their first steps toward the web rule addresses this head-on. It tells entities they will not be able to use automated testing tools alone, because those tools “can’t test for all aspects of accessibility,” and recommends some combination of automated and manual assessment. That is the regulator describing the method it expects. Automated scanning is a legitimate first pass — it is simply not the whole job. A widget is not even that: a scanner at least tells you what is broken.

The blind spot nobody mentions: your documents

For a school district, a county, or a state agency, the largest accessibility liability is almost never the homepage. It is the thousands of PDFs, Word files, presentations, and spreadsheets hanging off it — board packets, budgets, permit applications, enrollment forms, meeting minutes. An overlay does nothing to any of them. The script runs inside the page; the PDF opens in a separate viewer or downloads to the desktop, entirely outside its reach.

The Title II rule does carve out an exception for preexisting conventional electronic documents — PDFs and word processor, presentation, and spreadsheet files already posted before your compliance date. But that exception has a hard limit: it does not apply to documents currently used to apply for, gain access to, or participate in your services, programs, or activities. The permit application posted three years ago that residents still submit today is not covered. Neither is anything you post going forward. Scoping which of your documents fall inside that exception, and remediating the ones that do not, is real work no widget performs.

What to do instead

1. Inventory what you have. Pages, mobile apps, and — critically — the document library. You cannot scope a remediation you have not counted.
2. Sort by use, not by age. Whatever people use to obtain a service comes first. That is also the standard the document exception turns on.
3. Test the real way. Automated scan, then keyboard-only navigation, then screen-reader review of your templates and top tasks. Record what you found and when you found it.
4. Remediate at the source. Fix the CMS templates and shared components so the defect stops reappearing on every new page. Rebuild the documents with real tags, reading order, and alternative text.
5. Fix your contracts. Most agencies do not build their own portals. Put WCAG 2.1 AA conformance and an ACR obligation into vendor agreements so you are not remediating someone else’s product for free.
6. Publish an honest accessibility statement. Say what conforms, what does not yet, and how to request an accessible copy. Documented good-faith effort helps you; overclaiming does not.

If the widget genuinely helps some of your visitors, there is no reason to rip it out. Just stop counting it as compliance, and move the budget line to where the work actually is. Your Title II deadline is April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special district governments — enough time to do this properly, and not enough time to start late.