Plugins do not create accessibility, but new problems: an analysis

The deadline was at the end of June 2025: a large number of websites must now be accessible. Many agencies offer accessibility plugins based on certain tools that are supposed to make the website accessible with just one click. Sounds tempting: one click, one overlay, everything is legally compliant. But the reality is different. If you take a closer look, you will notice that these tools only solve a small part of the problems, but they create new ones.

This analysis summarizes the following findings:

• First things first: accessibility plugins are not able to make your website compliant with the technical requirements of WCAG.
• Accessibility plugins and overlays are problematic for PageSpeed and Core Web Vitals of your websites.
• These types of solutions create problems in technical SEO, which can ... and probably will ... put pressure on your rankings.
• The user experience of your website decreases as a result of slower websites, which means negative user signals for Google.
• The majority of people with disabilities reject accessibility overlays based on such plugins.
• The promised legal certainty is a bold statement that has already led to immense fines elsewhere.

Conclusion: Despite their tempting promises of quick solutions, accessibility plugins and overlays are no real help for people with disabilities and convey a false sense of security, which is ultimately paid for dearly (in addition to the monthly costs) with poorer performance and a lower user experience, which is not insignificant for SEO and rankings. Google wants to provide the best user experience for users. Google will no longer find this on pages with these plugins.

The illusion of instant accessibility

Now that the BFSG has come into force, web accessibility has evolved from a mere consideration to a fundamental necessity for companies with at least ten employees or 2 million turnover that offer electronic services on their website. To qualify as an electronic service, it is sufficient for a contact form to be placed to initiate business or make an appointment. As an accessibility agency, we also made the websites of a large number of clients accessible in May, June and now in July - at code level, not with plugins. It wasn't just about ethical inclusion. If we are honest, companies are primarily concerned with compliance with legal regulations. Without the new law, few customers would have opted for accessibility optimization. So much honesty is necessary. With companies under pressure to act before the threat of severe penalties, the allure of seemingly effortless "one line of code" solutions is incredibly strong: welcome to the Potemkin village of accessibility plugins and overlays that pose as solutions but essentially just mask existing barriers and create new problems in the process.

These tools are often presented as instant, fully automated and sometimes AI-powered solutions to web accessibility problems. They promise to deliver instant compliance and effortless inclusivity by providing a deceptive shortcut around the complexities of true accessibility. This marketing often uses buzzwords like "complete web accessibility solution" or "quick & easy , creating the impression of a magical solution.

For example, one provider's website presents the accessibility plugin, which is also marketed to customers via the Händlerbund: BSFG-compliant with one click.

Here is the landing page of the Händlerbund with the accessibility package, where the plugin itself is also conveniently used (see blue icon bottom left): "legally secure ... a technically barrier-free presence".

Brief classification: As a company, we have also been a Händlerbund customer since 2018 and appreciate the legal texts service and the services relating to legal certainty for companies, websites and stores. We have also referred some of our customers to Händlerbund ... out of conviction.

However, we would never use this plugin or similar accessibility overlays or install them for our customers. This report will demonstrate that these "quick & easy" solutions are not only inadequate, but actively harmful to SEO and PageSpeed, and also keep websites from actually solving real accessibility problems. Such comprehensive accessibility plugins, on the other hand, introduce a new set of problems that significantly impact website performance, provide no real legal protection, and ultimately hinder true inclusion for users with disabilities.

Real data from Deutsche See's online store will be used to illustrate exactly how these tools undermine their own stated purpose. The analysis will show why a deeper, code-based approach with further manual testing is the only sustainable, ethical and legally sound way to achieve comprehensive accessibility for websites.

The performance drop: an insight into PageSpeed data

When you visit the Deutsche See store as a user, you will find a small icon on the right-hand side of the screen to make the accessibility functions visible. They are already loaded, regardless of whether you see the control panel or not. Click on it and the panel will expand. Take a look at the blue scroll bar on the right ... there are lots of functions available to the user if they scroll further down in the control panel.

Understanding the Core Web Vitals (CWV): The foundation of the user experience

Google's Core Web Vitals (CWV) are a set of metrics that measure real-world user experience and directly influence search engine rankings and user engagement. These metrics include Largest Contentful Paint (LCP), which evaluates load performance; Interaction to Next Paint (INP) , which measures interactivity, and Cumulative Layout Shift (CLS), which quantifies visual stability.

Here is an evaluation from PageSpeed Insights for the store home page: Core Web Vitals are failing due to cumulative layout shifts. We were also plagued by CLS problems for several months, which we were only able to fix with great effort.

