Accessibility overlays and source fixes

An accessibility overlay is a script that changes a shop’s pages in the visitor’s browser after they have loaded. A source fix changes the shop’s templates, styles or scripts, so the corrected page is what the server sends to every browser and every tool.

Request a free check How a project runs

Last updated: 20 October 2026

On this page: 9 answers

What is the difference between an overlay and a source fix?

The difference between an accessibility overlay and a source fix is where the change is made. An overlay changes the page in each visitor’s browser; a source fix changes the files the page is built from.

Accessibility overlay: A script added to a shop’s pages that changes each page in the visitor’s browser after it has loaded. The script can add or change attributes, text and styles, and it can add controls of its own. Apart from the reference that loads the script, the shop’s own code stays as it was.
Source fix: A change to the shop’s own templates, stylesheets or scripts: the files the server builds each page from. Once the change is live, the corrected page is what the server sends.

What does an overlay change?

An accessibility overlay changes the page in the visitor’s browser, and only there. Its script loads with the page, reads what the browser has built from the shop’s HTML, and changes it, again on every page view, in every browser that loads and runs the script.

Details: repairs that need knowledge the page does not contain

Some repairs need knowledge that the page does not contain, for example what a product photo is meant to tell a buyer. The script cannot read that from the page: it has to infer it, or add text that someone entered with the provider. Either way, the result exists only in browsers that run the script.

What does an accessibility overlay not fix?

An accessibility overlay does not fix the code that produces a failure. The theme’s files and the HTML the server sends stay as they were, apart from the reference that loads the overlay, and a browser or tool that does not run the script gets the page with its original failures.

What an overlay leaves as it was

The theme’s files.
The HTML the server sends.
What a browser or tool gets without the script.
The page before the script has run.
The page after the script is removed.
Anything the script does not run in.

Details: what an overlay leaves as it was, one by one

An accessibility overlay does not fix the code that produces a failure. Everything the page is built from stays as it was, and so does every copy of the page that the script does not reach:

The theme’s files. The shop’s templates, stylesheets and scripts stay as they were, apart from the reference that loads the overlay.
The HTML the server sends. It is the same as before, apart from that reference.
What a browser or tool gets without the script. A browser with JavaScript turned off, a browser in which the script is blocked or fails to load, and a tool that reads the HTML without running scripts all get the page with its original failures.
The page before the script has run. Until the script has loaded and made its changes, the page is as the shop’s code delivers it.
The page after the script is removed. When the overlay is switched off or removed, the pages are as they were before it was added.
Anything the script does not run in. A PDF, an email from the shop, or a page on another domain that does not load the script, such as an externally hosted payment page.

How can you check this on any shop?

You can see where a change was made with an ordinary desktop browser, without access to the shop’s code: compare the source with the rendered page, block the overlay’s script and reload, or ask to see the change in the code.

Three checks

Compare the source with the rendered page. The browser’s “View page source” shows the HTML the server sent. The element inspector in the browser’s developer tools shows the page after its scripts have run. An attribute or text that appears only in the inspector was added by a script after the page loaded.
Block the overlay’s script. Block the address the script loads from, for example with the request blocking in the browser’s developer tools, and reload the page. What is left is the shop as its own code delivers it.
Ask to see the change in the code. A source fix is a change to a file of the theme that a developer can show you, with its date. A change made by an overlay is not in the theme’s files.

What do regulators and lawsuit figures say about overlays?

In April 2025 the US Federal Trade Commission approved a final order that bars a company selling an automated accessibility plug-in from claiming that its products can make any website WCAG-compliant when it does not have evidence for the claim. Germany’s supervisory bodies for public websites state that overlay tools currently cannot make a website with barriers fully accessible.

US Federal Trade Commission, 22 April 2025

A final order against a company that sells an automated accessibility plug-in

It bars the company from claiming that its automated products can make any website WCAG-compliant, or keep it so over time, when it does not have the evidence to support the claim.
Germany’s supervisory bodies, joint assessment revised in March 2025

Overlay tools currently cannot make a website that has barriers fully accessible

Using them can create additional barriers. The joint assessment concerns the websites of public bodies under the Web Accessibility Directive (EU) 2016/2102.
UsableNet, United States, 2024

1,023 companies with an accessibility widget live on their website received lawsuits

A lawsuit is a claim, not a ruling, so the figure says nothing about how the cases ended.

