Do accessibility overlays meet ADA Title II? What the FTC's accessiBe order tells local governments

No. An accessibility overlay doesn't make a local government website conform to WCAG 2.1 AA, the standard in the ADA Title II rule. In 2025 the Federal Trade Commission finalized an order requiring accessiBe, an overlay vendor, to pay $1 million over claims that its AI tool could make any website WCAG compliant. Meeting the rule still means fixing the site's code, content and documents.

Below: what the FTC's documents say, what the Department of Justice has said about overlays, and what works instead. To see what fixing your own site at the source looks like, read the accessibility page.

What is an accessibility overlay?

An accessibility overlay is a third-party script, often added with a single line of code, that sits on top of a website and changes the page in the visitor's browser without changing the site's own code. The FTC's complaint says overlays are "not intended to permanently alter web code or design" (FTC complaint, para. 4 (opens in a new tab)).

Most overlays have two parts:

• A toolbar or widget: a button that opens controls for text size, contrast, spacing, cursors and animation.
• Automated repairs: a script that scans the page as it loads and tries to patch problems such as missing image descriptions, unlabeled form fields or menus that don't work from a keyboard.

Both parts run after the page reaches the visitor. The template, the PDFs and the videos on the server stay as they were.

What did the FTC's accessiBe order say?

The FTC alleged that accessiBe's claims that its accessWidget product could make any website WCAG compliant were false, misleading or unsubstantiated, and that the company paid for reviews formatted to look like independent articles. accessiBe agreed to pay $1 million and to stop making those claims without solid evidence. It neither admitted nor denied the allegations (decision and order (opens in a new tab)).

The FTC announced the proposed order on January 3, 2025 (opens in a new tab). The final order was issued April 21 and announced April 22, 2025 (opens in a new tab). According to the complaint, accessiBe said its "one line of code" made a site meet 30% of WCAG right away and the remaining 70% within 48 hours. Manual testing of sites running the widget found missing or wrong alt text, keyboard traps, missing focus indicators, incorrect headings, and broken menus, buttons and tables.

The order runs 20 years. Its main terms:

1. No claims that its automated products can make any site WCAG compliant, or keep it compliant as content changes, without competent and reliable evidence.
2. No passing off paid reviews or endorsers as independent.
3. Clear disclosure of any unexpected material connection with an endorser.
4. A clear warning, before purchase, that the product won't fix barriers on third-party domains unless those domains also use it.
5. A $1,000,000 payment to the Commission.

The order binds one company, but it gives staff a fair question for any vendor. If a product promises to make a site compliant, ask what testing backs that up, who did it, and what the product leaves out, such as PDFs, video and pages hosted elsewhere.

Does an accessibility overlay meet ADA Title II?

Not on its own. The ADA Title II rule judges results, not products: a local government website, its documents and its mobile apps must conform to WCAG 2.1 AA, whatever tools are used to get there. DOJ didn't approve or ban any product.

When commenters raised concerns about overlays and automated checkers, the Department replied that the rule sets a technical standard and doesn't address the internal policies an entity uses to meet it (89 FR 31396 (opens in a new tab)).

DOJ's 2022 web guidance takes a middle line. It says automated checkers and overlays "can be helpful tools" but "need to be used carefully," and that a clean report "does not necessarily mean everything is accessible" (ADA.gov (opens in a new tab)).

The FTC complaint also lists what the widget didn't reach, and the list covers much of a public site. PDFs, audio and video, and pages on other domains were outside it unless extra services were bought (paras. 83 to 86 (opens in a new tab)). On a government site, those are agenda packets, recorded board meetings and payment portals.

The dates: after an April 2026 interim final rule (opens in a new tab), governments serving 50,000 people or more have until April 26, 2027, and smaller governments and special districts have until April 26, 2028. The rule may still change. The National Federation of the Blind sued in May 2026 (opens in a new tab) to undo the extension.

How much can automated tools find?

A single tool finds somewhere between a sixth and a bit over half of known problems, depending on the tool and how you count. No study shows a scanner finding everything. W3C, which publishes WCAG, says "no tool alone can determine if a site meets accessibility standards" and that knowledgeable human evaluation is required (W3C WAI (opens in a new tab)).

