Accessibility overlays vs real audits
Overlay widgets inject a JavaScript layer on top of your site at runtime. They don't change the underlying HTML, ARIA, or content — which is what WCAG, EN 301 549, and EU regulators actually measure. Here's what that means in plain language, and what a real audit delivers instead.
Sourced from Overlay Fact Sheet, WebAIM, and EU regulator guidance
A JavaScript layer on top of an unchanged site
When a visitor loads a page with an overlay widget installed, the widget's script runs after the browser has already parsed the HTML. It tries to detect patterns (missing alt text, missing labels, low contrast) and apply runtime fixes — rewriting a small fraction of the DOM, adding ARIA attributes, switching colour themes.
None of this changes the source of the site. The underlying HTML that ships to every visitor — and that WCAG, EN 301 549, and EU regulators actually measure — is unchanged. A screen reader user on a phone, a keyboard user tabbing through a form, a colour-blind visitor at checkout: they meet the original page, not the widget's patch of it.
That's the mechanical core of why overlays cannot satisfy conformance on their own. Everything below follows from it.
Overlay widget vs evidence-backed audit
Both are sold as “accessibility solutions”. Only one changes what WCAG, EN 301 549, and EU regulators evaluate.
Ten WCAG failures overlays cannot repair
These are the kinds of issues our scanner finds on every audit. None of them can be silenced by a runtime JavaScript layer — they have to be fixed in the source.
Heading hierarchy that skips levels (H1 → H3 → H2 → H4).
Form inputs without semantic <label for="…"> associations.
Buttons built from non-interactive elements (<div onClick>) with no keyboard focus or role.
Source-level colour-contrast failures in the brand palette.
Modals that don't trap focus, don't announce themselves to screen readers, or don't restore focus on close.
Custom components (carousels, tab panels, autocompletes) missing ARIA roles, states, and properties.
Reading order that depends on visual CSS positioning, not document order.
Video and audio without captions, transcripts, or accessible media controls.
Images that convey information without descriptive alt text.
Language of the page not being set (lang attribute) for screen-reader pronunciation.
EU authorities measure the underlying service, not the widget
The EAA (Directive 2019/882), the harmonised standard EN 301 549, and every national transposition we have reviewed reference the underlying digital service, not any overlay layer applied on top of it. A legitimate conformance claim has to cite the underlying code and the evidence used to verify it.
§3 of the Barrierefreiheitsstärkungsgesetz applies to the service itself. Market surveillance treats overlays as supplementary at best; they do not discharge the §3 obligation.
Read moreThe RGAA 4.1 référentiel and the accessibilité declaration both reference the site's underlying code. DGCCRF has opened market-surveillance files where overlays were cited as the sole measure.
Read moreOACIAP and the autonomous communities audit against UNE-EN 301 549, which references the underlying service. An overlay on top is not a conformance statement.
Read moreANPC enforces against product-as-delivered. Romanian consumer-protection complaints routinely cite the underlying checkout flow, not the widget.
Read moreClause 9 explicitly incorporates WCAG 2.1 AA success criteria against the content the user agent receives. That's the source HTML, not a runtime-patched version of it.
Read moreThe EAA is technology-neutral but presumes conformance via EN 301 549. An overlay does not alter the scope of what has to be demonstrated.
Read moreThe people overlays claim to help mostly disagree
The Overlay Fact Sheet is the most widely cited independent statement on this topic. It has been signed by hundreds of accessibility professionals, including blind and low-vision screen reader users, keyboard-only users, and users of speech recognition software — the actual constituency overlay marketing targets.
Their consensus: overlays frequently interfere with the assistive technology users have already chosen and configured. WebAIM's end-user survey (the largest public survey of screen reader users) has repeatedly reported low satisfaction with overlays and a strong preference for sites built accessibly in the first place.
This is the single most important framing point for a client conversation. “The users this is for mostly don't want it” is the shortest honest summary of the research.
Where a widget is genuinely useful
Not every overlay is harmful. Some widget features are just user-preference controls — if they're layered on top of a site that is already accessible in its default state, they can be a nice personalisation option. What they cannot do is substitute for making the underlying site accessible in the first place.
Font-size toggles offered as a user preference on an already-accessible site.
High-contrast or dark-mode themes layered on top of a palette that already meets contrast in its default state.
Dyslexia-friendly font switching — again, as a personalisation option, not as a substitute for accessible typography.
Reading-ruler or focus-highlight tools for cognitive-load support.
A real audit turns your codebase into the compliance story
Every AccessiProof audit is a report your developers can act on and a paper trail you can hand to a regulator, procurement team, or plaintiff if challenged. The evidence sits on your side.
Every issue cited
Each finding includes the selector, the failing HTML snippet, the WCAG criterion, the EN 301 549 clause, and whether the clause is in the harmonised version.
Acceptance criteria
AI-assisted remediation gives your developers a clear pass/fail check for each fix — not just a vague 'make this accessible'.
Effort bands
Quantified hour estimates split by templated vs bespoke instances so you can plan sprints honestly and price the remediation.
White-label for agencies
Your agency logo, your brand, sent to your client as the deliverable. No third-party widget branding on their site.
Monthly monitoring
Once fixed, monthly scans catch regressions before they reach customers — because accessibility drifts every time content changes.
Tracker-ready JSON
Export tickets directly to Jira, Linear, or any markdown-aware tracker. Cuts the hand-off time from hours to minutes.
Replace the overlay with evidence
Start with a free five-page scan. If it looks worth a full audit, we turn it into a developer-ready remediation plan with acceptance criteria, effort estimates, and an evidence package you can defend in front of a regulator.
Overlay questions EU agencies actually hear
Does an accessibility overlay make my website WCAG compliant?
No. WCAG 2.1 AA compliance is measured against the underlying HTML, ARIA, and content of your website. Overlays inject a JavaScript layer at runtime — they do not modify the source HTML that assistive technology reads. Many WCAG criteria (logical heading order, accessible names, form labels, sufficient colour contrast in the source design, keyboard focus order) cannot be satisfied by a runtime JavaScript layer at all.
Is an overlay widget enough for the European Accessibility Act?
No. The EAA (Directive 2019/882) and the harmonised standard EN 301 549 reference the underlying service, not a widget on top of it. EU regulators — including Germany's BFSG enforcement framework and France's DGCCRF — treat overlays as supplementary personalisation at best, not a substitute for compliance. A legitimate EAA conformance claim has to cite the underlying code, the evidence, and the methodology used to verify it.
Have overlay vendors been sued?
Yes. In the United States, multiple ADA lawsuits (tracked publicly by UsableNet and the Accessibility.com lawsuit tracker) have been filed against websites that relied on overlay widgets, with the overlay vendor sometimes named as a co-defendant. In 2022 AccessiBe settled a FTC-adjacent complaint about marketing claims. No US court has accepted 'we installed an overlay' as a defence against an ADA Title III claim.
What is the Overlay Fact Sheet?
The Overlay Fact Sheet (overlayfactsheet.com) is a statement signed by hundreds of independent accessibility professionals — including people with disabilities who rely on assistive technology — documenting why overlays fail to deliver real compliance and often actively harm users. It is the most widely cited independent reference on the topic.
Is it ever okay to use an overlay?
A small set of overlay features — font-size toggles, high-contrast themes, dyslexia-friendly fonts — are just preference controls. They're fine as optional personalisation on top of an already-accessible site. What they cannot do is substitute for fixing the underlying HTML, ARIA, or content. If the site is inaccessible without the widget, it is still inaccessible with it.
What do assistive technology users experience with overlays installed?
Frequently, worse. Overlays inject event listeners and DOM modifications that collide with the user's screen reader (JAWS, NVDA, VoiceOver), their keyboard shortcuts, and their existing browser extensions. This is documented by the Overlay Fact Sheet and by usability studies from WebAIM. The accessibility community's consensus is that overlays interfere with the adaptive tooling disabled users have already chosen and configured.
What does a real accessibility audit deliver instead?
An evidence-backed audit identifies the specific HTML/CSS/JavaScript changes needed to meet WCAG 2.1 AA: selectors, failing code snippets, acceptance criteria, remediation effort estimates, and a prioritised roadmap. The output is a report your developers can act on and a paper trail you can show a regulator, procurement team, or plaintiff's lawyer if challenged.