Plugins schaffen keine Barrierefreiheit, sondern neue Probleme: eine Analyse

Der Stichtag war Ende Juni 2025 da: eine Vielzahl von Websites müssen nun barrierefrei sein. Viele Agenturen bieten Barrierefreiheit per Plugin an, die auf bestimmten Tools basieren, die die Website quasi mit einem Klick barrierefrei machen sollen. Klingt verlockend: ein Klick, ein Overlay, alles ist gesetzeskonform. Aber die Realität sieht anders aus. Wer genauer hinsieht, merkt: Diese Tools lösen nur einen geringen Teil der Probleme, sie schaffen dafür aber neue. 

Diese Analyse enthält zusammengefasst folgende Ergebnisse:

• Das wichtigste zu erst: Barrierefreiheit-Plugins sind nicht in der Lage, deine Website nach technischen Anforderungen der WCAG compliant zu machen. 
• Plugins und Overlays für Barrierefreiheit sind problematisch für PageSpeed und Core Web Vitals deiner Websites.
• Diese Art von Lösungen schaffen Probleme im Technical SEO, was deine Rankings unter Druck setzen kann … und wohl auch wird.
• Die User Experience deiner Website sinkt in Folge langsamerer Websites, was negative User-Signale für Google bedeuten. 
• Menschen mit Behinderung lehnen mehrheitlich Barrierefreiheit-Overlays auf Basis solcher Plugins ab.
• Die versprochene Rechtssicherheit ist eine gewagte Aussage, die an anderer Stelle bereits zu immensen Strafzahlungen geführt hat.

Fazit:  Barrierefreiheits-Plugins und Overlays sind trotz ihrer verlockenden Versprechen von schnellen Lösungen keine echte Hilfe für Menschen mit Beeinträchtigung und vermitteln ein falsches Gefühl der Sicherheit, welches letztlich teuer bezahlt (neben den monatlichen Kosten) wird mit schlechterer Performance und niedrigerer User Experience, was nicht unerheblich ist für SEO und Rankings. Google will für Nutzer das beste Nutzungserlebnis ermöglichen. Das wird Google bei Seiten mit diesen Plugins nicht mehr finden. 

Die Illusion der Sofort-Barrierefreiheit

Spätestens jetzt mit dem Inkrafttreten des BFSG hat sich die Web-Barrierefreiheit von einer bloßen Überlegung zu einer grundlegenden Notwendigkeit für Unternehmen mit mindestens zehn Mitarbeitern oder 2 Mio Umsatz entwickelt, die elektronische Dienstleistungen auf ihrer Website anbieten. Um sich zur elektronischen Dienstleistung zu qualifizieren, reicht es schon, dass ein Kontaktformular zur Geschäftsanbahnung oder Terminvereinbarung platziert ist. Auch wir als Agentur für Barrierefreiheit haben im Mai,Juni und auch jetzt im Juli die Websites einer Vielzahl von Kunden barrierefrei gemacht, auf Codeebene, nicht mit Plugins. Es ging nicht allein um ethische Inklusion. Wenn wir ehrlich sind, geht es Unternehmen vor allem um die Einhaltung gesetzlicher Vorschriften. Ohne das neue Gesetz hätten sich wohl eher wenige Kunden für die Optimierung zur Barrierefreiheit entschieden. So viel Ehrlichkeit muss sein. Da Unternehmen im Zugzwang sind, bevor empfindliche Strafen drohen, ist der Reiz scheinbar müheloser „Ein-Zeilen-Code“-Lösungen unglaublich stark: Willkommen im potemkinschen Dorf der Barrierefreiheits-Plugins und Overlays, die sich als Lösung darstellen, aber im Wesentlichen nur bestehende Barrieren kaschieren und dabei neue Probleme schaffen.

Diese Tools werden häufig als sofortige, vollautomatische und manchmal auch KI-gestützte Lösungen für Web-Barrierefreiheitsprobleme präsentiert. Sie versprechen, sofortige Konformität und mühelose Inklusivität zu liefern, indem sie eine trügerische Abkürzung um die Komplexität echter Barrierefreiheit bieten. Dieses Marketing verwendet oft Schlagworte wie „Komplettlösung für Web-Barrierefreiheit“ oder „schnell & einfach , wodurch der Eindruck einer magischen Lösung entsteht.  

So präsentiert etwa die Website eines Anbieters das Barrierefreiheit-Plugin, welches auch über den Händlerbund an die Kunden vermittelt wird: BSFG-konform mit einem Klick.

Hier ist die Landingpage vom Händlerbund mit dem Barrierefreiheit-Paket, wo praktischerweise auch das Plugin selbst genutzt wird (siehe blaues Icon links unten): „rechtlich abgesichert … eine technisch barrierefreie Präsenz“.

Kurze Einordnung: Auch wir als Unternehmen sind Kunde beim Händlerbund seit 2018 und schätzen den Rechtstexte-Service und die Leistungen rund um Rechtssicherheit für Unternehmen, Websites und Shops. Ebenso haben wir einige unserer Kunden an den Händlerbund vermittelt … aus Überzeugung. 

Dieses Plugin oder gleichgelagerte Overlays für Barrierefreiheit würden wir aber niemals einsetzen oder bei unseren Kunden installieren. Dieser Bericht wird darlegen, dass diese „Schnell & einfach“-Lösungen nicht nur unzureichend, sondern aktiv schädlich sind für SEO und PageSpeed und die Websites auch davon entfernt halten, echte Barrierefreiheitsprobleme tatsächlich zu lösen. Derartig umfassende Plugins für Barrierefreiheit führen hingegen eine neue Reihe von Problemen ein, die die Website-Performance erheblich beeinträchtigen, keinen echten Rechtsschutz bieten und letztendlich die wahre Inklusion für Nutzer mit Behinderungen behindern. 

Es werden reale Daten des Online-Shops von Deutsche See herangezogen, um genau zu veranschaulichen, wie diese Tools ihren eigenen erklärten Zweck untergraben. Die Analyse wird zeigen, warum ein tieferer, Code-basierter Ansatz mit weiteren manuellen Tests der einzig nachhaltige, ethische und rechtlich fundierte Weg ist, um umfassende Barrierefreiheit für Websites zu erreichen.

Der Performance-Abfall: Ein Einblick in PageSpeed-Daten

Wenn du als Nutzer auf den Shop von Deutsche See kommst, findest du rechts im Bild ein kleines Icon, um die Barrierefreiheitsfunktionen sichtbar zu machen. Geladen sind sie bereits, ganz gleich, ob du das Bedienfeld siehst oder nicht. Du klickst rauf und das Panel wird ausgeklappt. Schau mal rechts auf den blauen Scrollbalken … jede Menge Funktionen bieten sich dem Nutzer, wenn er im Bedienfeld weiter nach unten scrollt. 

Das Verständnis der Core Web Vitals (CWV): Die Grundlage der Benutzererfahrung

Googles Core Web Vitals (CWV) sind eine Reihe von Metriken, die die reale Benutzererfahrung messen und Suchmaschinenrankings sowie die Nutzerbindung direkt beeinflussen. Diese Metriken umfassen Largest Contentful Paint (LCP), das die Ladeleistung bewertet; Interaction to Next Paint (INP) , das die Interaktivität misst, und Cumulative Layout Shift (CLS), das die visuelle Stabilität quantifiziert. 

