Overlay Tools vs. a Real Accessibility Audit: What Actually Protects You

The promise: accessibility via a script snippet

Since the BFSG took effect, one particular offer has boomed: overlay tools such as accessiBe, UserWay or EqualWeb promise to make your website "instantly accessible" with a single line of code – usually for a monthly fee. To many owners that sounds like the perfect solution: no rebuild, no developer, no effort. That is exactly why a sober look at what these tools technically do is worth it.

How overlays technically work

An overlay is JavaScript that runs in the visitor's browser after the page loads. It layers itself over the existing page and modifies the DOM after the fact: it injects a control widget (font size, contrast modes, read-aloud) and in part tries to fill in missing attributes automatically, using heuristics and AI – for instance "guessing" alt texts or ARIA roles.

The decisive point: all of this happens client-side and superficially. The overlay does not repair your source code; it manipulates the result afterwards. The underlying problems remain – they are merely covered up.

What overlays cannot do

• Repair semantics: an automatically guessed alt text ("image", "graphic123.jpg") is not a meaningful alt text. Context that only a human knows cannot be invented by automation.
• Resolve keyboard traps: if a hand-built modal locks focus in place, an overlay widget doesn't help – the trap remains.
• Fix form logic: mis-linked labels or colour-only error messages require changes in code, not an additional script.
• PDFs and embedded content: downloads, iframes and third-party widgets are usually out of an overlay's reach entirely.
• Avoid new barriers: in practice, overlay widgets themselves collide with screen readers and create additional problems.

The evidence: studies and positions

The criticism of overlays comes not from competitors but from the accessibility community itself. The Overlay Fact Sheet, signed by hundreds of accessibility professionals, explicitly rejects these tools. Disability organisations – including the National Federation of the Blind in the US – have taken a clear stand against them. And in the US there have already been numerous lawsuits against operators whose sites were unusable despite an installed overlay.

For Germany this means: the BFSG's benchmark is the standard EN 301 549, which for the web points to WCAG 2.1 level AA. What is assessed is the actual state of your website – not the presence of a widget. An overlay does not substitute this conformance and therefore does not reliably protect against warning letters.

What a real audit delivers instead

A real audit examines the actually-rendered HTML – the way keyboard navigation or a screen reader experiences the page. The result is not a widget but a finding: a prioritised list of concrete violations, each with location, severity and a route to a fix. Remediation then happens in code, permanently and verifiably. That is precisely the difference between "looks accessible" and "is accessible".

An important clarification: diagnostic tools like my plugin Kipphard Accessibility Audit are not a contradiction to this – quite the opposite. They are honest checking tools that show you where action is needed, instead of automatically "covering up" problems. They don't replace remediation; they make it plannable in the first place.

Decision guide: which tool when

• Overlay widget: fine as an additional assistive control (e.g. a contrast or font-size toggle) – unsuitable as a substitute for compliance.
• Audit plugin: ideal for ongoing diagnosis and the accessibility statement, especially on WordPress.
• Manual audit + remediation: the only route to solid BFSG compliance, because only this fixes semantic and structural problems.

If you want to know where your website really stands – beyond marketing promises – I handle the BFSG audit and remediation. Get in touch and we'll look at your specific case.