Achieving the lowest, i.e. best CWV values is essential for a fast, responsive and visually stable website, as this has an impact on user engagement and the visibility of your website in search results. Core Web Vitals are an official ranking factor for Google and were part of the Page Experience Update in 2021.

How accessibility plugins become performance bottlenecks

Accessibility overlays are typically implemented as third-party JavaScript files that are dynamically injected into a website's existing code. This "bolt-on" methodology, rather than proper integration in the code, inherently leads to significant scope and complexity. If you look at the functionality of such plugins, you can imagine how much of this code is injected.

These plugins introduce a significant amount of additional JavaScript and CSS that needs to be downloaded, parsed and executed by the browser before the page can be fully rendered. And in the Deutsche See example, we see that the code is already loaded before the icon is even clicked. The code is therefore already included in the first loading process. This is what the result of the PageSpeed test for mobile looks like:

Not only is the mobile PageSpeed particularly bad at 37, but significantly, Google also assigns only a moderate 72 to the website for accessibility.

On desktop, every website usually has a good PageSpeed value. Green is the standard, yellow is almost a rarity. But Deutsche See has made it. A tragedy. And the value for accessibility has dropped further.

The accessibility plugin adds "unnecessary layers" and creates cumbersome scripts and third-party dependencies, which directly contributes to increased loading times. The main browser thread is responsible for critical tasks such as parsing HTML, applying styles and executing JavaScript. Overlays often monopolize or block this main thread, significantly delaying the rendering of visible content and hindering user interactivity. The dynamic injection of numerous additional elements and styles can lead to excessive DOM size. This, combined with the large file sizes of plugin assets, results in huge network payloads, further exacerbating slow page load times, especially for users with slower connections or mobile devices.

In the list of recommendations to fix these issues in the PageSpeed Insights report, I've marked once with the blue icon where the diagnostic report actually references the scripts from the accessibility plugin directly by name as part of the problem.

The technical architecture of this accessibility overlay leads directly to a deterioration in performance with all the disadvantages for user experience and SEO. These types of overlays work by injecting large amounts of JavaScript and CSS into the existing structure of a website. This injection increases the total amount of data transferred (network payload) and adds numerous elements to the Document Object Model (DOM size). An additional problem is that these scripts also carry a lot of unnecessary code that should not or not yet be there.

Here is the evaluation when "Reduced unused CSS" and "Reduced unused JavaScript" are folded out.

The accessibility plugin loads a large JavaScript package (950 KiB) when the page is called up, even if the panel is not yet being used. The panel is only activated when you click on the blue icon. And only then do many of the functions really come into play. The better solution would be for a slim JavaScript to initialize only the icon. And only when clicked would the complete panel + functionality be loaded on demand

Here it looks different: In order for the browser to render the page when it is called up, it has to process and execute the newly injected, often unoptimized, third-party code of the accessibility plugin. This intensive processing leads directly to increased JavaScript execution time and a heavier load on the main thread. These are absolutely critical factors for the Core Web Vitals.

PageSpeed Insights has very poor performance values, with a negative effect that is also explicitly attributed to the accessibility plugin used. Is it only at deutschesee.de that it is so bad, but other customers solved it better? Let's take a look at a few other company websites that use the bfw plugin - from left to right: trelino.com, hb-marketplace.com (from Händlerbund), christopeit-sport.com and ottowildegrillers.com.

The values are consistently in the red zone. No website fulfills the Core Web Vitals. The plugin is not the only reason for these negative performance values. All of the websites examined also have other issues that stand in the way of optimal PageSpeed values. But with the overlay, the handbrake is additionally applied. The PageSpeed Insights diagnostic notes are a direct confirmation of the theoretical performance problems associated with accessibility overlays. This concrete data shows that these plugins are actively undermining a website's core performance metrics, leading to measurable negative impacts on user experience, SEO and potentially conversion rates.

I'm not questioning the basic functionality of the plugin to better capture content for people with disabilities, but

• ... the entire code (here: 1.2 MB just for the plugin ... the absolute performance killer) is still loaded completely before the user does anything.
• ... many users do not use the panel at all. The code is therefore unnecessary ballast.
• ... the LCP (Largest Contentful Paint) as an important metric for the Core Web Vitals suffers because the JS and CSS block or delay the rendering process.
• ... there is no lazy loading, no code splitting, no dynamic reloading.