Hier ist eine Auswertung von PageSpeed Insights für die Shop-Startseite: Core Web Vitals sind nicht bestanden wegen kumulativer Layoutshifts. Auch uns plagten einige Monate CLS-Probleme, die wir nur mit großem Aufwand fixen konnten. 

Das Erreichen niedrigster, also bester CWV-Werte ist elementar für eine schnelle, reaktionsschnelle und visuell stabile Website, da dies Einfluss hat auf Nutzerbindung und  Sichtbarkeit deiner Website in den Suchergebnissen. Die Core Web Vitals sind ein offizieller Rankingfaktor für Google und waren Teil des Page Experience Updates im Jahr 2021 gewesen.

Wie Barrierefreiheits-Plugins zu Performance-Engpässen werden

Barrierefreiheits-Overlays werden typischerweise als Third-Party-JavaScript-Dateien implementiert, die dynamisch in den bestehenden Code einer Website injiziert werden. Diese „aufgesetzte“ Methodik, anstatt einer richtigen Integration im Code, führt von Natur aus zu erheblichem Umfang und Komplexität. Schaust du dir die Funktionsumfalt derartiger Plugins einmal an, kannst du dir vorstellen, wie viel von diesem Code injiziert wird. 

Diese Plugins führen eine beträchtliche Menge an zusätzlichem JavaScript und CSS ein, die vom Browser heruntergeladen, geparst und ausgeführt werden muss, bevor die Seite vollständig gerendert werden kann. Und im Beispiel von Deutsche See sehen wir, dass der Code bereits geladen wird, bevor überhaupt das Icon betätigt wird. Der Code ist also bereits beim ersten Ladevorgang dabei. Uns so sieht dann das Ergebnis vom PageSpeed-Test für Mobile aus:

Nicht nur ist der mobile PageSpeed mit 37 besonders übel, sondern bezeichnender Weise weist Google bei Accessibility auch nur mäßige 72 der Website zu.

Bei Desktop hat in der Regel jede Website einen guten PageSpeed-Wert. Grün ist der Standard, gelb hat schon fast Seltenheitswert. Doch Deutsche See hat es geschafft. Ein Trauerspiel. Und der Wert für Accessibility ist weiter abgesackt.. 

Das Barrierefreiheitsplugin fügt „unnötige Schichten“ hinzu und schafft schwerfällige Skripte und Drittanbieter-Abhängigkeiten, was direkt zu erhöhten Ladezeiten beiträgt. Der Haupt-Thread des Browsers ist für kritische Aufgaben wie das Parsen von HTML, das Anwenden von Stilen und das Ausführen von JavaScript verantwortlich. Overlays monopolisieren oder blockieren diesen Haupt-Thread häufig, was das Rendern sichtbarer Inhalte erheblich verzögert und die Benutzerinteraktivität behindert. Die dynamische Injektion zahlreicher zusätzlicher Elemente und Stile kann zu einer übermäßigen DOM-Größe führen. Dies, kombiniert mit den großen Dateigrößen der Plugin-Assets, führt zu enormen Netzwerknutzlasten, was langsame Seitenladezeiten weiter verschärft, insbesondere für Nutzer mit langsameren Verbindungen oder mobilen Geräten.  

In der Liste mit den Empfehlungen zur Behebung dieser Probleme beim PageSpeed-Insights-Report habe ich einmal mit dem blauen Icon gekennzeichnet, wo der Diagnosereport tatsächlich direkt die Skripte vom Barrierefreiheit-Plugin namentlich als Teil des Problems referenziert. 

Die technische Architektur dieses Barrierefreiheits-Overlays führt direkt zu einer Verschlechterung der Performance mit allen Nachteilen für User Experience und SEO. Diese Art von Overlays funktionieren, indem sie große Mengen an JavaScript und CSS in die bestehende Struktur einer Website injizieren. Diese Injektion erhöht die insgesamt übertragene Datenmenge (Netzwerknutzlast) und fügt dem Document Object Model (DOM-Größe) zahlreiche Elemente hinzu. Ein zusätzliches Problem kommt hinzu, dass mit diesen Skripten auch viel unnötiger Code mitgeführt wird, der gar nicht oder noch nicht da sein sollte. 

Hier einmal die Auswertung, wenn „Reduced unused CSS“ und „Reduced unused JavaScript“ ausgeklappt ist.

Das Barrierefreiheits-Plugin lädt beim Seitenaufruf ein großes JavaScript-Paket (950 KiB), selbst wenn das Panel noch gar nicht benutzt wird. Erst beim Klick auf das blaue Icon wird das Panel aktiviert. Und dann kommen erst viele der Funktionen wirklich zum Einsatz. Die bessere Lösung sähe so aus, dass ein schlankes JavaScript nur das Icon initialisiert. Und erst beim Klick würde das vollständige Panel + Funktionalität on demand geladen

Hier sieht es anders aus: Damit der Browser die Seite beim Aufruf rendern kann, muss er den neu injizierten, oft unoptimierten, Drittanbieter-Code des Barrierefreiheits-Plugins verarbeiten und ausführen. Diese intensive Verarbeitung führt direkt zu einer erhöhten JavaScript-Ausführungszeit und einer stärkeren Belastung des Haupt-Threads. Das sind absolut kritische Faktoren für die Core Web Vitals. 

PageSpeed Insights weist sehr schlechte Leistungswerte auf, mit einem negativen Effekt, der explizit auch dem eingesetzten Barrierefreiheits-Plugin zugeschrieben wird. Ist es nur bei deutschesee.de so schlecht, aber andere Kunden lösten es besser? Schauen wir uns ein paar weitere Unternehmenswebsites an, die das bfw-Plugin nutzen – von links nach rechts: trelino.com, hb-marketplace.com (vom Händlerbund), christopeit-sport.com und ottowildegrillers.com. 

Die Werte sind durchgängig im roten Bereich. Keine Website erfüllt die Core Web Vitals. Nicht allein das Plugin sorgt für diese negativen Performance-Werte. Alle untersuchten Websites haben auch noch andere Baustellen, die optimalen PageSpeed-Werten entgegenstehen. Aber mit dem Overlay wird die Handbremse zusätzlich angezogen. Die Diagnosehinweise von PageSpeed Insights sind eine direkte Bestätigung der theoretischen Performance-Probleme, die mit Barrierefreiheits-Overlays verbunden sind. Diese konkreten Daten zeigen, dass diese Plugins die Kernleistungsmetriken einer Website aktiv untergraben, was zu messbaren negativen Auswirkungen auf die Benutzererfahrung, SEO  und potenziell die Konversionsraten führt.

Die grundsätzliche Funktionalität des Plugins zum besseren Erfassen der Inhalte für Menschen mit Beeinträchtigungen stelle ich hier gar nicht in Frage, aber

• … der komplette Code (hier: 1,2 MB nur für das Plugin … der absolut Performance-Killer) wird dennoch komplett mitgeladen, noch bevor der Nutzer etwas tut.
• … viele Nutzer nutzen das Panel gar nicht. Der Code ist also unnötiger Ballast.
• … der LCP (Largest Contentful Paint) als wichtige Metrik für die Core Web Vitals leidet, weil das JS und CSS den Renderprozess blockieren oder verzögern.
• … es gibt kein Lazy Loading, kein Code-Splitting, keine dynamische Nachladung.

Im Fazit wirkt technisch gesehen das Plugin wie ein Overkill. Es fügt viel Ballast hinzu, ohne dass erkennbar ist, welche echten Barrierefreiheitsfunktionen davon überhaupt sinnvoll eingesetzt werden. 

