Accessibility overlays: what they mean in a vendor's VPAT

Sooner or later a vendor will answer an accessibility question with a widget. The proposal mentions an accessibility toolbar, or an AI-powered script that "automatically remediates" the product, and the conformance report reads "Supports" down the column. This article covers what an accessibility overlay is, why it does not make a product conform, and how to handle one in procurement.

What an accessibility overlay is

"Overlay" is used loosely for two different things, usually delivered as a script added to a web page.

• A preferences toolbar. An icon opens a panel that lets the user enlarge text, change contrast, pause animation, change fonts or highlight links.
• Automated remediation. A script that inspects the page as it loads and rewrites it: generating alternative text for images, adding ARIA attributes, adjusting focus behavior, relabelling form fields.

Many products sold this way combine both. Neither changes the vendor's underlying code. The fixes, if they are fixes, are applied in the user's browser each time the page loads.

Why an accessibility overlay does not make a product conform

Conformance to WCAG 2.1 is a property of the content as it is delivered. The standard's conformance requirements say conformance applies to full web pages and "cannot be achieved if part of a web page is excluded", and that every page in a process, such as an application or a checkout, must conform for any of it to conform. A product either meets 1.1.1 Non-text Content or 4.1.2 Name, Role, Value on the pages a resident uses, or it does not.

That creates three problems for overlay-based claims.

Automated repair is guesswork where meaning is involved. A script can detect that an image lacks alternative text. It cannot reliably know what the image communicates in context, whether a custom dropdown's behavior matches the role it has been given, or whether the visual order of a form matches its reading order. Criteria such as 1.3.1 Info and Relationships, 2.4.6 Headings and Labels, and 3.3.2 Labels or Instructions turn on meaning, and meaning is what the vendor's developers know and the script does not.

A toolbar the user must switch on is an alternate version, at best. WCAG allows a "conforming alternate version" only if it provides all the same information and functionality, is as up to date as the original, and can be reached through an accessibility-supported mechanism. The ADA Title II rule is narrower still: 28 CFR 35.202 permits conforming alternate versions "only where it is not possible to make web content directly accessible due to technical or legal limitations". A vendor that could fix its code but chose a toolbar instead is not in that position.

People who rely on assistive technology have usually configured it already. Screen reader users, people using screen magnification and people using operating system contrast settings bring their own tools. An overlay can duplicate those tools and, in some cases, interfere with them. That is a practical concern rather than a rule, but it is one more reason the overlay is not the measure of the product.

None of this means a preferences toolbar is harmful in itself. As an extra, on top of a product that already conforms, it can be a convenience. It is not evidence of conformance.

What the DOJ and the FTC have said

The DOJ addressed overlays briefly when it published the Title II web rule in April 2024. Commenters had raised concerns about public entities using accessibility overlays and automated checkers. The DOJ's response was that the rule sets a technical standard and does not address the internal policies or tools an entity might use to meet it. Read plainly: the rule neither approves nor prohibits overlays. The question is whether the web content and mobile apps conform to WCAG 2.1 Level AA, by whatever means.

The Federal Trade Commission went further with one vendor. In January 2025 the FTC announced a proposed order against accessiBe, which sells an overlay product called accessWidget. The FTC alleged that the company's claims that accessWidget "can make any website compliant with" WCAG were false, misleading or unsubstantiated, and that it had formatted third-party articles and reviews to look like independent opinions. The order requires the company to pay $1 million and bars it from representing that its automated products can make any website WCAG-compliant, or keep a website compliant over time, unless it has evidence to support the claim. The Commission approved the final order in April 2025. These were allegations resolved by a consent order, not findings after a trial.

The useful point for procurement is narrow and solid: a claim that software automatically produces WCAG conformance needs substantiation like any other claim. A vendor's conformance report is the place that substantiation should appear, and how to read a VPAT covers what substantiation looks like.

How overlays show up in VPATs

Overlay reliance is rarely announced. In reports we review, it tends to appear in one of these forms:

• Evaluation methods that mention testing "with the accessibility widget enabled", or that name only an automated scan.
• Remarks that point to a toolbar: "Supports. Users may increase contrast using the accessibility menu" beside 1.4.3 Contrast (Minimum).
• A block of "Supports" on criteria that need human judgment, such as 1.1.1, 1.3.1 and 2.4.6, with remarks that describe what the script does rather than what the product does.
• A report for the wrong product. An ACR for the overlay itself, attached in place of one for the software you are buying.
• A product description that leads with the widget.

A remark like "Supports. Our AI engine adds alternative text to images" tells you how the vendor hopes the criterion is met. It does not tell you that it is.

What to ask before award

If an overlay appears anywhere in a proposal or a report, put these in writing:

1. Was the evaluation performed with the overlay disabled? If not, ask for the conformance levels without it. That is the product you are buying.
2. Which criteria depend on the overlay? Ask for a list, by criterion number.
3. For each of those, what is the fix in the product's own code, and when will it ship? That is a remediation plan, and it belongs in the contract.
4. Is the overlay a separate product or service with its own terms? If it is withdrawn or changes, what happens to the conformance you were promised?
5. Will the vendor warrant conformance of the product as delivered, not conditional on a third-party script? See accessibility contract language.

The answers matter more than the presence of the overlay. A vendor that says "the toolbar is optional; the evaluation was manual, with NVDA and VoiceOver, with the toolbar off" is giving you a usable report. A vendor that cannot separate its conformance from its widget is telling you the product does not conform on its own.

Writing it into the solicitation

The simplest defense is to make the question unnecessary. State in the solicitation that the Accessibility Conformance Report must describe the product as delivered, evaluated without reliance on accessibility overlays or third-party remediation scripts, and that conformance claims dependent on such tools will be treated as not supported. The RFP requirements article has starting language for the rest of the requirement.

---

Sources: W3C WCAG 2.1, section 5 (Conformance) and the definition of "conforming alternate version"; 28 CFR 35.202 and the DOJ's April 2024 section-by-section analysis of the Title II web rule (89 FR 31320); FTC press releases of 3 January 2025 and 22 April 2025 on the accessiBe order. This is general guidance, not legal advice.

GOVvpat reads the evaluation methods and remarks in each vendor report and flags claims that rest on an overlay rather than the product. Request a quote.