In summary, the plugin looks like overkill from a technical point of view. It adds a lot of ballast without making it clear which real accessibility functions are actually used in a meaningful way.

How misleading in this context is the plugin provider's own advertising on its website with the supposed advantages of using the tool:

• Improved reach and SEO: accessible pages rank better.
• Better user experience: For all visitors - regardless of restrictions.

The performance loss due to the accessibility tool used is so massive that the user experience deteriorates noticeably - with foreseeable consequences for the rankings. We can only hope that the SEO managers at Deutsche See & Co. are not only looking for the cause in the currently much-discussed AI overviews, which have caused traffic losses on many websites since the roll-out, but also recognize the direct connection between technical overhead and loss of visibility.

The compliance dilemma: Why accessibility overlays fail at true inclusion

The limited scope of automatic corrections: a band-aid, not a cure

The promise of a "fully automated" accessibility solution is a dangerous misconception. Automated tools and overlays are inherently limited and can only detect a fraction of real accessibility issues.

These tools mainly focus on superficial changes, such as changing colors or adjusting text size. In any case, these are functions that users with disabilities often already control via their operating system or browser settings. Crucially, overlays can't fix the underlying structural issues embedded in a website's HTML, CSS and ARIA roles. They cannot effectively fix complex issues such as improper heading structures, missing or incorrect ARIA labels, or providing truly meaningful alternative text for images because they lack the human context and interpretive ability required to do so.

Overlays fix symptoms, not causes. True web accessibility is deeply rooted in the semantic structure and logical flow of a website's code, not just its visual presentation. Overlays inject a layer of code over the existing website by design, rather than modifying the core HTML, CSS and JavaScript. This means that they can make superficial changes (e.g. contrast adjustments), but cannot fix fundamental structural errors such as incorrect heading hierarchies, illogical reading order or dynamic content issues that require direct code adaptation.

Here is an evaluation of deutschesee.de by the on-page crawler SEOBILITY with a small excerpt of the anomalies:

How does the accessibility tool now solve the problems with the headings and the hierarchical structure? What effect does the plugin have on the missing alt attributes in the images? None of this is solved by the plugin, otherwise the crawler would not have detected these errors. Even worse: The plugin itself delivers an image without an alt attribute, as can be seen in the following screenshot, where PageSpeed Insights does not recognize any alt text for the popup image and the plugin logo for the store homepage.

This restriction means that they only "patch" visible symptoms, while leaving the vast majority of complex accessibility issues untreated. This creates a false sense of security and leads to what can be described as a compliance show. It is an appearance of compliance without real compliance.

No accessibility for integrated videos, iFrames or PDF files

Deutsche See writes it themselves in the accessibility statement, summarizing very well other areas where the accessibility plugin does not help.

Despite our efforts, the content listed below is not accessible:

• PDF documents: some of our PDF documents are not accessible. We will endeavor to provide an adapted version or accessible alternatives as soon as possible. If you require a specific PDF file from us that is not yet accessible, please let us know.
• Videos: Some of our embedded videos do not currently have subtitles. We will endeavor to add subtitles to all videos as soon as possible.
• Images without alternative text: Some images on the website do not have alternative text. We will endeavor to update them in a timely manner.
• iFrame: For technical reasons, parts of the content of our website are integrated via iFrame and are therefore not accessible without barriers.

Enough has already been said about the images without alt texts (see also above). The providers of booking platforms that provide iFrame or API-based booking widgets for websites for hotels, vacation apartments or boats must also take action to avoid causing problems for their customers.

Videos should have subtitles or transcriptions. This is always a problem if a video is not integrated via YouTube, for example, where subtitles can simply be activated.

PDFs should also be accessible, which is a problem if there are a lot of PDF files. We have also made the PDF files integrated on the website accessible for some customers. To be honest, the time required was more than expected. By the way, PDF files can be tested with this PDF accessibility checker.

Impairment of assistive technologies and user experience

A critical problem is that accessibility overlays often interfere with the assistive technologies (AT) they are supposed to support, such as screen readers, keyboard navigation tools and magnifiers.

Users with disabilities carefully configure their devices and AT to meet their specific needs. Overlays can override these personalized settings, forcing users to adapt to an unfamiliar system on every website. This leads to lousy user experience and ultimately makes websites more frustrating and less usable. The disability community has spoken out overwhelmingly against overlays. A WebAIM survey found that 72% of impaired users rated these tools as "not at all effective or not very effective"... and only 2.4% found them to be effective.

