We don’t put an overlay on your site. Here is why.

An accessibility overlay is third-party code that a site owner adds to their pages. When someone visits, it runs in their browser. The Overlay Fact Sheet, written by accessibility practitioners, describes the newer products this way: “They apply a script to the page which scans the code and automatically attempts to repair the problem” [Source: Overlay Fact Sheet].

Vendors describe the same mechanism in their own words. UserWay says customers “add a single line of JavaScript” and that its widget “modifies the presentation layer of web pages” [Source: UserWay, product facts]. EqualWeb says its widget “applies fixes in real time through the browser DOM, so your original source files are never modified” [Source: EqualWeb, widget]. The page your team built does not change. What changes is what the script does to it in each browser.

The W3C, which publishes WCAG, has not issued a formal position on overlays, and we won’t claim it has. What it does say applies to every automated tool, including ours. WCAG 2.2 is designed “to be testable with a combination of automated testing and human evaluation” [Source: WCAG 2.2], and the W3C’s evaluation overview says “no tool alone can determine if a site meets accessibility standards” [Source: W3C WAI, evaluation overview].

An automated fix inherits the limits of the automated test that found the problem. The W3C’s guidance on choosing evaluation tools puts it plainly.

In January 2025 the US Federal Trade Commission announced a proposed order requiring accessiBe to pay $1 million to settle allegations that it misrepresented the ability of its AI-powered tool to make any website WCAG compliant [Source: FTC, Jan 2025]. The complaint alleged that “in a number of instances accessWidget fails or has failed to make basic and essential website components like menus, headings, tables, images, recordings, and more, compliant with WCAG” [Source: FTC complaint], and that third-party articles and reviews were formatted to look independent without disclosing accessiBe’s connection to them [Source: FTC, Jan 2025].

The FTC approved the final order in April 2025 [Source: FTC, Apr 2025]. accessiBe neither admitted nor denied the allegations [Source: FTC decision and order], and the $1 million “may be used to provide refunds to consumers” [Source: FTC, Jan 2025]. The order concerns one company’s claims, not overlays as a category, but it is a direct statement from a regulator about what an automated tool can promise.

Organisations of disabled people have been consistent. The National Federation of the Blind resolved in 2021 that overlays “may help to make certain parts of a website nonvisually accessible” but “alone cannot guarantee full nonvisual access to every website where they are deployed” [Source: NFB resolutions, 2021]. The American Council of the Blind resolved the same year that overlays “create a separate and often inferior experience for website users who are blind or have low vision” [Source: ACB, 2021].

In Europe, the European Disability Forum and the International Association of Accessibility Professionals said in 2023 that overlays “do not make the website accessible or compliant with European accessibility legislation” [Source: EDF and IAAP, 2023]. More than 1,000 people have signed the Overlay Fact Sheet, which says “full compliance cannot be achieved with an overlay” [Source: Overlay Fact Sheet]. (The signature count is ours, taken from the page on the date we checked.)

UsableNet, which sells accessibility services and publishes an annual lawsuit report, counted that “In 2024, 1,023 companies with an accessibility widget live on their website received lawsuits,” noting that many of those suits “cited the widget’s features as barriers to equal access” [Source: UsableNet, 2024 report]. Its December 2024 figure was a projection at the time of publication.

Its 2025 report is blunter: “Accessibility widgets did not slow litigation in 2025. An increasing number of lawsuits were filed against companies already using these tools” [Source: UsableNet, 2025 report]. This does not show that a widget causes a lawsuit, and we don’t claim it does. It does show that installing one is not a defence on its own.

Scanners have limits too, and we would rather say so than have you find out. Deque, which makes the open-source axe engine TrustScans runs alongside its own checks, reports that automated testing covered 57% of issues on average in its own audit data, measured by volume of issues rather than by success criteria [Source: Deque, 2021]. The UK Government Digital Service planted 142 barriers on a test page and found the best tool it tested caught 40% of them [Source: GDS tool audit, 2018]. Those figures measure different things, and both are dated, but they agree on the point: automation finds a large share of problems, never all of them.

That is why a TrustScans report keeps three lists apart: confirmed failures, items that need a person to check, and best-practice recommendations. Only confirmed failures count toward the score, and no report claims that a site conforms to WCAG.

Public bodies in the US now have a named standard and a date. Under the Department of Justice’s 2024 rule for ADA Title II, state and local government web content “usually needs to meet WCAG 2.1, Level AA,” including pages an outside web company builds and updates for them [Source: DOJ, 2024 Title II rule]. An interim final rule effective 20 April 2026 moved the compliance dates: public entities with a total population of 50,000 or more now have until 26 April 2027, and entities under 50,000, along with any special district government, until 26 April 2028 [Source: DOJ, 2026 interim final rule]. Confirm which category your organization falls in with counsel.

Either way, the obligation is about the content your organization publishes. An overlay leaves that content as it is [Source: EqualWeb, widget] [Source: UserWay, product facts]. What helps is knowing where your pages fail WCAG 2.1 AA, fixing them in the source, and keeping dated records of the work. Our ADA coverage page summarises the rule with its primary citations.

We decided early that TrustScans would never put anything on a customer’s site. A scan loads your public pages in a real browser from the outside and tests each one. Nothing about your site changes until your team changes it, and when they do, the fix reaches every visitor.

The report is built to make that work possible. Each finding names the WCAG success criterion, the pages it appears on, the element’s selector and HTML, and a highlighted screenshot for the first occurrences. Markup that fails the same way on three or more pages is flagged as a likely shared component. Every rule comes with guidance on why it matters and how to fix it, and our coverage library explains the regulations behind them.

Then we help you keep going: recurring scans, regression alerts on every plan, remediation progress that is only verified by a new scan, report views for executives, managers and developers, PDF and CSV exports, and an API and MCP server that lets a coding agent work through the issue queue in your codebase.