Wie irreführend ist in diesem Zusammenhang die Eigenwerbung des Plugin-Anbieters auf seiner Website mit den vermeintlichen Vorteilen beim Einsatz des Tools: 

• Verbesserte Reichweite und SEO: Barrierefreie Seiten ranken besser.
• Bessere Nutzererfahrung: Für alle Besucher - unabhängig von Einschränkungen.

Der Performance-Verlust durch das eingesetzte Barrierefreiheits-Tool ist so massiv, dass sich die User Experience spürbar verschlechtert – mit absehbaren Folgen für die Rankings. Bleibt zu hoffen, dass die SEO-Verantwortlichen bei Deutsche See & Co. die Ursache nicht allein bei den aktuell viel diskutierten AI Overviews suchen, die seit dem Roll-out bei vielen Websites für Trafficverluste sorgen, sondern auch den direkten Zusammenhang zwischen technischem Overhead und Sichtbarkeitsverlust erkennen. 

Das Compliance-Dilemma: Warum Overlays für Barrierefreiheit bei echter Inklusion versagen

Der begrenzte Umfang automatischer Korrekturen: Ein Pflaster, keine Heilung

Das Versprechen einer „vollautomatischen“ Barrierefreiheitslösung ist ein gefährliches Missverständnis. Automatisierte Tools und Overlays sind von Natur aus begrenzt und können nur einen Bruchteil der tatsächlichen Barrierefreiheitsprobleme erkennen.  

Diese Tools konzentrieren sich hauptsächlich auf oberflächliche Änderungen, wie das Ändern von Farben oder die Anpassung der Textgröße. Das sind ohnehin Funktionen, die Nutzer mit Behinderungen oft bereits über ihr Betriebssystem oder ihre Browsereinstellungen steuern. Entscheidend ist, dass Overlays die zugrunde liegenden strukturellen Probleme, die im HTML, CSS und in den ARIA-Rollen einer Website verankert sind, nicht beheben können. Sie können komplexe Probleme wie unsachgemäße Überschriftenstrukturen, fehlende oder falsche ARIA-Labels oder das Bereitstellen von wirklich aussagekräftigem Alternativtext für Bilder nicht effektiv beheben, da ihnen der menschliche Kontext und die Interpretationsfähigkeit fehlen, die dafür erforderlich sind.  

Overlays beheben Symptome, nicht die Ursachen. Echte Web-Barrierefreiheit ist tief in der semantischen Struktur und dem logischen Fluss des Codes einer Website verwurzelt, nicht nur in ihrer visuellen Präsentation. Overlays injizieren per Design eine Code-Schicht über die bestehende Website, anstatt den Kern von HTML, CSS und JavaScript zu modifizieren. Das bedeutet, dass sie oberflächliche Änderungen vornehmen können (z.B. Kontrastanpassungen), aber grundlegende strukturelle Fehler wie falsche Überschriftenhierarchien, unlogische Lesereihenfolgen oder dynamische Inhaltsprobleme, die eine direkte Code-Anpassungerfordern, nicht beheben können. 

Hier ist eine Auswertung von deutschesee.de durch den OnPage-Crawler SEOBILITY mit einem kleinen Auszug der Auffälligkeiten:

Wie löst jetzt das Accessibility-Tool die Probleme mit den Überschriften und der hierarchischen Struktur? Was bewirkt das Plugin bei den fehlenden Alt-Attributen bei den Bildern? Gar nichts davon wird gelöst durch das Plugin, sonst hätte der Crawler diese Fehler nicht erfasst. Schlechter noch: Das Plugin selbst liefert ein Bild ohne Alt-Attribut, wie im folgenden Screenshot zu sehen ist, wo PageSpeed Insights für die Shopstartseite keinen Alt-Text beim Popup-Bild und beim Logo des Plugins erkennt.

Diese Einschränkung bedeutet, dass sie nur sichtbare Symptome „flicken“, während die überwiegende Mehrheit komplexer Barrierefreiheits-Issues unbehandelt bleibt. Dies schafft ein falsches Gefühl der Sicherheit und führt zu dem, was als Compliance-Show bezeichnet werden kann. Es ist ein Anschein von Konformität ohne echte Einhaltung.  

Keine Barrierefreiheit bei integrierten Videos, iFrames oder PDF-Dateien

Deutsche See schreibt es selbst in der Barrierefreiheitserklärung und fasst damit sehr gut weitere Bereiche zusammen, wo das Barrierefreiheits-Plugins keine Hilfe bietet. 

Trotz unserer Bemühungen sind die nachstehend aufgeführten Inhalte nicht barrierefrei:

• PDF-Dokumente: Einige unserer PDF-Dokumente sind nicht barrierefrei. Wir bemühen uns, zeitnah eine angepasste Version oder barrierefreie Alternativen zur Verfügung zu stellen. Falls Sie eine bestimmte PDF-Datei von uns benötigen, die bisher nicht barrierefrei zur Verfügung steht, teilen Sie uns dies gerne mit. 
• Videos: Einige unserer eingebetteten Videos verfügen derzeit nicht über Untertitel. Wir bemühen uns, zeitnah alle Videos mit Untertiteln zu versehen. 
• Bilder ohne Alternativtext: Einige Bilder auf der Website haben keinen Alternativtext. Wir bemühen uns, Zeitnah um die Aktualisierung. 
• iFrame: Teile der Inhalte unsere Website sind aus technischen Gründen per iFrame eingebunden und darum nicht barrierefrei erreichbar. 

Zu den Bildern ohne Alt-Texte wurde schon genug gesagt (siehe auch oben). Auch die Anbieter von Buchungsplattformen, die via iFrame oder api-basiert Buchungswidgets für Websites für Hotels, Ferienwohnungen oder Boote bereitstellen, müssen handeln, um bei ihren Kunden keine Probleme zu erzeugen. 

Videos sollen Untertitel oder Transkriptionen erhalten. Das ist immer dann ein Problem, wenn ein Video etwa nicht über YouTube eingebunden ist, wo einfach die Untertitel aktivierbar sind. 

PDFs sollen ebenso barrierefrei sein, was ein Problem ist, wenn viele PDF-Dateien vorhanden sind. Wir haben auch für einige Kunden die auf der Website integrieren PDF-Dateien barrierefrei gemacht. Der Zeitaufwand war ehrlich gesagt höher als erwartet. Testbar sind PDF-Dateien übrigens mit diesem PDF-Barrierefreiheit-Checker. 

Beeinträchtigung von assistiven Technologien und Benutzererfahrung

Ein kritisches Problem ist, dass Barrierefreiheits-Overlays häufig die assistiven Technologien (AT) stören, die sie angeblich unterstützen sollen, wie Bildschirmlesegeräte, Tastaturnavigationstools und Vergrößerungsgläser.  

Nutzer mit Behinderungen konfigurieren ihre Geräte und AT sorgfältig, um ihren spezifischen Bedürfnissen gerecht zu werden. Overlays können diese personalisierten Einstellungen überschreiben und damit die Nutzer zwingen, sich auf jeder Website an ein unbekanntes System anzupassen. Dies führt zu mieser User Experience und macht Websites letztendlich frustrierender und weniger nutzbar. Die Behinderten-Community hat sich überwältigend gegen Overlays ausgesprochen. Eine WebAIM-Umfrage ergab, dass 72% der beeinträchtigten Nutzer diese Tools als „überhaupt nicht effektiv oder nicht sehr effektiv“ bewerteten … und nur 2,4% sie als effektiv empfanden.  