Overlays create new barriers for the users they are supposed to help. Screen readers are designed to interpret the underlying semantic structure of a web page (HTML elements, ARIA attributes) to convey information to users. Many websites that rely on overlay solutions do not have a clean semantic structure in the code itself. Important attributes such as aria-label are completely missing. And this is precisely where the problem lies: assistive technologies such as screen readers need this information to guide users through content.

If instead an overlay with JavaScript simply superimposes visual functions, nothing changes in the actual structure. Overlays often do not update this underlying semantic structure correctly or can even conflict with it by injecting JavaScript and making superficial visual changes.

The result is that a tool intended to improve accessibility paradoxically creates new, frustrating barriers for the very people who rely on AT, degrading their user experience instead of improving it. The end result is a deceptive interface that looks good but can destroy core assistive technology functionality.

The strong stance of the disability community

The disability community, along with a large majority of accessibility experts and assistive technology providers, has spoken out overwhelmingly and unequivocally against the use of accessibility overlays.

This collective opposition is significant: over 970 accessibility experts and people with disabilities - as of July 12, 2025 - have signed an open letter condemning their use.

Many users actively use ad blockers to prevent overlays from loading. This strong stance stems from the fact that overlays often create more barriers, disrupt existing, preferred assistive tools and can even raise serious privacy concerns by automatically recognizing and potentially logging the use of assistive technologies without the user's explicit consent.

Features that bloat the site but you don't need

If you look at the range of functions of the BFW plugin, it is impressive on the one hand what the developers have come up with to provide users with an improved view of the website. On the other hand, one may ask what is actually needed on the user side, because many functions such as text size changes, color contrasts, etc. are already provided by the browser (see, for example, the reading mode implemented in Chrome) or the screen readers.

The new code that is injected into the existing code structure through overlays not only slows down the page speed, but is also not adapted to the layout conditions of the website. Here is an example of the view when dyslexia mode is enabled. The product title is cut off for three products and there is also not enough space for the text in the green image anteasers for the highlights. What is supposed to be friendly for dyslexics makes it difficult to access the information.

The strong overbloat could have been avoided if every function had been seriously checked for meaningfulness.

There is also another conspicuous feature. This font, which is displayed when you click on the "Friendly for dyslexia" button, is called Open Dyslexic. It was originally developed to improve readability. So the hypothesis goes.

At Axe-Con 2021, the Readability Group presented its large typography study, in which it tested the effectiveness of 20 different fonts on 2022 participants. This included over 250 people with pronounced dyslexic characteristics. Axe-Con is an annual, international online conference that focuses exclusively on digital accessibility. The Readability Group is an independent research and consulting company specializing in readability, typography and accessible type design.

The aim of the typography study was to use real user data to find out which fonts are actually readable and which only carry the label "accessible". Each font was viewed over 16,000 times in around 7,000 hours of testing. This is the list of the 20 fonts, starting with the font with the highest approval rating.

• BBC Reith Sans 65%
• SF Pro 65% ... Apple developed SF Pro internally because Helvetica Neue looked too narrow on iPhones
• Verdana 64% ... I remember well, many websites 20 years ago had chosen this font. Verdana was specially designed for Microsoft for low-resolution monitors. The letters were made extra wide to appear clear even on CRT monitors.
• Segoe UI 62%
• Legend Decca 62%
• Atkinson 60%
• Red Hat Text 60%
• Roboto 57% ... a Google font. We already use it for some customer projects.
• FS Me 56%
• Calibri 55% ... Microsoft's standard font for a long time, after it replaced Times New Roman in 2007.
• BBC Reith Serif 54%
• Ubuntu 54% ... we also use this font here on our agency website. You are reading this line in this font.
• Helvetica 47% ... everybody's darling.
• Roboto Slab 47%
• Lexie Readable 44% ... specially developed for better readability for people with dyslexia
• Times New Roman 36%
• Sylexiad Sans 36% ... specially designed for better readability for people with dyslexia
• Dislexie 30% ... specially developed for better legibility for people with dyslexia
• Comic Sans 28% ... the ugliest font ever.
• Open Dyslexic 18% ... specially developed for better legibility for people with dyslexia

It is interesting to note that the worst performing fonts for the dyslexic group were precisely those that were "designed" in their favor. The dyslexia mode offers those affected the font with the lowest approval rating. In this case, too, the accessibility plugin is well-intentioned but misses the mark and is unnecessary.

What do the test tools say about accessibility at deutschesee.de?