Source: US Federal Trade Commission, press release of 22 April 2025; BFIT-Bund, joint assessment of the supervisory bodies (in German); UsableNet, 2024 Year-End ADA Web Lawsuit Report

The US Federal Trade Commission, final order of 22 April 2025

On 22 April 2025 the US Federal Trade Commission (FTC) approved a final consent order against a company that sells an automated accessibility plug-in for websites. The FTC’s complaint, proposed in January 2025, alleged that, contrary to the company’s claims, the plug-in did not make all websites that used it WCAG-compliant.

The order bars the company from claiming that its automated products can make any website WCAG-compliant, or keep it so over time, when it does not have the evidence to support the claim. It also bars the company from presenting reviews, blog posts or articles about its products as independent opinions when they are not, and it requires the company to pay USD 1 million. Source: the FTC’s press release of 22 April 2025.

Germany’s supervisory bodies for accessible information technology, March 2025

Germany’s federal and state supervisory bodies for the accessibility of information technology (Überwachungsstellen des Bundes und der Länder) state in a joint assessment that overlay tools currently cannot make a website that has barriers fully accessible, and that using them can create additional barriers. The assessment was revised in March 2025. It is published by BFIT-Bund, the federal supervisory body. Its key sentence in the original German: “Aktuell sind Overlay-Tools nicht in der Lage, einen Webauftritt, der Barrieren aufweist, vollständig barrierefrei darzustellen” (currently, overlay tools are not able to make a website that has barriers fully accessible).

The assessment adds that overlay tools and assistive technologies used at the same time can interfere with each other, which can make the website hard or impossible to use for disabled people. It concerns the websites of public bodies under the Web Accessibility Directive (EU) 2016/2102: such a website is accessible only if it meets the requirements without an overlay tool. Source: the joint assessment on bfit-bund.de, in German.

What is the alternative to an accessibility overlay?

The alternative to an accessibility overlay is a source fix: a correction in the file that produces the failure, such as a template, stylesheet or script. Once the change is live, the corrected markup and styles are part of what the server sends, so they reach every visitor, browser and tool.

Validiscan delivers its fixes this way

As a change you can review.
Nothing on your live shop changes until you decide.
In the files that cause the failure.
Without a script of its own.
Checked after it is live.

Details: what a source fix changes, and how Validiscan delivers its fixes

The alternative is a source fix: a correction in the file that produces the failure, such as a template, a stylesheet or a script of the shop’s theme. Once the change is live, the corrected markup and styles are part of what the server sends, so they reach every visitor, browser and tool without depending on an extra script.

Validiscan delivers its fixes this way:

As a change you can review. Validiscan delivers the changes as a pull request on a new branch of your repository with one commit per fix, as an unpublished copy of your Shopify theme, or as a patch bundle with one patch file per fix.
Nothing on your live shop changes until you decide. You or your developer merge the pull request, publish the theme copy or apply the patch.
In the files that cause the failure. A fix can change a template, a stylesheet or one of the theme’s own scripts. For example, a slideshow that advances by itself gets a pause button in its template, and a block of code added to the theme’s main script connects the button to the slideshow.
Without a script of its own. Nothing in a Validiscan delivery runs on your site by itself, and Validiscan never adds a script that repairs your pages in visitors’ browsers after they have loaded. Code added to the theme’s own scripts becomes part of your code, and your developer reviews it with the rest of the change.
Checked after it is live. Once the changes are live, a verification scan checks the affected pages again, and the Remediation Evidence Package records what was tested, changed and verified, with dates.

How a project runs, step by step

How do the two approaches compare?

An accessibility overlay and a source fix differ in where the change lives, who can see it and what is left afterwards: an overlay’s repairs were never in your code, while a source fix’s changes are part of it.

Accessibility overlay and source fix, compared by where the change is made
Question	Accessibility overlay	Source fix
Where is the change made?	In the visitor’s browser, by a script, on every page view	In the theme’s own files, once
What does the server send?	The same HTML as before, plus a reference to the script	The corrected HTML and styles
What does a browser or tool get that does not run the script?	The page with its original failures	The corrected page
Can your developer review the change before it goes live?	Not as a change to the shop’s code	Yes: line by line in a pull request or a patch bundle, or as a preview of an unpublished theme copy
What is in your code when you stop paying the provider?	None of the repairs, because they were never in your code	The changes, because they are part of your code
What can undo the change?	The script failing to load, being blocked or being removed	A later change to the theme, for example a theme or app update
What runs in the visitor’s browser that was not there before?	The overlay’s script	No separate script. Where a fix needs behaviour, code added to the theme’s own scripts

