Do Accessibility Overlays Work? What to Know

Do accessibility overlays work? It depends on what you ask the script to do. If you ask it to change how a page looks for one visitor, such as larger text or higher contrast in that browser session, it can do that job. If you ask it to repair the source code so every applicable WCAG success criterion is met, it cannot do that job on its own. The difference follows from where the change lives.

This is general information, not legal advice. If you have received a demand letter or been sued, talk to a qualified attorney.

Key takeaways

• A script overlay changes the page after it loads in the visitor browser. It does not edit the site source code.
• A code fix changes the markup itself, so the fix stays when the script is off.
• W3C defines meeting WCAG in strict terms: every applicable success criterion must be met, with no content that violates one.
• The FTC 2025 order was about outcome claims for an automated product, not a ruling that every script is banned.
• Test with the script off and with a keyboard task.

What a script overlay does

An overlay is a script added to a website. When a visitor opens a page, the script loads in that browser and tries to adjust what is shown. Many overlays offer a toolbar with controls for text size, contrast, spacing, or a reading mode. Some also scan the loaded page and try to patch problems on the fly, such as adding a label where one is missing.

The Overlay Fact Sheet describes this layer plainly. Overlays apply third party source code, typically JavaScript, to the front end code of a website. Some products scan the code when the page loads and try to repair problems in the browser. That repair happens after load, in that one browser session, on top of the original markup.

A toolbar setting can help a visitor who wants larger text on your page. It does not prove the underlying page was repaired.

What a code level fix does

A code level fix edits the markup, the styles, or the script that the site itself sends. Turn the overlay off, reload the page, and the fix is still there. Open the page in a different browser, and the fix is still there. A tester who views the page source can see it.

Take a form field. The failing version has an input with only placeholder text and no label tied to it:

<input type="text" placeholder="Email address">

The passing version ties a label to the input with matching for and id values:

<label for="email">Email address</label>
<input type="text" id="email" name="email">

A code fix puts that label in the source, where it survives a reload and a test that reads the source.

Why the bar is high

W3C Understanding Conformance gives a strict definition. Conformance to a standard means meeting the requirements of the standard. In WCAG 2, the requirements are the success criteria. To conform, there must be no content which violates the success criteria. That is an all applicable criteria test, not a score.

Two more W3C points matter for overlays. Conformance is for full pages only, and cannot be achieved if part of a web page is excluded. For a complete process, such as a checkout that runs across several pages, all pages in the process must conform at the specified level or better. A script that improves one view on one page does not settle a full page, and it does not settle a full checkout.

W3C also states that testing involves automated testing and human evaluation. A scan result that improves after a script loads is not the same as a human keyboard check.

What the Fact Sheet says cannot be repaired reliably

The Fact Sheet lists the repairs where automated work is not reliable. Automated application of text alternatives for images is not reliable. Automated repair of field labels, error management, error handling, and focus control on forms is not reliable. Automated repair of keyboard access is not reliable.

Each item needs judgment. A text alternative must say what the image means in context. A form error must say which field failed and how to fix it.

Two more limits often surprise site owners. Modern component based interfaces, such as those using React, Angular, or Vue, may change page state independently of the overlay, leaving it unable to fix those changes. Overlays also do not repair content in Flash, Java, Silverlight, PDF, HTML5 Canvas, SVG, or media files. The Fact Sheet conclusion is direct: overlays are not an effective means of ensuring accessibility.

What the FTC order did and did not do

On January 3, 2025, the FTC announced a complaint and a proposed order in a case about an AI powered web accessibility tool. The payment required was $1 million. The FTC alleged that claims that the tool could make any website meet WCAG were false, misleading, or unsubstantiated. The complaint also covered review practices, alleging that third party articles and reviews were presented as independent opinions without disclosing material connections to the company.

On April 22, 2025, the FTC approved a final consent order, by a 3-0 vote. The final order bars the company in that case from representing that its automated products can make any website meet WCAG, or ensure continued WCAG conformance over time, unless it has evidence to support such claims. For the full facts of that case, see the FTC order article.

The order did not ban overlays as a category. It addressed marketing claims and disclosure practices in that case, for that company.

A ten minute test you can run

Run these steps on a page that matters, such as a contact form or a checkout step.

1. Turn the overlay off, then reload the page. Read the source for the label, heading order, and button names.
2. Turn the overlay back on, then reload again. Note what changed in the rendered view, and whether the source changed.
3. Put the mouse aside. Use only the Tab key, Shift plus Tab, and Enter to complete the main task. Note where focus stalls.
4. Try the same task with a screen reader if you can. Note whether the form errors and button names make sense out of visual order.
5. Write down the date, the page, the task, and what failed. For a simple log format, see the remediation log article.

If the first step shows the same barriers as the second, the script changed the view, not the site. If the keyboard task stalls in the same place with the script on and off, the keyboard barrier is still in the source.

Common mistakes

• Judging a tool only by a score that moves after the script loads, without reading the source.
• Accepting a review that does not disclose payment or a business connection to the seller.
• Assuming a toolbar setting replaces a fix in the markup for labels and focus order.
• Deleting a script and stopping there, without fixing the barriers underneath it.

How Axeazy helps with this exact issue

Axeazy takes the code route. It scans a site for WCAG 2.2 AA problems using axe-core, then fixes the underlying code instead of painting a script over the page. For a site with its own GitHub repository, fixes arrive as a real pull request with a visible code diff for review and merge. For other sites, the scan gives computed fix values and a guided checklist to apply by hand. Read the honest scope on the capabilities page, and read how the scan works.

Every scan and fix is recorded with a date and time. For the wider legal picture, start with the state by state overview. Axeazy does not scan content behind logins or on third party hosted embeds the scanner cannot reach.

Want a quick read on your own site? Run Axeazy's free 60 second scan . It needs no signup.

Last checked: October 28, 2026.

FAQ

Do accessibility overlays work at all?

A toolbar setting can change text size or contrast for one visitor in one session. As a repair method, a script does not edit the site source, so it does not settle whether every applicable WCAG success criterion is met.

Why does turning the script off matter as a test?

Turning the script off returns the page to its original markup. If a barrier is gone only while the script runs, the barrier is still in the source. A code fix stays after the script is off.

Did the FTC ban accessibility overlays in 2025?

No. The FTC approved a final consent order in April 2025 that required a $1 million payment and barred certain claims for the company in that case. It did not ban overlays as a category.

What should I do if my site already uses a script based tool?

Check the source code and test the main tasks with a keyboard and, where possible, a screen reader. Keep a dated log of the barriers, the code changes, and the retest date. If a barrier sits in the markup, fix the markup.

Sources

• W3C Understanding Conformance, WCAG 2.2, checked October 28, 2026
• Overlay Fact Sheet, checked October 28, 2026
• FTC Order Requires Online Marketer to Pay $1 Million, checked October 28, 2026