The Accessibilitychecker.org audit for the deutschesee.de store provides objective data on the failure of plugins to deliver real accessibility. Despite loading an accessibility plugin, the website received an abysmal "Audit Score: 29%" and was explicitly marked as "NOT COMPLIANT" under "Germany law".



The audit also listed 117 critical problems for the tested store subpage alone and indicates that the website does not meet numerous WCAG criteria. It is significant that Accessibilitychecker.org does not even recognize the overlay as such in this case, which it does with other tools. The irony here is that the Händlerbund also fails with its Marketplace page, where the accessibility plugin is offered.

Nevertheless, a limited number of the problems mentioned are actually solved by the plugin, such as color contrasts, which are currently too weak. Other parts such as missing alt texts, missing ARIA labels such as the lack of accessible names of buttons are not solved by the plugin ... just the information that is elementary for visually impaired people when using screen readers.

The following table compares how overlays and code-level solutions handle the WCAG principles:

This table illustrates the fundamental differences in approach and effectiveness between overlays and code-level solutions.

Limited improvements are possible with plugins and overlays

If you are now wondering what percentage the plugins and overlays help on the way to compliance, you can calculate a rule of thumb of around 40% improvement.

Skynet Technologies has a mode that adds the plugin effect to the score. Here, too, a check can be carried out free of charge for a subpage. The result for Deutsche See is just under 57% and Semi Compliant status.

https://freeaccessibilitychecker.skynettechnologies.com/?website=deutschesee.de

The switcher at the top right is particularly interesting, where the use of the All in One Accessibility Tool offered by Skynet Technologies in the paid version simulates how many problems are solved with it. More than 200 issues can be resolved. The score increases by over 25 percentage points. However, it remains in Semi Compliant status.

Seductive or misleading marketing by providers?

Plugins for compliance are a marketing promise that should be treated with caution. The assumption of website operators is that the plugin ensures compliance with legal requirements. But apparently they do not. The bigger implication is that companies are not just buying and deploying a flawed technical solution, they are actively investing in a legal risk.

Accessibility overlays do not fulfill their primary advertised purpose of ensuring legal compliance. It confirms the widespread expert consensus that these tools provide a false sense of security and do not protect against non-compliance.

It is interesting to note the difference in communication when promoting accessibility plugins between established American providers, who have already been shown their limitations in a litigious environment, and the new gold diggers in the German market. Skynet Technologies or the provider AccessiBe, which was fined 1 million dollars, advertise their tool on their websites with statements such as:

• supports companies in optimizing for accessibility
• improves accessibility
• reduces legal risks

The only thing that can be done here with just a few clicks or in two minutes is the integration of the tool into the website, but not accessibility. And the providers are quite open about this.

The new German tool providers that are springing up like mushrooms, on the other hand, communicate in a differentiated manner. The BFW plugin makes a full-bodied promise:

• Whether website, store or portal - BFSG-compliant with one click
• With our highly compatible plugin solution, your website meets the legal requirements.
• Secure your legally compliant and accessible website with our plugin - quickly and easily.
• With our plugin, you avoid legal risks and improve the user experience for ALL visitors.
• With our plugin, you can integrate accessibility into your existing website in just a few minutes. Just two lines of code - immediately more inclusion and legal certainty.
• Legal certainty: Meets all requirements of WCAG 2.1 and BITV 2.0.
• Activate accessibility in just a few minutes.
• With our certified plugin, you can make your website accessible in just a few minutes - legally compliant, secure and without any programming effort.

I would like to know exactly what kind of certification the provider is talking about. I can't find any information about this.

The competitor AccessGo makes promises such as:

• ... you fulfill the legal requirements easily, quickly and stress-free.
• ... implement the requirements automatically and legally compliant - without any technical effort.

In the accessibility statements of the companies that actually use this tool, they backtrack. One example of this is the Eintracht Braunschweig website, which uses the AccessGo plugin. When you visit the website, you immediately encounter the first access barrier: the icon for the accessibility plugin is currently still covered by the cookie banner. In addition, the cookie banner is in English because it reacts to the browser language, even though I am on the German Eintracht site.

Unfortunately, cookie banners are all too often not readable for the screen reader, which is also directly criticized by the community of visually impaired people.

If you look at the website's accessibility statement, it says:

How accessible is the service?

The assessment is based on a self-assessment using the AccessGO accessibility tool.

Based on this review, the website is partially accessible with the aforementioned requirements.

In detail, the following points are not fully compliant with the accessibility regulations that apply to us:

Barrier: some buttons are empty or contain no descriptive text.
Barrier: Some links are empty or contain no text, making their destination or function unrecognizable.
Barrier: Some images are empty or contain no descriptive text.
We are currently planning to implement the removal of these barriers.

From a marketing point of view, AccessGo has done it cleverly. Companies committed to accessibility are promised quick and easy compliance with WCAG requirements. Legal certainty with just a few clicks. Agencies and/or companies opt for a tool, but in the end only semi-compliance is delivered. After installing the plugin, numerous problems remain, about which information is then provided in the accessibility statement. Is that enough to prevent fines or warnings? I honestly don't know. It remains to be seen.

The name of the company presented in the footer for the AccessGo tool was also a clever psychological choice: German Society for Accessibility.

You don't do it under that. It immediately brings to mind real bodies such as the German Society for International Cooperation or the German Society for Psychology or Nutrition, Palliative Medicine or other well-known societies where members exchange ideas and strive for social improvements in the interests of the topic. The only difference is that the German Society for Accessibility is not an association or a foundation, but a limited liability company that was only entered in the commercial register in March 2025.

At least 100 companies are already using the tool, lured by the promise of quick compliance with WCAG requirements and legal certainty - quick and easy accessibility, as it says at the bottom of the footer. As a company, you also want to use the right tool. Fortunately, the tool provider received the right top ratings on three portals in January 2025 - even before the company was founded - from three identical user names: Patrick, Laura and Anonymus.

This made it possible to advertise on the website with the reviews of the "customers" right from the start.

As an agency, we are honestly grateful when customers contribute a Google review. The fact that a customer gives their praise directly to three review platforms is the new gold standard for me from now on.

The BFW plugin, which is actively advertised by the Händlerbund, is really clumsy when it comes to testimonials.

The customers Thomas Klein and Anna Schubert praise it excessively. Of course. The names are so German and catchy, as if everyone had once had a person with this name in their class. Do they really exist? That remains questionable. Because the two testimonial actors are called Christa and John Smith on another website.

However, there are other uses of these images, which can be easily identified via Google Lens. Regardless of whether the image comes from a stock portal or from the AI, the images were probably already integrated as placeholders in the website template used.

A third German provider, whose tool claims to "automatically make your website accessiblewith just a few clicks", also uses this approach on its landing page:

The customer Leon is then called Markus on this other website and Ben, Will, David or perhaps Heinz in over 150 other online presences.

Legal risks: overlays do not protect against lawsuits

Agencies and companies rely on new providers to quickly and easily make their or their customers' websites legally compliant, supported by pithy promises of compliance with WCAG requirements, recommendations from reputable service providers such as the Händlerbund and supposed customer quotes whose origin is more than a mystery. Companies are prepared to accept annual costs for this, which is fine in itself if the return is right. Here, however, companies receive a solution that does not create compliance. And sooner or later this will be confirmed by the courts in Germany.

In the USA, it has long been clear that accessibility overlays offer no legal protection. The US Department of Justice clearly recommends compliance with the WCAG 2.1 AA guidelines as the minimum standard for ADA compliance (the American equivalent of our European EAA directive, to which the German BFSG refers). Despite this, many companies continue to rely on bogus technical solutions such as overlays. This has already had costly consequences. In 2023 alone, 24.5% of all ADA lawsuits involved websites that used just such plugins.

Court rulings such as Murphy v. Eyebobs or Quezada v. US Wings have shown that overlays are not a legal safeguard. In the meantime, class action lawsuits have even been filed directly against overlay providers: for example, in the case of accessiBe, which had to pay a fine in the millions due to misleading promises about the effectiveness of its tool. These promises were not dissimilar to those of the tools presented here.

What is happening in the USA today could be a harbinger for Europe. With the entry into force of the Accessibility Improvement Act (BFSG), similar liability risks are also coming within reach here in Germany. The BFSG itself provides for fines of up to 100,000 euros. Companies that rely on supposedly "quick" plugin solutions are not investing in accessibility, but in a legal risk: because the plugins feign conformity without meeting the actual requirements. And if the companies were honest, the investment in such plugins was never motivated by the desire for more inclusion, but solely to create legal certainty.

The result is a dangerous chain: misleading marketing → implementation of ineffective overlays → non-compliance with legal requirements → increased susceptibility to lawsuits → loss of image → potentially severe fines → reworking the optimization for accessibility via the correct code level approach and thus renewed costs.