Overlays schaffen neue Barrieren für die Nutzer, denen sie eigentlich helfen sollen. Bildschirmlesegeräte sind darauf ausgelegt, die zugrunde liegende semantische Struktur einer Webseite (HTML-Elemente, ARIA-Attribute) zu interpretieren, um Informationen an die Nutzer zu übermitteln. Viele Websites, die auf Overlay-Lösungen setzen, haben im Code selbst keine saubere semantische Struktur. Wichtige Attribute wie aria-label fehlen komplett. Und genau hier liegt das Problem: Assistive Technologien wie Screenreader brauchen diese Angaben, um Nutzer durch Inhalte zu führen. 

Wenn stattdessen ein Overlay mit JavaScript einfach nur visuelle Funktionen drüberlegt, ändert sich an der eigentlichen Struktur nichts. Overlays aktualisieren diese zugrunde liegende semantische Struktur oft nicht korrekt oder können sogar mit ihr in Konflikt geraten, indem sie JavaScript injizieren und oberflächliche visuelle Änderungen vornehmen. 

Das Ergebnis ist, dass ein Tool, das die Barrierefreiheit verbessern soll, paradoxerweise neue, frustrierende Barrieren für genau die Personen schafft, die auf AT angewiesen sind, wodurch ihre Benutzererfahrung verschlechtert statt verbessert wird. Am Ende entsteht eine trügerische Oberfläche, die gut aussieht, aber zentrale Funktionen für assistive Technologien zerstören kann. 

Die starke Haltung der Behinderten-Community

Die Behinderten-Community, zusammen mit einer großen Mehrheit der Barrierefreiheitsexperten und Anbieter von assistiven Technologien, hat sich überwältigend und unmissverständlich gegen die Verwendung von Barrierefreiheits-Overlays ausgesprochen.  

Diese kollektive Opposition ist bedeutsam: Über 970 Barrierefreiheitsexperten und Menschen mit Behinderungen haben – mit Stand 12. Juli 2025 – einen offenen Brief unterzeichnet, in dem sie deren Verwendung verurteilen. 

Viele Nutzer setzen aktiv Ad-Blocker ein, um das Laden von Overlays zu verhindern. Diese starke Haltung rührt daher, dass Overlays häufig mehr Barrieren schaffen, bestehende, bevorzugte assistive Tools stören und sogar ernsthafte Datenschutzbedenken aufwerfen können, indem sie die Verwendung von assistiven Technologien automatisch erkennen und potenziell protokollieren, ohne die ausdrückliche Zustimmung des Nutzers.  

Funktionen, die die Seite aufblähen, aber die man nicht braucht

Schaut man sich die Funktionsvielfalt des BFW-Plugins an, so ist es einerseits beeindruckend, was die Entwickler auf die Beine gestellt haben, um Nutzern eine verbesserte Ansicht der Website zu ermöglichen. Andererseits darf gefragt werden, was überhaupt nutzerseitig benötigt wird, weil viele Funktionen wie Textgrößenänderungen, Farbkontraste etc. ohnehin schon vom Browser (siehe beispielsweise der im Chrome implementierte Lese-Modus) oder den Screenreadern geliefert wird. 

Der neue Code, der durch Overlays in die bestehende Code-Struktur injiziert wird, verlangsamt nicht nur den PageSpeed, sondern ist auch nicht abgestimmt auf die Layoutbedingungen der Website. Hier ist ein Beispiel der Ansicht, wenn der Modus für Legasthenie aktiviert ist. Bei drei Produkten ist der Produkttitel abgeschnitten und auch bei den Highlights reicht der Platz in den grünen Bildanteasern nicht mehr für den Text. Was freundlich für Legastheniker sein soll, erschwert den Zugang zu den Informationen.

Der starke Overbloat hätte vermieden werden können, wenn jede Funktion auf die Sinnhaftigkeit ernsthaft geprüft worden wäre.

Es kommt noch eine weitere Auffälligkeit hinzu. Diese Schriftart, die mit Klick auf den “Freundlich für Legasthenie”-Button angezeigt wird, heißt Open Dyslexic. Sie wurde ursprünglich entwickelt, um eine bessere Lesbarkeit herzustellen. So die Hypothese. 

Auf der Axe-Con 2021 präsentierte die Readability Group ihre große Typografie-Studie, in der sie die Effektivität von 20 verschiedenen Schriftarten bei 2022 Teilnehmenden getestet hat. Darunter über 250 Menschen mit ausgeprägten dyslektischen Merkmalen. Die Axe-Con ist eine jährliche, internationale Online-Konferenz, die sich ausschließlich mit digitaler Barrierefreiheit beschäftigt. Die Readability Group ist ein unabhängiges Forschungs- und Beratungsunternehmen, das sich auf Lesbarkeit, Typografie und barrierefreie Schriftgestaltung spezialisiert hat. 

Ziel der Typografie-Studie war es, durch echte Nutzerdaten herauszufinden, welche Fonts tatsächlich lesbar sind und welche nur das Etikett "barrierefrei" tragen. Jede Schriftart wurde über 16.000 Mal in rund 7.000 Teststunden angesehen. Das ist die Liste der 20 Schriftarten, beginnend bei der Schrift mit der höchsten Zustimmung. 

• BBC Reith Sans 65%
• SF Pro 65% … Apple entwickelte SF Pro intern, weil Helvetica Neue auf iPhones zu eng wirkte
• Verdana 64% … ich erinnere mich gut, viele Websites vor 20 Jahren hatte diesen Font gewählt. Die Verdana wurde speziell für Microsoft für Monitore mit geringer Auflösung konzipiert.  Die Buchstaben wurden besonders breit gestaltet, um selbst auf Röhrenmonitoren klar zu erscheinen. 
• Segoe UI 62%
• Legend Decca 62%
• Atkinson 60%
• Red Hat Text 60%
• Roboto 57% … ein Google-Font. Setzten wir auch bereits bei einigen Kundenprojekten ein.
• FS Me 56%
• Calibri 55% … lange Zeit die Standardschriftart von Microsoft, nachdem 2007 die Times New Roman damit ersetzt wurde.
• BBC Reith Serif 54%
• Ubuntu 54% … diese nutzen wir hier auch auf unserer Agentur-Seite. Diese Zeile liest du gerade in diesem Font.
• Helvetica 47% … everybody's darling.
• Roboto Slab 47%
• Lexie Readable 44% … speziell entwickelt für bessere Lesbarkeit für Menschen mit Dyslexie 
• Times New Roman 36%
• Sylexiad Sans 36% … speziell entwickelt für bessere Lesbarkeit für Menschen mit Dyslexie
• Dislexie 30% … speziell entwickelt für bessere Lesbarkeit für Menschen mit Dyslexie
• Comic Sans 28% … die hässlichste Schrift überhaupt.
• Open Dyslexic 18% … speziell entwickelt für bessere Lesbarkeit für Menschen mit Dyslexie

Interessant ist, dass die am schlechtesten abschneidenden Schriftarten für die Gruppe der Legastheniker genau diejenigen waren, die zu ihren Gunsten „entworfen“ wurden. Der Legasthenie-Modus bietet Betroffenen die Schriftart mit der geringsten Zustimmung an. So zeigt sich auch in diesem Fall mit dem Barrierefreiheitsplugin: gut gemeint, am Ziel vorbei und unnötig. 

Was sagen die Testtools zur Barrierefreiheit bei deutschesee.de?

