Accessibility overlays: why widgets fail under BFSG

Since 28 June 2025, the German Accessibility Strengthening Act (BFSG) has required many online shops and service providers to make their digital offerings accessible. At the same time, overlay widgets promise a quick fix via a code snippet: drop in a small script and you are done. That is exactly where the risk lies. Overlays usually do not resolve the underlying barriers and can even increase the BFSG risk. This article explains why genuine accessibility has to be built into the code and when a widget becomes a trap.

The promise sounds tempting: one line of JavaScript, and the compliance topic is ticked off. For many people in charge who came under pressure shortly before or after the deadline, it looks like a saving grace. In reality, however, an overlay only shifts the problem and, in the worst case, makes it bigger. Anyone who wants to meet the BFSG requirements in the long term cannot avoid looking at the actual source code. It is there, in the structural makeup of the page, that it is decided whether an offering is usable for everyone.

What overlay widgets promise and what they actually do

An accessibility overlay is a JavaScript script placed as an additional layer on top of your existing website. Clicking a floating icon opens a menu with options such as larger text, contrast switching or a read-aloud function. The marketing message is usually: one line of code and your site is compliant.

The decisive point, however, is this: an overlay does not change your page's source code. Missing alternative text, an inadequate heading structure, unlabelled form fields or poor keyboard operability all remain in the HTML. The widget merely adds a cosmetic layer on top. Accessibility widgets are therefore widely regarded as complementary tools, not replacements for code-level remediation (Wikipedia/Web accessibility).

There is also a technical hurdle that is often overlooked: an overlay only takes effect after the page has loaded and the script has run. Assistive technologies, however, frequently begin interpreting the document earlier. What the screen reader encounters at that moment is the unchanged, non-accessible HTML. If the overlay then tries to rewrite content after the fact, the worst case is a moving target that assistive technology cannot reliably follow.

The commercial incentive behind many overlay offerings is worth a look too. They are often sold as a subscription, with the promise of immediate compliance without touching the existing site. That promise is tempting, especially under time pressure. But recurring fees for a tool that does not remove the actual barriers are usually less sustainable than a one-off, clean implementation in the code that lasts.

Why overlays can create new barriers

The interaction with assistive technology is particularly critical. Many blind and visually impaired people use a screen reader that is already deeply integrated into the operating system and browser. An overlay that adds its own read-aloud or navigation features in parallel can clash with the screen reader and create new obstacles rather than removing existing ones (audatis). The result is paradoxical: a tool meant to remove barriers sometimes erects new ones. This can be especially frustrating for experienced users who have configured their assistive technology over years.

The scepticism is well documented. The Overlay Fact Sheet is a statement signed by around 800 accessibility professionals, including contributors to the WCAG, ARIA and HTML specifications (Overlay Fact Sheet). The signatories commit not to recommend an overlay that falsely presents itself as automated compliance with legal requirements. The National Federation of the Blind has also condemned overlays as an inadequate solution (Wikipedia/AccessiBe).

How seriously the situation is taken is shown by a legal development: in 2024, a class action was filed against a well-known overlay provider, alleging that several marketing claims were exaggerated and that the widgets did not ensure compliance, in some cases even making use harder (Wikipedia/UserWay). For operators this is a warning sign: anyone who relies on a tool's compliance promise ultimately bears the responsibility for actual accessibility themselves.

An overlay cannot put a website into a state that the underlying code does not support. It masks symptoms but does not fix the cause.

Consensus of the accessibility community (Overlay Fact Sheet)

• Duplicate controls: widget functions overlay native screen reader commands and cause confusion.
• Wrong or automatic labels: machine-generated alt text is often inaccurate and can misrepresent content.
• Focus traps: the floating menu can interrupt keyboard navigation.
• Performance overhead: an extra script slows down page rendering and affects load times.

The data: accessibility is still the exception

The WebAIM Million report 2025 analyses the home pages of the one million most-visited websites every year. The result is sobering: 94.8% (WebAIM Million 2025) of these home pages contain detectable WCAG 2 A/AA failures, only a marginal improvement on 95.9% in 2024 (WebAIM Million 2025).

On average, testers found 51 errors per page (WebAIM Million 2025). Notably, just six recurring error types account for around 96% (WebAIM Million 2025) of all issues. By far the most common is insufficient text contrast, present on 79.1% (WebAIM Million 2025) of the home pages analysed. These very errors live in CSS and HTML and cannot be reliably fixed by an overlay, but they can be addressed through clean implementation in the code.

These figures are not an argument against technical aids as such, but they are an argument against the idea that a generic script could automatically resolve the diversity of real barriers. The most common error types, such as low contrast or missing image descriptions, arise in the design and the markup. They can be fixed precisely where they originate, rather than through a downstream layer that leaves the original untouched.

Who is affected by the BFSG

The BFSG transposes the European directive on accessibility requirements for products and services into German law. Since 28 June 2025, those affected include providers in electronic commerce, that is, typical online shops, as well as other services aimed at end customers. For many operators this means: the entire purchase journey, from the product listing through the detail page to checkout, has to be accessible.

There are exceptions, for example for micro-enterprises that provide services and fall below certain thresholds for employees and turnover. This classification has to be checked case by case, however, and does not automatically exempt a business from every requirement. Anyone unsure whether their offering falls within scope should clarify this early, rather than relying on an overlay as supposed protection.