Another scenario is also conceivable: AGG lawsuits due to insufficient accessibility. If you are a visually impaired person and cannot see or use a job advertisement on a company's website due to a lack of accessibility (e.g. lack of alternative texts, illegible PDFs or inaccessible form fields), this could constitute indirect discrimination on the grounds of disability. Anyone who can credibly demonstrate that they have been disadvantaged due to a lack of accessibility and that this has resulted in a disadvantage in the application process could be inclined to claim damages or compensation. Time and again, we read in the press about labor court proceedings in which some people have brought hundreds of complaints about disadvantages in the application process.

Relying solely on accessibility overlays makes companies vulnerable to lawsuits and legal consequences for non-compliance. What has already happened in the US in recent years is what I predict will happen in the EU and Germany.

The Händlerbund continues to diligently drum up support for the BFW plugin solution and asked its members directly in the subject line of its info newsletter on July 10: Accessibility: Who will be hit by the first warning? ⏳

It may be that I am making a mistake here overall and misjudging the situation here in Germany when it comes to implementing the WCAG requirements by simply transferring the legal risks that companies with overlays expose themselves to from the USA to us. I greatly appreciate the legal service provided by Händlerbund. We have been using it for years. And my lines here in this blog post are not legal advice, but simply my personal view, i.e. an opinion piece. It is therefore a real mystery to me how the Händlerbund sells a plugin to its tens of thousands of members as a legally compliant solution. A plugin will only correct around 40% of the problems. And it only really makes sense to solve problems with color contrasts if, for example, color adjustments are not possible due to the corporate design. But even then, a contrast switcher can simply be added on a code basis, which only loads the code to adjust the colors via CSS with a click. There are no problems with too much code, impact on page speed or other disadvantages.

The right way is therefore to create accessibility on a code-level basis - secured by test tools and manual tests.

Code-level accessibility: the gold standard for sustainable inclusion

Accessibility starts in the code, not in the plugin. It's about structuring HTML, CSS and JavaScript in such a way that content can be used by everyone, including users with screen readers or keyboard navigation. This is not a quick fix, but sustainable work.

Which speaks for code solutions:

• No loading delays. No bulky overlays, no flickering interfaces. Just a clean, fast basic framework.
• No third-party risks. No third-party scripts that block other tools or paralyze the store.
• Support from the community. People with assistive technologies rely on well thought-out accessibility anchored in the code.
• Less legal risk. Those who work accessibly in code meet real standards: WCAG, ADA, BFSG. No bogus solutions.
• Less expensive. Once it's in the code, there's no need for expensive improvements later on.

Built-in, not imposed: The foundation of true accessibility

Code-level accessibility means making fundamental, structural changes directly in the HTML, CSS and JavaScript of your website. This approach is the most reliable and sustainable way to achieve true web accessibility". By integrating accessibility directly into the core structure of the website, it is "built into the foundation of your website", ensuring that improvements are permanent, robust and integral, rather than temporary patches.

In stark contrast to overlays, code-level changes result in no additional load time, no flickering interface and no unnecessary clutter. This approach inherently keeps the website lean, fast and under your control. By eliminating the need for external, third-party dependencies and avoiding unnecessary layers, code-based solutions remove the risk of errors, conflicts with other tools or unexpected website malfunctions.

Code-level accessibility is a performance accelerator, not a hindrance. Nothing has to be activated first, which may be hidden by a cookie banner. It's there from the start. Good code-level accessibility practices inherently involve optimizing HTML, CSS and JavaScript, ensuring efficient loading and minimizing unnecessary code bloat. These practices lead directly to smaller file sizes, less main thread work, and faster rendering times, which are the core components of strong core web vitals.

Many improvements driven by accessibility, such as logical navigation, readable text and responsive design, inherently benefit all users, not just those with disabilities. This universal design approach leads to an improved overall user experience and actually contributes positively to SEO.

The process is relatively simple. A full scan of all websites is carried out in advance using a professional tool. We use accessibilitychecker.org, for example. Our customer websites are checked in WCAG 2.2 mode with additional best practice requirements from the community. The issues listed result in a score. The problems are rectified on the code side and the implementation is checked technically in further scans. Here is an example of the before and after score of a hospital website.

As the test tools cannot detect all barriers, additional manual tests must also be carried out.

Significantly, the disability community, including those who rely on assistive technologies, overwhelmingly favors "code-level accessibility" as it guarantees seamless and reliable interaction with their existing tools without glitches.