What does a source fix not do?

A source fix has limits too: it needs access to the shop’s code, it fixes only what code can fix, it does not reach third-party embeds such as payment or chat widgets, and a later theme or app update can bring a fixed failure back.

Details: each limit in full

A source fix has limits too, and they are worth knowing before you choose:

It needs access to the code. Validiscan works on a clone of your repository, a copy of your Shopify theme, or an export of your theme that your developer uploads. You or your developer review the change before it goes live.
It fixes what code can fix. Some failures need a content or design decision that only you can make, for example captions for your product videos. For these, Validiscan gives guidance (tier MANUAL) instead of a change to your code.
It does not reach what is not in your theme. Third-party embeds, such as payment or chat widgets, bring their own code, which a change to your theme does not alter. They are not part of a Validiscan project, and neither are PDFs.
It can break again. A later theme or app update can bring a fixed failure back. Regression protection scans the shop again on a schedule and reports a failure that was fixed and has come back.

What should you ask any accessibility provider?

Ask any accessibility provider, Validiscan included, where the change lives, whether your developer can see every change before it goes live, and what stays in your shop if you stop paying. If a provider promises that your shop meets the law or is protected from legal claims, ask what that promise rests on.

These questions work for any provider, Validiscan included. The answers show where the work ends up and what you can check yourself. Validiscan’s own answer follows each question.

Where does the change live: in my theme’s files, or in a script you host? Validiscan: in your theme’s files.
Can my developer see every change before it goes live? Validiscan: yes. A pull request has one commit per fix, and a patch bundle has one patch file per fix. An unpublished Shopify theme copy can be previewed and checked before you publish it.
What stays in my shop if I stop paying you? Validiscan: the changes, because they are part of your code. Regression protection can be cancelled to the end of any month.
What runs in my visitors’ browsers that was not there before? Validiscan: no separate script, and nothing loaded from Validiscan. Where a fix needs behaviour, such as a pause button for a slideshow, it adds code to your theme’s own scripts, which you review with the rest of the change.
What is not covered? Validiscan: findings that need your own content decisions (tier MANUAL), third-party embeds such as payment or chat widgets, and PDFs.
How much of the testing is automated, and what does a person check? Validiscan: automated scans report failures that can be proven from a page’s code, and they do not find every failure. A manual checklist of 35 items, which a person works through, covers every WCAG 2.2 criterion that no rule tests and some that rules test only in part. For the other criteria, among them 1.1.1 Non-text Content, a result rests on automated checks alone. The method and the standards
How are the fixes checked after they go live, and what record do I get? Validiscan: a verification scan of the affected pages, and a dated Remediation Evidence Package.
What exactly do you state about the result? Validiscan: the package reports conformance with WCAG 2.1 AA and WCAG 2.2 AA success criteria as evaluated on the listed pages and dates. It is evidence of an evaluation and of remediation work, not a certificate.
Do you promise that my shop meets the law, or that it is protected from legal claims? Ask what such a promise rests on. Validiscan makes no such promise: whether a shop meets a law is a legal assessment, for you and your lawyer.

Sources

3 sources, each checked for this page on 6 October 2026.

United States 2

FTC Approves Final Order Requiring accessiBe to pay $1 Million · US Federal Trade Commission · 22 April 2025 · checked 6 October 2026
2024 Year-End ADA Web Lawsuit Report · UsableNet · checked 6 October 2026

Germany 1

Gemeinsame Einschätzung der Überwachungsstellen des Bundes und der Länder für die Barrierefreiheit von Informationstechnik zum Einsatz von Overlay-Tools · BFIT-Bund · checked 6 October 2026

Start with a free check of your shop.

Send your shop’s address. Validiscan scans it and replies with every failure the scan can prove, with the page and the code.

Request a free check

Or write to info@validiscan.com.

What the free check covers, and what it leaves out

You send: your shop’s address
Pages scanned: up to 15
You get: every failure the scan can prove, with the page and the code
On your shop: public pages only; no login, nothing bought, no forms sent
What it is not: a full audit