Das Accessibilitychecker.org-Audit für den Shop von deutschesee.de liefert objektivierte Daten für das Versagen von Plugins, echte Barrierefreiheit zu liefern. Trotz des Ladens eines Barrierefreiheits-Plugins erhielt die Website einen miserablen "Audit Score: 29%" und wurde explizit als "NOT COMPLIANT" unter "Germany law" gekennzeichnet. 



Das Audit führte ferner 117 kritische Probleme auf allein für die getestete Shop-Unterseite und zeigt an, dass die Website zahlreiche WCAG-Kriterien nicht erfüllt. Bezeichnend ist dabei, dass der Accessibilitychecker.org in diesem Fall nicht mal den Overlay als solchen erkennt, was er bei anderen Tools durchaus tut. Die Ironie dabei: Ebenso fällt der Händlerbund mit seiner Marketplace-Seite durch, wo das Barrierefreiheitsplugin angeboten wird. 

Nichtsdestotrotz werden ein begrenzter Teil der genannten Probleme  tatsächlich durch das Plugin gelöst, wie etwa Farbkontraste, die aktuell zu schwach sind. Weitere Teile wie fehlende Alt-Texte, fehlende ARIA-Label wie das Fehlen von zugänglichen Namen von Buttons werden nicht durch das Plugin gelöst … gerade die Informationen, die für sehbeeinträchtige Menschen bei der Nutzung von Screenreadern elementar sind.

Die folgende Tabelle vergleicht, wie Overlays und Code-Level-Lösungen die WCAG-Prinzipien handhaben:

Diese Tabelle verdeutlicht die grundlegenden Unterschiede in Ansatz und Effektivität zwischen Overlays und Code-Level-Lösungen.

Begrenzte Verbesserungen sind möglich durch Plugins und Overlays

Wer sich jetzt fragt, um wie viel Prozent die Plugins und Overlays auf den Weg zur Compliance helfen, kann als Faustformel mit ca. 40 % Verbesserung kalkulieren. 

Skynet Technologies hat dazu einen Modus, der die Plugin-Wirkung dem Score aufrechnet. Auch hier kann eine Prüfung kostenlos für eine Unterseite vorgenommen werden. Bei Deutsche See kommen knapp 57 Prozent und der Status Semi Compliant als Ergebnis.

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

Interessant ist vor allem der Switcher oben rechts, bei dem der Einsatz des von Skynet Technologiens angebotenen All in One Accessibility Tools in der Paid-Variante similiert wird, wie viele Probleme damit gelöst werden. Mehr als 200 Issues können behoben werden. Über 25 Prozentpunkte wächst der Score. Es bleibt aber im Status Semi Compliant.

Verführendes oder irreführendes Marketing der Anbieter?

Plugins für Compliance sind ein Marketingversprechen, das mit Vorsicht zu genießen ist. Die Annahme von Websitebetreibern ist ja gerade, dass das Plugin sicherstellt, die gesetzlichen Anforderungen zu erfüllen. Doch das tun sie anscheinend nicht. Die größere Implikation ist, dass Unternehmen nicht nur eine fehlerhafte technische Lösung kaufen und einsetzen, sondern aktiv in ein rechtliches Risiko investieren.

Barrierefreiheits-Overlays erfüllen nicht ihren primären beworbenen Zweck, die Einhaltung gesetzlicher Vorschriften zu gewährleisten. Es bestätigt den weit verbreiteten Expertenkonsens, dass diese Tools ein falsches Gefühl der Sicherheit vermitteln und nicht vor Nicht-Konformität schützen.  

Interessant ist der Unterschied in der Kommunikation beim Bewerben der Barrierefreiheitsplugins zwischen etablierten amerikanischen Anbietern, die bereits in einem klagefreudigen Umfeld ihre Schranken aufgezeigt bekommen haben, und den neuen Goldgräbern im deutschen Markt. Skynet Technologies oder der mit einer Strafzahlung von 1 Mio Dollar verurteilte Anbieter AccessiBe bewerben ihr Tool auf ihren Websites mit Aussagen wie: 

• unterstützt Unternehmen bei der Optimierung zur Barrierefreiheit
• verbessert die Barrierefreiheit
• reduziert rechtliche Risiken

Das einzige, was hier mit wenigen Klicks oder in zwei Minuten machbar ist, ist allein die Integration des Tools in der Website, aber nicht die Barrierefreiheit. Und das schreiben die Anbieter auch ganz offen.

Die neuen deutschen Tool-Anbieter, die wie Pilze aus dem Boden sprießen, kommunizieren hingegen differenziert dazu. Das BFW-Plugin verspricht vollmundig: 

• Ob Website, Shop oder Portal – BFSG-konform mit einem Klick
• Mit unserer hochkompatiblen Plugin-Lösung erfüllt Ihre Webseite die gesetzlichen Anforderungen. 
• Sichern Sie sich Ihre rechtssichere und barrierefreie Website durch unser Plugin – schnell und einfach.
• Mit unserem Plugin vermeiden Sie rechtliche Risiken und verbessern die Nutzererfahrung für ALLE Besucher.
• Mit unserem Plugin integrieren Sie Barrierefreiheit auf Ihrer bestehenden Website innerhalb weniger Minuten. Nur zwei Zeilen Code – sofort mehr Inklusion und Rechtssicherheit.
• Rechtssicherheit: Erfüllt alle Anforderungen der WCAG 2.1 und BITV 2.0.
• Barrierefreiheit in wenigen Minuten aktivieren.
• Mit unserem zertifizierten Plugin machen Sie Ihre Website in wenigen Minuten barrierefrei – gesetzeskonform, sicher und ganz ohne Programmieraufwand.

Ich wüsste gern, von welcher Art Zertifizierung der Anbieter genau spricht. Darüber finde ich keine Auskunft. 

Beim Mitbewerber AccessGo finden sich Versprechen wie: 

• … erfüllen Sie die gesetzlichen Anforderungen einfach, schnell und stressfrei.
• … setzen Sie die Vorgaben automatisch und rechtssicher um – ganz ohne Technikaufwand.

In der Barrierefreiheitserklärung der Unternehmen, die dieses Tool dann tatsächlich einsetzen, wird zurückgerudert. So beispielhaft bei der Website von Eintracht Braunschweig, die das Plugin von AccessGo einsetzen. Besuchst du die Website, erhältst du direkt die erste Zugangsbarriere: Das Icon für das Barrierefreiheitsplugin wird aktuell noch vom Cookie-Banner verdeckt. Zudem ist der Cookie-Banner auf englisch, weil dieser auf die Browsersprache reagiert, obwohl ich auf der deutschen Eintracht-Seite bin. 

Cookie-Banner sind leider allzu oft nicht für den Screen-Reader auswertbar, was direkt auch aus der Community der sehbehinderten Menschen kritisiert wird.

Schaust du auf der Website in die Barrierefreiheitserklärung, so heißt es: 

Wie barrierefrei ist das Angebot?

Die Einschätzung basiert auf einer Selbstbewertung unter Hinzunahme des Accessibility-Tools von AccessGO.

Aufgrund dieser Überprüfung ist die Website mit den zuvor genannten Anforderungen teilweise barrierefrei.

Im Einzelnen sind die folgenden Punkte nicht vollständig mit den für uns geltenden Vorschriften zur Barrierefreiheit vereinbar:

Barriere: Einige Buttons sind leer oder enthalten keinen beschreibenden Text.
Barriere: Einige Links sind leer oder enthalten keinen Text, wodurch deren Ziel oder Funktion nicht erkennbar ist.
Barriere: Einige Bilder sind leer oder enthalten keinen beschreibenden Text.
Wir planen aktuell die Umsetzung der Behebung dieser Barrieren.

Aus Marketing-Sicht hat es AccessGo clever gemacht. Zur Barrierefreiheit verpflichtete Unternehmen wird die schnelle und einfache Erfüllung der WCAG-Anforderungen versprochen. Rechtssicherheit mit wenigen Klicks. Agenturen und/oder Unternehmen entscheiden sich also für ein Tool, aber am Ende wird nur die Semi-Compliance geliefert. Nach dem Installieren des Plugins bleiben zahlreiche Probleme erhalten, worüber dann in der Barrierefreiheitserklärung Auskunft erteilt wird. Reicht das, um Bußgelder oder Abmahnungen zu verhindern? Ich weiß es ehrlich gesagt nicht. Es bleibt abzuwarten. 

Psychologisch geschickt wurde auch der Namen des Unternehmens gewählt, der im Footer für das Tool AccessGo präsentiert wird: Deutsche Gesellschaft für Barrierefreiheit. 

Darunter macht man es nicht. Es erinnert sofort an echte Instanzen wie die Deutsche Gesellschaft für internationale Zusammenarbeit oder Deutsche Gesellschaft für Psychologie oder Ernährung, Palliativmedizin oder andere bekannte Gesellschaften, wo sich Mitglieder austauschen und im Interesse des Themas gesellschaftliche Verbesserungen anstreben. Nur zum Unterschied, dass die Deutsche Gesellschaft für Barrierefreiheit kein Verein oder eine Stiftung ist, sondern eine GmbH, die erst im März 2025 im Handelsregister eingetragen wurde.

Mindestens 100 Unternehmen setzen das Tool bereits ein, gelockt mit dem Versprechen von schneller Erfüllung der WCAG-Anforderungen und Rechtssicherheit – schnell und ohne großen Aufwand barrierefrei, wie es unten im Footer auch heißt. Als Unternehmen möchte man auch auf das richtige Tool setzen. Zum großen (Vertriebs-) Glück erhielt der Tool-Anbieter bereits im Januar 2025 – also noch vor der Gesellschaftsgründung – die passenden Best-Bewertungen auf gleich drei Portalen, von den drei identischen Nutzernamen: Patrick, Laura und Anonymus. 

So konnte direkt zum Start mit den Bewertungen der „Kunden“ geworben werden auf der Website.

Wir als Agentur sind ehrlich schon dankbar, wenn  Kunden eine Google-Rezension beisteuern. Das ein Kunde direkt bei drei Bewertungsplattformen sein Lobeshymne abgibt, ist der neue Goldstandard für mich ab heute.

Richtig plump wird es bei den Testimonials bei dem BFW Plugin, welches aktiv vom Händlerbund beworben wird. 

Die Kunden Thomas Klein und Anna Schubert loben über Gebühr. Natürlich. Die Namen so deutsch und eingängig, als hätte jeder mal in seiner Klasse eine Person mit diesem Namen gehabt. Gibt es sie wirklich? Das bleibt fraglich. Denn die beiden Testimonial-Darsteller heißen auf einer anderen Website Christa und John Smith. 

Es gibt aber noch weitere Nutzungen dieser Bilder, leicht ermittelbar über Google Lens. Ganz gleich ob Bild von einem Stock-Portal oder aus der KI, vermutlich waren die Bilder bereits als Platzhalter im verwendeten Website-Template integriert.

Auch ein dritter deutscher Anbieter, dessen Tool nach eigener Aussage mit wenigen Klicks „Ihre Website automatisch barrierefrei macht“, nutzt diese Herangehensweise auf seiner Landingpage:

Der Kunde Leon heißt dann auf dieser anderen Website Markus und in über 150 weiteren Online-Präsenzen Ben, Will, David oder vielleicht auch Heinz. 

Rechtliche Risiken: Overlays schützen nicht vor Klagen

Agenturen und Unternehmen vertrauen auf neue Anbieter, um ihre oder die Kundenwebsites schnell und einfach rechtssicher zu gestalten, gestützt von markigen Versprechungen zur Erfüllung der WCAG-Anforderungen, der Empfehlung von seriösen Dienstleistern wie dem Händlerbund und vermeintlichen Kundenzitaten, deren Herkunft mehr als schleierhaft ist. Dafür sind Unternehmen bereit, jährliche Kosten in Kauf zu nehmen, was an sich okay ist, wenn die Gegenleistung stimmt. Hier erhalten Unternehmen aber eine Lösung, die keine Compliance herstellt. Und das werden wir in Deutschland früher oder später auch gerichtlich bestätigt bekommen.

In den USA ist längst klar: Barrierefreiheits-Overlays bieten keinen rechtlichen Schutz. Das US-Justizministerium empfiehlt klar die Einhaltung der WCAG 2.1 AA-Richtlinien als Mindeststandard zur ADA-Konformität (dem amerikanischen Pendant zu unserer europäischen EAA-Richtlinie, worauf sich das deutsche BFSG bezieht). Trotzdem vertrauen viele Unternehmen weiterhin auf technische Scheinlösungen wie Overlays. Das hatte bereits kostenintensive Folgen. Allein im Jahr 2023 betrafen 24,5 % aller ADA-Klagen Websites, die genau solche Plugins einsetzten.

Gerichtsurteile wie Murphy vs. Eyebobs oder Quezada vs. US Wings haben gezeigt, dass Overlays keine gesetzliche Absicherung darstellen. Inzwischen richten sich sogar Sammelklagen direkt gegen Overlay-Anbieter: so etwa im Fall accessiBe, das wegen irreführender Versprechen zur Wirksamkeit seines Tools eine Strafe in Millionenhöhe zahlen musste. Es waren solche Versprechen, die denen der hier vorgestellten Tools nicht unähnlich waren.

Was heute in den USA geschieht, könnte ein Vorbote für Europa sein. Mit Inkrafttreten des Barrierefreiheitsstärkungsgesetzes (BFSG) rücken ähnliche Haftungsrisiken auch hierzulande in greifbare Nähe. Das BFSG selbst sieht Bußgelder bis zu 100.000 Euro vor. Unternehmen, die auf vermeintlich „schnelle“ Plugin-Lösungen setzen, investieren nicht in Barrierefreiheit, sondern in ein rechtliches Risiko: Denn die Plugins täuschen Konformität vor, ohne die tatsächlichen Anforderungen zu erfüllen. Und wenn die Unternehmen ehrlich wären, war die Investition in solche Plugins zu keiner Zeit von den Motiven zu mehr Inklusion getragen, sondern allein zur Herstellung der Rechtssicherheit.

Es entsteht eine gefährliche Kette: irreführendes Marketing → Implementierung ineffektiver Overlays → Nichteinhaltung der gesetzlichen Vorgaben → erhöhte Klageanfälligkeit → Imageverlust → potenziell empfindliche Bußgelder  → Nacharbeitung bei der Optimierung für Barrierefreiheit über den richtigen Code-Level-Ansatz und damit erneute Kosten.