Two studies give the range:

• In a 2017 test by the UK Government Digital Service, a page held 143 planted barriers. The best single tool found 41%, and the weakest found 17%. All 10 tools together found 71%, and 29% were missed by every tool (GDS (opens in a new tab)).
• In a 2021 study by Deque, covering about 13,000 audited pages, its automated axe tests covered 57% of issues by volume (Deque (opens in a new tab)). Deque sells those tools, and counting by volume gives a higher figure than counting by WCAG criteria.

An overlay's automated repair is limited by what software can detect and judge. A script can spot that an image has no alt text. It can't know whether a photo shows the new fire station or last year's fire station.

Do overlays help or hurt people with disabilities?

Some of both, and the research leans toward harm for blind and low-vision users. A 2024 study of blind and low-vision users found some benefited from font size or contrast controls. Of 34 survey respondents, though, 24 rated overlays not very or not at all effective, and overlay screen reader modes clashed with users' own software.

That study, by Makati, Tigwell and Shinohara at ASSETS 2024 (opens in a new tab), also found that about 42% of respondents had stopped using, or cut back on, websites because of overlays (UW CREATE summary (opens in a new tab)).

Practitioners and disability groups have said the same, more bluntly:

• The Overlay Fact Sheet (opens in a new tab) has more than 1,000 signatories, including W3C spec contributors and people who build the NVDA and JAWS screen readers. It argues that widget controls mostly repeat settings people already have on their devices. It also calls automated repair of alt text, form labels and keyboard access unreliable.
• In June 2021 the National Federation of the Blind's board revoked accessiBe's sponsorship (opens in a new tab) of its national convention.

Can an overlay get a local government sued?

An overlay doesn't stop a claim, and lawsuit data shows sites with widgets installed are still sued regularly. What draws a claim is the unfixed barriers underneath. UsableNet counted more than 1,000 businesses sued in 2024 with a widget installed, over 25% of cases (UsableNet (opens in a new tab)). Its 2026 midyear figure was about 20% (UsableNet (opens in a new tab)).

Those counts are mostly private businesses, and UsableNet sells remediation services. Still, its 2025 review (opens in a new tab) concluded that "widgets do not materially reduce legal risk." For a public entity, the practical question is the same: can a person using a keyboard or screen reader actually pay the water bill, find the agenda and submit the form?

What should a local government do instead?

Fix the site where the problems live: templates, content, documents and media. Then test by hand, keep monitoring and give residents a way to report problems. This is slower than pasting in a script, but it's the work the ADA Title II rule measures, and it stays fixed when the subscription ends.

A checklist to start with:

• Templates and components. Fix the header, menus, footer and form styles first, since each fix repeats across the site.
• Alt text. Have staff who know the image write it, and mark decorative images as decorative.
• Headings and links. Use headings in order and link text that says where it goes.
• Forms. Every field needs a visible label, clear error messages and keyboard access.
• Color contrast. Body text needs a contrast ratio of at least 4.5:1 (WCAG 1.4.3 (opens in a new tab)).
• Keyboard. Tab through key pages. Focus should be visible, and nothing should trap it.
• Captions. Caption meeting video and edit automatic captions. DOJ notes W3C guidance that automatic captions usually need editing (89 FR 31359 (opens in a new tab)).
• Documents. Put agendas and minutes on web pages where possible, and make new PDFs accessible.
• Manual testing. Try key tasks with a keyboard and a screen reader. The Michigan Townships Association (opens in a new tab) points members to NVDA, a free screen reader.
• Vendors. Ask payment, permitting and agenda vendors how they meet WCAG 2.1 AA.
• Monitoring. Scan on a schedule and treat results as a to-do list. Our free ADA website checker is a quick first look, but like any automated check it finds only some issues.
• Statement and feedback. Post an accessibility statement and a way to report problems. DOJ's guidance says a reporting channel helps site owners fix issues (ADA.gov (opens in a new tab)).