Because code-level fixes address accessibility barriers at their source, they are more likely to meet legal compliance standards such as WCAG. This proactive, ground-up approach reduces the risk of lawsuits or complaints and demonstrates a real investment in making websites truly inclusive, providing more robust legal protection than overlays.

Leaner code also means a smaller carbon footprint. By nature, accessible websites tend to be leaner, faster and more efficient, which directly contributes to lower energy consumption across devices and networks.

Cost comparison: Code-level accessibility vs. accessibility plugin/overlay

Accessibility is not an add-on. It belongs in the foundation. If you rely on plugins, you may save money at first glance, but you will pay for it several times over in the long term. We have already dealt with the costs of accessibility in a separate blog post. It is worth comparing the costs of code-level accessibility, as we implement it as an accessibility agency, and the use of plugins.

Plugins: start cheap, end expensive

The monthly costs of the tool providers are similar. For example, the BFW plugin costs between €29 and €59 per month, plus a one-off setup fee of around €299 if the two lines of code cannot be integrated by the customer. Sounds manageable. But what is the price really?

• Technically, it's not a real solution: the plugin only overlays, leaving a large number of barriers in the code.
• Poor PageSpeed values: External scripts slow down loading times, which has a negative impact on SEO & user experience.
• No legal certainty: The requirements of the BFSG or the EAA are generally not met by overlays.
• Dependence on the tool provider: You rent a solution. As soon as you cancel, the "protection" is gone.

Code-level accessibility: right once and permanently effective

Our own work for our customer websites shows this: With just 3-20 hours of work, many websites can be made technically clean, accessible and legally compliant. At an hourly rate of €120 net, our experience shows that this amounts to

• One-pager: 360-840 € net
• Corporate website: 720-1,800 € net
• Online store: €1,200-2,400 net

This includes: the technical adaptations, the accessibility declaration and, if necessary, content in plain language - including audit and proof of 100% WCAG compliance via tool certificate.

While the initial implementation of code-level accessibility may require more effort and investment, it reduces the need for ongoing patchwork solutions, reliance on external tools or costly legal responses. A proactive model avoids the additional expense and reduces the need to rework or restructure end products.

Conclusion: investment instead of rent, security instead of a sham solution

If you make your site accessible in the code, you invest in the substance - and benefit:

• better SEO values
• faster loading times
• positive user signals
• greater legal certainty
• no ongoing plugin costs

Tip: Some agencies charge €2,500 for an audit alone. With us, you get it for free. We'll tell you honestly what needs to be done ... and implement it if you want. Fair. Transparent. With real results.

Code-level accessibility is a strategic business investment, not just a compliance expense. The perceived higher initial cost of code-level accessibility is often cited as an obstacle ... even accessibility statements occasionally state that it is economically unreasonable. In our view, this is not entirely comprehensible. It is more of a protective claim. Podcast episodes should not be transcribable? AI now does that automatically. Videos without subtitles? These can also be created via AI and assigned to the videos, unless the videos are loaded via YouTube anyway, where subtitles can be activated with a click. Old texts cannot be reworked? Excuse. Code-side adjustments are too costly? Definitely not, as we have proven dozens of times in various CMS and store systems.

If you want your site to work for everyone - then do it right. Do it in the code. We help you to make your website accessible.

Conclusion: Building a truly accessible and high-performance website

Accessibility plugins and overlays, despite their tantalizing promises of quick fixes, are a false sense of security. An overlay can improve compliance with some provisions in key accessibility standards. However, full compliance with WCAG standards cannot be achieved with an overlay alone. The German plugin providers advertise that accessibility can be achieved with just a few clicks, but then we read in their customers' accessibility statements what is not possible.

As the example with deutschesee.de shows, these overlays significantly impair website performance with negative consequences for user experience and SEO. Contrary to their purpose, they do not fulfill the actual WCAG requirements, but instead continue to expose companies to legal risks. Ultimately, they frustrate users with disabilities and in some cases continue to actively exclude them.

This code-level approach is a permanent, scalable and real solution that provides a superior user experience for all visitors, improves SEO, strengthens legal position and even contributes positively to environmental sustainability.

Accessibility is an ongoing process, not a one-off product installation. Automated overlay tools are insufficient for achieving true accessibility. This also means that a "set it and forget it" approach, which is often associated with plugins, is fundamentally flawed. Instead, accessibility requires a continuous process that integrates human knowledge (e.g. in content maintenance), regular audits and monitoring. This shifts the paradigm from viewing accessibility as a product that must be purchased to an embedded process within the organization where inclusion is actually considered.