Auch ein weiteres Szenario ist denkbar: AGG-Klagen wegen unzureichender Barrierefreiheit. Wenn du als sehbeeinträchtigte Person eine Stellenanzeige auf der Website eines Unternehmens aufgrund von mangelnder Barrierefreiheit (z. B. fehlende Alternativtexte, unlesbare PDFs oder unzugängliche Formularfelder) nicht wahrnehmen oder bedienen kannst, könnte das eine mittelbare Diskriminierung aufgrund einer Behinderung darstellen. Wer glaubhaft machen kann, dass er aufgrund fehlender Barrierefreiheit benachteiligt wurde und sich daraus ein Nachteil im Bewerbungsprozess ergeben hat, könnte geneigt sein, Schadensersatz oder Entschädigung zu verlangen. Immer wieder lesen wir in der Presse von arbeitsgerichtlichen Prozessen, indem manche Menschen Benachteiligungen im Bewerbungsprozess hundertfach zur Klage gebracht haben. 

Das alleinige Vertrauen auf Barrierefreiheits-Overlays macht Unternehmen anfällig für Klagen und rechtliche Konsequenzen wegen Nichteinhaltung. Was in den USA bereits in den letzten Jahren passiert ist, prognostiziere ich genauso für die EU und für Deutschland.  

Der Händlerbund trommelt weiter fleißig für die Lösung vom BFW-Plugin und fragte direkt im Mailbetreff in seinem Info-Newsletter am 10. Juli seine Mitglieder: Barrierefreiheit: Wen trifft die erste Abmahnung? ⏳

Es mag sein, dass ich mich insgesamt hier täusche und die Gegebenheiten hier in Deutschland bei der Umsetzung der WCAG-Anforderungen falsch beurteile, indem ich die rechtlichen Risiken, denen sich Unternehmen mit Overlays aussetzen, einfach von den USA auf uns übertrage. Ich schätze den Rechtsservice vom Händlerbund sehr. Wir nutzen ihn seit Jahren. Und meine Zeilen hier in diesem Blogbeitrag sind keine Rechtsberatung, sondern einfach meine persönliche Draufsicht, also ein Meinungsbeitrag. Mir ist daher wirklich schleierhaft, wie der Händlerbund seinen Zehntausenden Mitgliedern ein Plugin als rechtssichere Lösung verkauft. Ein Plugin wird nur ca. 40 % der Probleme korrigieren. Und es ist eigentlich nur dann sinnvoll, um Probleme mit den Farbkontrasten zu lösen, wenn beispielsweise Farbanpassungen aufgrund des Corporate Designs nicht möglich sind. Aber selbst dann kann auf Code-Basis einfach ein Kontrast-Switcher hinzugefügt werden, der nur den Code lädt, um via CSS die Farben anzupassen via Klick. Da gibt es keine Probleme mit zu viel Code, mit Einfluss auf den PageSpeed oder sonstige Nachteile. 

Der richtige Weg ist daher die Herstellung von Barrierefreiheit auf Code-Level-Basis – abgesichert durch Testtools und manuellen Tests.

Code-Level Accessibility: Der Goldstandard für nachhaltige Inklusion

Barrierefreiheit beginnt im Code, nicht im Plugin. Es geht darum, HTML, CSS und JavaScript so zu strukturieren, dass Inhalte für alle nutzbar sind, auch für Nutzer mit Screenreader oder Tastatur-Navigation. Das ist kein Quick-Fix, sondern nachhaltige Arbeit.

Was für Code-Lösungen spricht:

• Keine Ladeverzögerung. Keine sperrigen Overlays, keine flackernden Interfaces. Nur ein sauberes, schnelles Grundgerüst.
• Keine Drittanbieter-Risiken. Keine fremden Skripte, die andere Tools blockieren oder den Shop lahmlegen.
• Rückhalt aus der Community. Menschen mit Assistenztechnologien vertrauen auf durchdachte, im Code verankerte Accessibility.
• Weniger rechtliches Risiko. Wer im Code barrierefrei arbeitet, erfüllt echte Standards: WCAG, ADA, BFSG. Keine Scheinlösungen.
• Günstiger. Was einmal im Code sitzt, muss später nicht teuer nachgebessert werden.

Eingebaut, nicht aufgesetzt: Das Fundament echter Barrierefreiheit

Code-Level-Barrierefreiheit bedeutet, grundlegende, strukturelle Änderungen direkt im HTML, CSS und JavaScript deiner Website vorzunehmen. Dieser Ansatz  ist der zuverlässigste und nachhaltigste Weg, um echte Web-Barrierefreiheit zu erreichen“. Durch die direkte Integration der Barrierefreiheit in die Kernstruktur der Website wird sie „in das Fundament Ihrer Website eingebaut“ wodurch sichergestellt wird, dass Verbesserungen dauerhaft, robust und integral sind, anstatt temporäre Patches.  

Im krassen Gegensatz zu Overlays führen Code-Level-Änderungen zu keiner zusätzlichen Ladezeit, keinem flackernden Interface und keinem unnötigen Ballast. Dieser Ansatz hält die Website von Natur aus schlank, schnell und unter deiner Kontrolle. Durch die Eliminierung der Notwendigkeit externer, Drittanbieter-Abhängigkeiten und die Vermeidung unnötiger Schichten beseitigen Code-basierte Lösungen das Risiko von Fehlern, Konflikten mit anderen Tools oder unerwarteten Funktionsstörungen der Website.  

Code-Level-Barrierefreiheit ist ein Performance-Beschleuniger, kein Hindernis. Es muss nichts erst aktiviert werden, was womöglich durch einen Cookie-Banner verdeckt ist. Es ist von vornherein da. Gute Praktiken der Code-Level-Barrierefreiheit beinhalten von Natur aus die Optimierung von HTML, CSS und JavaScript, die Sicherstellung eines effizienten Ladens und die Minimierung unnötiger Code-Bloat. Diese Praktiken führen direkt zu kleineren Dateigrößen, weniger Haupt-Thread-Arbeit und schnelleren Rendering-Zeiten, die die Kernkomponenten starker Core Web Vitals sind.

Viele Verbesserungen, die durch Barrierefreiheit vorangetrieben werden, wie logische Navigation, lesbarer Text und responsives Design, kommen naturgemäß allen Nutzern zugute, nicht nur denen mit Behinderungen. Dieser universelle Designansatz führt zu einer verbesserten Gesamtbenutzererfahrung und trägt tatsächlich positiv zur SEO bei.  

Das Vorgehen ist relativ simpel. Es wird vorab ein Full-Scan aller Webseiten durchgeführt mit einem professieonellen Tool. Wir setzen dafür beispielsweise accessibilitychecker.org ein. Unsere Kundenwebsites werden geprüft im Modus WCAG 2.2 mit weiteren Best-Practice-Anforderungen aus der Community. Die aufgeführten Issues ergeben einen Score. Codeseitig werden die Probleme behoben und in weiteren Scans wird die Umsetzung technisch geprüft. Beispielhaft hier der Vorher-Nachher-Score von einer Krankenhaus-Website.

Da die Testtools nicht alle Barrieren feststellen können, müssen auch noch zusätzlich manuelle Tests erfolgen. 

Bedeutsamerweise bevorzugt die Behinderten-Community, einschließlich derer, die auf assistive Technologien angewiesen sind, „Code-Level-Barrierefreiheit“ überwiegend, da sie eine nahtlose und zuverlässige Interaktion mit ihren bestehenden Tools ohne Störungen garantiert.   

