Accessibility Overlays: Why They Fail BFSG Compliance

An accessibility overlay is a JavaScript widget loaded via an embedded script. After the page has rendered in the browser, the script intervenes in the document object model (DOM) and displays a control bar, usually a round icon at the edge of the screen. The timing is decisive: the overlay works exclusively client-side, after loading, and does not change the underlying HTML templates. The source code that search engines, assistive technologies and inspection bodies see remains unchanged.

Functionally, two building blocks can be distinguished. The first is a toolbar with display options: enlarge font, increase line spacing, adjust contrast, start a read-aloud mode. These are preferences that modern operating systems and browsers already provide to many users. The second building block consists of automated repair attempts: the script tries to add missing alt text or retrofit ARIA attributes. This part in particular raises the expectation that the widget can fix structural defects, and this is exactly where the largest gap between claim and effect lies.

The marketing of overlays follows a recurring pattern: accessibility is presented as a matter of minutes, handled by embedding a script. Anyone familiar with the success criteria of WCAG 2.2 quickly recognizes that these assurances gloss over the complexity of the requirements. The following claims appear especially often in offers.

There is a gap between marketing and evidence. In the WebAIM Survey of Web Accessibility Practitioners, 67 percent (WebAIM) of participants rated overlay tools as hardly or not effective. Among respondents with their own disability, the verdict was even clearer: 72 percent (WebAIM) considered the tools hardly or not effective, and only 2.4 percent (WebAIM) rated them very effective. Precisely the group whose access overlays are meant to improve is therefore especially critical.

The reason lies in the automated testing technology that overlays build on. According to the W3C and its Web Accessibility Initiative, automated methods cover only 30 to 40 percent (W3C/WAI) of WCAG criteria. The WebAIM Million report, which annually analyzes the home pages of the one million most visited websites, found an average of 56.8 (WebAIM Million, 2024) automatically detectable errors per page in its 2024 edition; low text contrast appeared on 81 percent (WebAIM Million, 2024) of pages. These figures show two things: how widespread barriers are and how limited a purely automated approach remains. The interplay of automated and manual testing cannot be replaced by any widget.

The German Federation of the Blind and Partially Sighted (DBSV) has published a detailed position. Its core statement: according to the current state of technology, accessibility overlays are not able to make a website accessible from the outside at the push of a button (DBSV). The association names concrete problems in the daily life of people who rely on assistive technology: the keyboard commands of many overlays are not coordinated with the commands of common assistive technologies, leading to conflicts. With modally displayed overlay interfaces, the widget controls and the page elements mix together, which complicates screen reader use. Some tools also allow color combinations that make the keyboard and mouse focus invisible (DBSV).

State bodies take a clear position as well. In a joint assessment by the federal and state monitoring bodies on the use of overlay tools, the authorities state that a non-accessible offering does not automatically meet the legal requirements through an overlay (Federal Agency for Accessibility). Using an overlay and assistive technology at the same time can even lead to negative interactions and a deterioration of accessibility. The central statement: a website is accessible only if it meets the requirements even without an overlay tool (Federal Agency for Accessibility).

The BFSG requires the service itself to be accessible. The technical foundation is the harmonized standard EN 301 549, which references the WCAG for web content (EN 301 549). By this logic, an overlay is not a substitute for conformance but an additional layer over an unchanged foundation. Anyone who wants to meet the requirements of the BFSG cannot avoid implementation in the source code. On top of this come further obligations such as an accessibility statement and a working feedback mechanism, which a widget does not provide. How a procedure unfolds in an emergency is described in our article on how the BFSG is enforced.

A common misconception is the idea that a vendor badge or an automatically generated conformity certificate protects against complaints. In an inspection, market surveillance asks for proof, not advertising claims. A seal generated by the overlay vendor is not a robust proof of conformance. Even where relief applies, such as under the exemption for microenterprises, an overlay replaces neither structural accessibility nor documentation.

Accessibility is not an effect that can be laid over a page after the fact, but a property built into its components. It arises in four places: in the markup, in the design system, in the interaction logic and in editing. A script that intervenes after loading cannot permanently replace any of these places. Accessible implementation starts exactly here.

The editorial dimension in particular is underestimated. Whether an alt text captures the purpose of an image in its context, whether a link text is understandable outside its sentence, whether a color contrast in the layout truly suffices: these are judgments that require an understanding of content. How strongly color contrasts already determine readability is shown in practice every day. Those who train teams specifically anchor accessibility permanently in the workflow; our editorial and development training conveys the necessary routines. The same logic applies beyond the website, for example to accessible apps, whose accessibility is likewise built in the native code.

The following comparison summarizes the key differences. It places the overlay widget and structural implementation along the criteria that matter for BFSG conformance and for the real user experience.

Does an overlay have no place at all? The DBSV sees a possible added value: as a supplement on a page that is already independently accessible, for example for individual personalization. As a replacement for the foundation, it is not suitable. Those who want to maintain the level achieved combine structural implementation sensibly with ongoing BFSG monitoring that detects new barriers early.

Instead of embedding a widget that hides the symptoms, it is worth looking at the causes. A WCAG 2.2 audit combines automated scans with manual expert and screen reader tests and delivers a prioritized action list as its result. Each finding is mapped to a success criterion and paired with a concrete solution proposal. This makes accessibility plannable and provable, instead of outsourcing it to an external black box.

The audit also provides the basis for the accessibility statement that the BFSG requires. If the scope is unclear, a short conversation helps find the right fit; our team is reachable via the contact page. The effort pays off: a structurally accessible page improves the user experience for everyone, is legally provable and remains independent of an external script.