An accessibility overlay is a layer added to a site afterward with JavaScript, offering visitors a few display settings. It can be useful, but it does not fix the structural accessibility issues in the page source code. In this guide we explain the difference between the overlay approach and real WCAG 2.2 scanning, the limits of overlays and an honest path to compliance. This content is not legal advice.
An accessibility overlay is a layer applied on top of an existing website afterward, using JavaScript. It typically opens a small button and offers visitors a few display settings, such as enlarging text, increasing contrast, stopping animations or a reading guide. These settings can provide a practical convenience for some users.
What matters is what an overlay does not do. An overlay does not fix the structural accessibility issues present in the page source code. A missing alt text, a broken heading hierarchy, an unlabeled form field, insufficient color contrast or a component that cannot be reached by keyboard are not permanently resolved by a display layer added on top at runtime. These issues live in the HTML, CSS and ARIA layer, that is, in the source code itself, and that is where the fix belongs.
There are two basic approaches to accessibility on the market. They are not the same thing and do not produce the same result. Below we compare the two in a factual way, without exaggeration.
An overlay works at the presentation layer. It changes the page appearance at runtime; it enlarges text, inverts colors, stops motion. It installs quickly and leaves a visible button. However, it does not measure, does not report violations and does not change the source code. The structural issues underneath the page remain in place; the overlay only covers them with a display layer.
Scanning works at the code level. It examines the page against the WCAG 2.2 success criteria, detects violations and reports them by severity (critical, serious, moderate, minor). The output is not a visible button but a measurable finding: which element violates which criterion, and how severely. These findings guide the fixes to be made in the source code and let you track progress with a score.
The two are not opposites but complementary. A well-designed widget that offers visitors useful display settings is valuable; however, an overlay alone is not a substitute for the measurement and source code fixes that need to happen. Meaningful accessibility work starts with scanning.
The accessibility community and domain experts have long noted that automated overlays do not deliver WCAG compliance on their own. The reason is structural: because an overlay does not measure and does not change the source code, it does not resolve the underlying violations. Moreover, in some cases the overlay itself can conflict with assistive technology, for example screen readers, and disrupt an experience that already worked. For this reason an overlay should be seen not as the starting point of an accessibility program but, at most, as a complement to it.
This also took concrete form at the regulatory level. In 2025, the US Federal Trade Commission (FTC) imposed a USD 1 million penalty on the overlay provider accessiBe over deceptive claims that its automated tool made websites WCAG compliant. This is a public, concrete decision showing that the claim of an automated tool achieving compliance on its own was rejected by a regulator. Source: ftc.gov.
Meaningful accessibility progresses not through a button but through a measurable loop. The four steps are a repeating process, not a one-time task.
Scan the page against the WCAG 2.2 success criteria. Automated scanning surfaces machine-detectable violations such as missing alt texts, contrast issues, unlabeled form fields and broken heading structure. This is an objective snapshot of the current state.
Report the violations by severity: critical, serious, moderate, minor. This ranking lets you spend limited time on the issues with the most impact. A compliance score (0-100) makes progress measurable over time.
This is where the real work is. The detected violations are fixed in the HTML, CSS and ARIA layer, that is, in the source code: missing alt text is added, the heading hierarchy is corrected, form fields are labeled, contrast is resolved. No runtime layer does this permanently for you.
Document your work with an accessibility statement. Under EAA Article 13, a statement transparently describes your compliance status, known limitations and a feedback channel. The statement makes the outcome of the process visible and accountable.
cerez.io does not guarantee full WCAG compliance; it measures your situation, reports violations and helps document them with a statement. Our approach is not an overlay; it is built on a real WCAG 2.2 scanner and a real accessibility widget running inside a Shadow DOM.
The platform scans your site against the WCAG 2.2 success criteria, detects violations by severity (critical, serious, moderate, minor) and produces a 0-100 compliance score with a prioritized violation report. This covers the measurement and reporting step that an overlay does not.
AvailableThe real accessibility widget runs inside a Shadow DOM, in isolation. It does not break the host site's CSS and does not interfere with the page structure. It offers visitors more than 40 features and more than 10 profiles; this is a controlled, isolated component, not a superficial display layer.
AvailableThe platform helps you create the accessibility statement under EAA Article 13: compliance status, known limitations and a feedback channel. This completes the final link of the four-step process, namely documentation.
AvailableScan your site against WCAG 2.2, see violations by severity, add the Shadow DOM widget and start building your EAA statement. Set up in 5 minutes.