Da Code-Level-Fixes Barrierefreiheitsbarrieren an ihrer Quelle beheben, ist es wahrscheinlicher, dass sie gesetzliche Compliance-Standards wie die WCAG erfüllen. Dieser proaktive, grundlegende Ansatz reduziert das Risiko von Klagen oder Beschwerden und zeigt eine tatsächliche Investition, Websites wirklich inklusiv zu gestalten, was einen robusteren Rechtsschutz bietet als Overlays.  

Schlankerer Code heißt auch geringerer CO2-Fußabdruck. Von Natur aus sind barrierefreie Websites tendenziell schlanker, schneller und effizienter, was direkt zu einem geringeren Energieverbrauch über Geräte und Netzwerke beiträgt.  

Kostenvergleich: Code-Level-Accessibility vs. Plugin/Overlay für Barrierefreiheit

Barrierefreiheit ist kein Add-on. Sie gehört ins Fundament. Wer auf Plugins setzt, spart vielleicht auf den ersten Blick, zahlt aber langfristig mehrfach drauf. Wir haben uns mit den Kosten für Barrierefreiheit bereits in einem separaten Blogbeitrag beschäftigt. Der Vergleich der Kosten von Code-Level-Barrierefreiheit, wie wir als Agentur für Barrierefreiheit es umsetzen, und dem Plugin-Einsatz lohnt.

Plugins: Günstig starten, teuer enden

Die monatlichen Kosten der Toolanbieter sind ähnlich. Die Kosten für das BFW-Plugin liegen beispielsweise zwischen 29 € und 59 € monatlich, dazu kommt eine einmalige Einrichtungsgebühr von rund 299 €, sofern die zwei Zeilen Code kundenseitig nicht selbst integriert werden können. Klingt überschaubar. Doch was ist der Preis wirklich?

• Technisch keine echte Lösung: Das Plugin überblendet nur, eine Vielzahl an Barrieren im Code bleibt.
• Schlechte PageSpeed-Werte: Externe Scripts bremsen Ladezeiten, was SEO & Nutzererlebnis negativ beeinflusst.
• Keine Rechtssicherheit: Die Anforderungen des BFSG oder der EAA werden durch Overlays in aller Regel nicht erfüllt.
• Abhängigkeit vom Toolanbieter: Du mietest eine Lösung. Sobald du kündigst, ist der „Schutz“ weg.

Code-Level-Accessibility: Einmal richtig unddauerhaft wirksam

Unsere eigenen Arbeiten für unsere Kundenwebsites zeigen: Bereits mit 3–20 Stunden Aufwand lassen sich viele Websites technisch sauber, barrierefrei und rechtssicher machen. Bei einem Stundensatz von 120 € netto sind das nach unseren Erfahrungen:

• Onepager: 360–840 € netto
• Corporate Website: 720–1.800 € netto
• Online-Shop: 1.200–2.400 € netto

Darin enthalten: die technischen Anpassungen, die Barrierefreiheitserklärung und ggf. Inhalte in Leichter Sprache – inkl. Audit und Nachweis über 100 % WCAG-Erfüllung per Tool-Zertifikat.

Während die anfängliche Implementierung von Code-Level-Barrierefreiheit mehr Aufwand und Investitionen erfordern mag, reduziert sie den Bedarf an laufenden Flicklösungen, die Abhängigkeit von externen Tools oder kostspieligen rechtlichen Reaktionen. Ein proaktives Modell vermeidet die zusätzlichen Ausgaben und verringert die Notwendigkeit, die Endprodukte zu überarbeiten oder neu zu strukturieren.  

Fazit: Investition statt Miete,  Sicherheit statt Scheinlösung

Wer seine Seite sauber im Code barrierefrei macht, investiert in die Substanz – und profitiert:

• bessere SEO-Werte
• schnellere Ladezeiten
• positive User Signals
• höhere Rechtssicherheit
• keine laufenden Plugin-Kosten

Tipp: Einige Agenturen verlangen allein für ein Audit 2.500 €. Bei uns bekommst du das kostenlos. Wir sagen dir ehrlich, was ansteht … und setzen es um, wenn du willst. Fair. Transparent. Mit echtem Ergebnis.

Code-Level-Barrierefreiheit ist eine strategische Geschäftsinvestition, nicht nur eine Compliance-Ausgabe. Die wahrgenommenen höheren Anfangskosten für Code-Level-Barrierefreiheit werden oft als Hindernis genannt … auch in den Barrierefreiheitserklärungen findet sich hin und wieder die Aussage der wirtschaftlichen Unzumutbarkeit. Ganz nachvollziehbar ist es aus unserer Sicht nicht. Es ist mehr eine Schutzbehauptung. Podcastfolgen sollen nicht transkriptierbar sein? Das macht die KI mittlerweile automatisiert. Videos ohne Untertitel? Auch diese können via KI erstellt und den Videos zugewiesen werden, sofern die Videos nicht ohnehin via YouTube geladen werden, wo Untertitel per Klick aktivierbar sind. Alt-Texte können nicht nachgearbeitet werden? Ausrede. Codeseitige Anpassungen sind zu kostspielig? Definitiv nicht, wie wir dutzendfach in verschiedenen CMS- und Shopsystemen bewiesen haben. 

Wenn du willst, dass deine Seite für alle funktioniert – dann mach’s richtig. Mach’s im Code. Wir helfen dir dabei, dass Website barrierefrei zu machen.

Fazit: Aufbau eines wirklich barrierefreien und leistungsstarken Webs

Barrierefreiheits-Plugins und Overlays sind trotz ihrer verlockenden Versprechen von schnellen Lösungen ein falsches Gefühl der Sicherheit. Ein Overlay kann die Einhaltung einiger Bestimmungen in den wichtigsten Zugänglichkeitsstandards verbessern. Eine vollständige Einhaltung der WCAG-Standards lässt sich jedoch nicht allein mit einem Overlay erreichen. Die deutschen Plugin-Anbieter werben damit, dass Barrierefreiheit mit wenigen Klicks erreichbar ist, in den Barrierefreiheitserklärungen ihrer Kunden lesen wir dann, was doch nicht alles geht.

Wie das Beispiel mit deutschesee.de zeigt, beeinträchtigen diese Overlays die Website-Performance erheblich mit negativen Folgen für User Experience und SEO. Sie erfüllen entgegen ihrem Zweck nicht die tatsächlichen WCAG-Anforderungen, sondern setzen Unternehmen stattdessen weiterhin rechtlichen Risiken aus. Letztlich frustrieren sie Nutzer mit Behinderungen und schließen sie teilweise weiterhin aktiv aus.

Dieser Code-Level-Ansatz ist eine dauerhafte, skalierbare und echte Lösung, die allen Besuchern eine überlegene Benutzererfahrung bietet, die SEO verbessert, die rechtliche Position stärkt und sogar positiv zur ökologischen Nachhaltigkeit beiträgt. 

Barrierefreiheit ist ein fortlaufender Prozess, keine einmalige Produktinstallation. Automatisierte Overlay-Tools sind für das Erreichen echter Barrierefreiheit unzureichend. Das heißt auch, dass ein "Einrichten und Vergessen"-Ansatz, der oft mit Plugins verbunden ist, grundsätzlich fehlerhaft ist. Stattdessen erfordert Barrierefreiheit einen kontinuierlichen Prozess, der menschliches Wissen (z. B. in der Contentpflege), regelmäßige Audits und Monitoring integriert. Dies verschiebt das Paradigma von der Betrachtung von Barrierefreiheit als Produkt, das gekauft werden muss, hin zu einem eingebetteten Prozess innerhalb des Unternehmens, wo Inklusion tatsächlich mitgedacht wird.