Accessibility overlay or fixing at the source.
An accessibility overlay tries to cover up accessibility problems with a script that runs after the page has loaded; fixing at the source resolves the problem in the site’s own code, templates and content.
The two approaches answer the same question from two different places. An overlay adds a layer on top of the site: the code does not change, and a script runs after the page has loaded. Fixing at the source changes the site itself: templates, components, color and content. This studio’s web accessibility audit does the latter and adds no fixing layer to the page; the comparison below sets out the reasons for this choice together with the overlay’s real benefit.
What can an accessibility overlay do, and what can’t it do?
The experts’ joint statement (Overlay Fact Sheet) divides overlays into two types. The first offers users a toolbar: text size, contrast, line spacing. According to the statement, most disabled users already use the equivalents of these settings in their operating system, their browser or their own assistive technology; the toolbar is often a duplicate. The second tries to repair the page’s code automatically. The limits the statement lists: alternative text written without knowing the meaning of the image, failing to connect form fields to the right label, being unable to reliably repair missing keyboard behavior, and falling behind on dynamically changing content.
On the conformance side, the question is clearer. WCAG’s conformance requirements are evaluated on full pages and for all success criteria of the relevant level. A script cannot know on its own the purpose of an image, the destination of a link or the clarity of an error message; these are decisions for someone who knows the content. In 2025 the US Federal Trade Commission found an overlay vendor’s claim that it “makes any website WCAG-compliant” unsubstantiated, and in April 2025 approved the final order barring the claim from being repeated without evidence.
The overlay does have a real benefit: it is quick to set up and does not require touching the site’s code. That is why it looks attractive at first glance to a team that has no way of changing the code. But that speed is not proof of conformance; the defect at the source stays where it is.
What does fixing at the source look like on this site?
The overlay column of this comparison relies on external sources; we did not measure an overlay on this site ourselves. The examples in the fixing-at-the-source column, however, come from this site’s own code and from the suite that runs on every release. Three examples, each covered in detail in its own guide:
- Focus indicator — the browser’s default ring was removed and replaced with the site’s own 2-pixel ring in its accent color; the ring is defined in one place as a design decision (focus indicator).
- Touch target — tappable elements are at least 44 pixels; the two-letter language switcher was brought up to this size with padding without being enlarged visually, and the suite measures targets on both desktop and mobile (touch target size).
- Reduced motion — when “reduce motion” is on in the operating system, animation layers are not set up at all and a still frame is loaded instead of video; the suite measures both that motion is not set up when the preference is on and that it actually works when it is off (reduced motion preference).
What the three have in common is that they live where an overlay cannot add anything afterwards: in color and size decisions, in templates, in loading logic. For the same reason there is no overlay on this site at all; the page loads scripts only from its own server. There is also a counterexample: the field borders in this site’s contact form were for a time below WCAG’s 3:1 threshold against the background, and the automated audit did not catch it, because it was not asking that question. The border was fixed in the color decision and a guard test was added. A layer cannot be expected to see a defect the tool does not see either (the limits of automated audits).
Which makes sense when?
In the short term an overlay may offer some visitors a setting; but it cannot be the answer to an audit, a statement or a legal obligation. In the long term the owner of the problem is the site’s source: the defect is born there, and the fix becomes permanent there. What an overlay is and why it is debated is explained briefly in the accessibility overlay entry.
If you want to know whether your site meets these criteria, the web accessibility audit measures every template against WCAG 2.2 point by point, fixes problems at the source and documents the result.
Criterion
Accessibility overlay
Where it runs In the visitor’s browser, after the page has loaded; changes the page structure with a script
Setup A one-line script; added without touching the site’s code
Alternative text Automatically generated text cannot know the image’s purpose on the page
Keyboard and focus Cannot reliably repair missing keyboard behavior and focus order
Fixing at the source
Where it runs In the site’s source: templates, components, color decisions and content
Setup Requires developer effort; every template and component is reviewed
Alternative text The text is written by someone who knows the content; decorative images are deliberately left empty
Keyboard and focus Real button and link elements are used; the focus indicator is part of the design
Accessibility overlay
The user’s own settings Offers tools such as text enlargement and contrast; their equivalents already exist in the operating system and browser
WCAG conformance Not proven to achieve conformance on its own; conformance is evaluated for full pages and all success criteria
Privacy An overlay that detects the use of assistive technology can reveal a visitor’s disability
Page weight Loads an extra third-party script on every page
When the site changes The new defect is born at the source, and the overlay tries to cover it up afterwards
Fixing at the source
The user’s own settings Browser zoom, reduced motion and contrast preferences are honored in the site’s own styles
WCAG conformance Each criterion is met at the source and can be documented by measurement
Privacy No third-party script enters the page for accessibility
Page weight No extra script; the fix lives in the page’s own code
When the site changes If a test measures the defect, its return shows up in that release
FREQUENTLY ASKED QUESTIONS
Does an accessibility overlay make a site legally compliant?
It has not been proven to do so on its own. In 2025 the US Federal Trade Commission found an overlay vendor’s claim that it “makes any website WCAG-compliant” unsubstantiated and barred it from repeating the claim without evidence; WCAG conformance, for its part, requires all success criteria to be met on full pages. This is not legal advice.
Where does removing the overlay and fixing at the source begin?
It begins with an audit. First you measure which criterion fails in which template, then the fix is made at the template and component level; if each fix is guarded by a test, it does not come back in later releases.
Can an overlay and fixing at the source be used together?
Technically yes, but the overlay does not remove the defect at the source and can itself become a new source of problems. The experts’ joint statement recommends not relying on overlays as a long-term solution and fixing problems at their source.