• Online shops selling to consumers
• Services in electronic commerce aimed at end customers
• Booking and appointment systems as well as self-service portals
• Certain products with a digital component, such as user interfaces

The legal risk under the BFSG

The BFSG is based on the requirements of the harmonised European standard and therefore on the WCAG. What matters is the actual perceivability, operability, understandability and robustness of your offering, not the presence of a widget. Relying on an overlay alone usually fails to meet the structural requirements (germanupa).

Violations carry tangible consequences. The market surveillance authority can request information and order the requirements to be implemented within a deadline. Under the act's penalty provisions, fines of up to 10,000 euros and, in certain cases, up to 100,000 euros can be imposed (Section 37 BFSG). In the most extreme case, the offering can be prohibited. On top of this comes the risk of warning letters under competition law.

Evidence matters. An overlay usually provides no robust proof that the individual WCAG success criteria are actually met. A structured implementation in the code, by contrast, can be documented, for example through test reports, a traceable component structure and reproducible tests. This documentation is helpful not only for a possible review by the authority but also for the ongoing development of the site.

Common myths about overlays

A few assumptions persist around overlay widgets that rarely hold up to closer scrutiny. It is worth addressing them openly, because they influence the decisions of many operators under time pressure.

Myth 1: an overlay makes the site compliant overnight. In reality the underlying code stays unchanged. The structural requirements of the WCAG are usually not met, and no robust proof is created.

Myth 2: users with disabilities prefer overlay functions. Many of those affected use their own, finely configured assistive technology. An additional, parallel layer of controls can disrupt rather than support it. Professional associations have described overlays as inadequate (Wikipedia/AccessiBe).

Myth 3: an overlay is cheaper than implementation in the code. At first glance yes, but the recurring subscription fees and the persisting legal risk put that advantage into perspective. A one-off, clean implementation has lasting effect and does not need to be paid for every month.

From overlay to a solid solution

Anyone already using an overlay is not facing a disaster but a clear next step. The path leads from the layer placed on top to a solution anchored in the code, ideally in several manageable stages. It is important not to lose the existing content along the way: text, images and features are preserved, they are simply prepared so that assistive technology can process them correctly. The result is not a break in the presentation but a step-by-step improvement of the substance.

1. Current-state analysis: a combined review of automated tools and manual tests reveals which barriers actually exist.
2. Prioritisation: the most common and most serious problems, such as contrast, missing labels and focus traps, are fixed first.
3. Implementation in code: the corrections are made directly in templates and components, so they take effect across all affected pages.
4. Testing and documentation: the accessibility achieved is documented traceably and cross-checked with assistive technology.
5. Retire the overlay: once the substance is sound, the additional script layer can be dropped, including its ongoing costs.

This sequence combines well with projects you are planning anyway. A website or shop relaunch is a natural moment to build in accessibility from the start, rather than adding it later.

How real accessibility is built into the code

Sustainable accessibility starts in the markup and the design. Instead of a layer placed on top, the content itself is structured so that it is accessible to all user groups and assistive technologies. This is the foundation of our accessibility optimisation and is part of every development project.

These principles apply regardless of the system. Whether a custom Shopware shop, a WordPress website or a bespoke application: accessibility is built into the components, tested and documented. A well-considered fair checkout process benefits from this just as much as low-barrier features such as an easy-to-use wishlist in the shop.

In practice, a clean implementation starts with an inventory. Where are the barriers, which templates and components are affected, and which success criteria are especially critical? From this analysis comes a prioritised plan that first addresses the most common and most consequential problems, such as contrast and alternative text, and then turns to the more complex interactive elements.

• Review and correct heading hierarchy and landmarks
• Make all controls reachable by keyboard, with a visible focus
• Label form fields clearly and make error messages accessible
• Test colour contrast against the WCAG 2.1 AA thresholds
• Add meaningful alternative text for images and graphics
• Carry out manual tests with keyboard and screen reader

A recurring benefit of this approach is maintainability. Because accessibility lives in the components themselves, new pages and future features automatically benefit from it too. No parallel system is created that has to be maintained and paid for; instead a standard emerges that is part of normal development.

Accessibility contributes to business success

Treating accessibility purely as an obligation falls short. A significant share of the population lives with permanent or temporary impairments, for example of sight, hearing or motor skills. On top of this come situational limitations: bright sunlight on a smartphone display, a noisy environment without headphones, or a hand that is busy with something else. An accessible site benefits all of these people, not just a small group.

Excluding these user groups gives away reach and revenue. A clear structure, good contrast and well-considered operability improve the user experience for all visitors and can have a positive effect on dwell time, completion rates and return visits. The very characteristics that make a site accessible are often the same ones that also support conversion optimisation and technical quality.

Accessibility as a sustainable investment

Accessibility is more than meeting an obligation. An accessible site reaches more people, improves usability for everyone and often has a positive effect on search engine optimisation and conversion, because clear structure and good operability help all visitors. An overlay buys short-term reassurance but provides neither the legal proof nor genuine accessibility.

Anyone taking the BFSG seriously therefore invests in substance rather than facade. A structured implementation in the code creates a robust foundation that holds up even as complexity grows and future extensions are added. What matters is that this work is done systematically rather than in isolated spots: once implemented cleanly in the templates, it takes effect on every page that uses those templates.