Overlays & Accessibility • Broken Promises
There are tools on the market that promise to make a website accessible in a matter of minutes, by adding a small JavaScript snippet. A button appears, usually decorated with a wheelchair icon or a Vitruvian Man pictogram. The user can adjust text size, activate a high contrast mode, change line spacing. Done and dusted.
Except no. It is not done. It is far from done.
This type of tool, known as an accessibility overlay or accessibility menu, has spread rapidly in recent years as digital accessibility legal obligations have tightened across Europe. And with it, a commercial logic that deserves to be looked at squarely: selling a simple answer to a problem that is not simple.
What European authorities have said, plainly
This is not an isolated viewpoint. It reflects a convergence of institutional positions published by competent authorities at multiple levels of governance.
The European Commission has taken an unambiguous stance on its digital strategy website: overlays, or any other tool that does not ensure the website itself meets the detailed criteria of the EN 301 549 standard, are not an appropriate solution. The Commission recommends fixing accessibility issues at their source. It also notes that the European Disability Forum, affected users, and many accessibility experts have raised concerns about the use of these tools, a position that carries real weight coming from an institution known for cautious wording.
In Germany, the Federal Monitoring Body for Accessible Information Technology (BfIT-Bund) published in March 2025, together with all regional monitoring authorities, a joint assessment that leaves no room for doubt. Their conclusion is direct: currently, overlays are not capable of making a website with accessibility barriers fully accessible. They can even create new barriers, particularly by interfering with the assistive technologies, screen readers, magnification software, specialised keyboards, that people with disabilities already use across their entire device. The German authority is clear that accessibility must be built in from the design phase, not patched in after the fact by a third-party tool.
In Luxembourg, the Information and Press Service published in March 2025 an analysis based on real data from its 2024 audit campaign, covering 93 public websites. The findings speak for themselves: sites equipped with an accessibility menu scored an average compliance rate of 53%, compared to 63% for sites without one. Installing an accessibility menu correlates with a lower level of accessibility. And that correlation is not merely statistical: in many cases, the menu itself was the source of additional accessibility problems.
Three authorities, three levels of governance, one conclusion.
Why these tools cannot work
The question is worth reframing: why can a JavaScript snippet, however sophisticated, not fix a website's accessibility problems?
The answer is structural. Digital accessibility is not a visual layer you can apply over the top of an interface. It is a fundamental property of how content is built, structured, written, and delivered.
Alternative text for an image cannot really be generated automatically: an algorithm can describe what it sees in an image, but not why that image is there, or what it means in context. A coherent heading hierarchy, keyboard navigation logic, correct focus management, properly labelled form fields, none of these can be corrected by a script applied after the fact without risking the introduction of new problems.
And that is before considering that these tools only exist in the browser, on that specific website, for the duration of the visit. They do nothing for the confirmation email sent after a sign-up. They do not touch the downloadable PDF contract. They play no role in the push notification received on a mobile device. All of these steps, which form part of a user's real journey, remain inaccessible.
Can a script automatically fix a website's usability problems? No. Can it rewrite poorly worded content to make it understandable? No. Can it redesign the logic of a confusing form? No. So why would we expect it to solve accessibility problems that are, by their nature, just as deep as those questions?
The real problem: demand for easy answers to a complex subject
It would be unfair to point only at the sellers of these tools. The overlay market exists because it responds to a genuine demand: from organisations that have a legal accessibility obligation, know their website is not compliant, and are looking for a fast and affordable fix.
That demand is understandable. Genuinely bringing a digital service into compliance takes time, specialist expertise, and sometimes a deep overhaul of architecture and content. It is an investment.
But that context, buyers under legal pressure, unfamiliar with the technical issues, looking for a quick solution, is precisely the environment in which too-good-to-be-true promises thrive. A tool sold as a turnkey solution to a structural problem is an effective commercial proposition. It is not a serious answer to the problem.
The German authority puts it with useful precision: people with disabilities do not need an extra tool to configure on every website they visit. They already have their own tools, set up once on their device, that work everywhere. What they need is for websites to be correctly built to work with those tools.
The paradox of the inaccessible accessibility menu
There is a particular irony in the Luxembourg data. Among the recurring problems identified on sites with an accessibility menu, one of the most common relates to the high contrast mode: when that feature is activated, content becomes unreadable or disappears. The tool designed to improve accessibility degrades it instead.
The German and Luxembourg authorities both raise a further problem of basic logical consistency: the button that activates high contrast mode must itself be in high contrast. Otherwise, the person who needs that mode cannot find the button to enable it. This kind of problem is not a minor edge case. It illustrates why accessibility cannot be treated as an external add-on: it has to be thought through from the inside.
What this means for digital service buyers
If you are responsible for a digital service, an institutional website, or an application, and someone is offering you an accessibility overlay as a compliance solution, here is what the institutional positions cited above mean in practice.
First, an overlay does not bring you into legal compliance. The European Commission, Germany, and Luxembourg are clear: a site is only accessible if the site itself meets the standard's criteria. Not if a software layer temporarily masks its shortcomings.
Second, an overlay can make your situation worse. If the tool interacts poorly with assistive technologies, you risk excluding users who were previously able to navigate your site with their own tools.
Third, in the event of an inspection or complaint, an overlay will not constitute a sufficient defence. Supervisory authorities assess the compliance of the site itself.
The only approach that holds: build accessibility, don't simulate it
The authorities are unanimous in their recommendation: fix problems at the source, integrate accessibility from the design phase, audit real services rather than relying on automated tools.
That means auditing complete journeys, not just pages. It means accounting for all touchpoints: the website, the mobile application, emails, PDF documents, notifications. It means working with human experts, because accessibility cannot be fully automated, not by an overlay, not by any other tool.
An overlay can, at best, complement an already solid compliance process, by adding features that go beyond the basic legal requirements, such as visual customisation options for specific user profiles. But it cannot replace that process.
The European Commission summarises it in one clear sentence: it is best to fix accessibility issues at their source. It is also the least costly approach in the long run, and the only one that genuinely protects your users.
CheckFox take
Digital accessibility is a serious subject. It concerns millions of people who have a genuine need to access public and private services without barriers. The legal framework exists. The sanctions for non-compliance exist.
In that context, offering a script as a compliance solution is selling a reassuring answer to a hard question. Those who buy it think they have solved the problem. Those who actually need accessibility may not yet know they have not.
The encouraging development is that a growing number of competent authorities, the European Commission, Germany, Luxembourg, are publicly and precisely documenting why these tools are not sufficient. That expanding institutional record makes it increasingly difficult to claim ignorance of the problem.
Real accessibility is built. It is not installed.
Sources:
- European Commission, Digital Strategy, Web Accessibility section
- BfIT-Bund – Joint assessment on overlay tools, March 2025
- Luxembourg Information and Press Service – The Accessibility Menu, a Friend to Eschew?, March 2025
Put this into practice with CheckFox
CheckFox helps teams run WCAG, RGAA and RAWeb audits, gather visual evidence, and generate compliant reports and accessibility statements.