Ein Klick auf ein Icon und alles ist barrierefrei? So einfach ist es nicht. Zwischen Overlay-Tools, KI-Versprechen und A11y-Siegeln entsteht ein Markt der schnellen Lösungen. Doch echte digitale Barrierefreiheit beginnt nicht mit einem Widget, sondern mit Struktur, Prozessen und Haltung, weiß Autor David Job.
Darum geht’s.
Viele Websites haben ein Symbol für Barrierefreiheit.
Ein Klick macht zum Beispiel den Text größer oder startet eine Vorlesefunktion.
Aber: Das macht eine Website nicht wirklich barrierefrei.
Oft liegen die Probleme tiefer:
- Die Navigation funktioniert nicht mit der Tastatur
- Formulare sind unklar
- Fehlermeldungen sind schwer verständlich
Diese Probleme kann ein zusätzliches Tool nicht lösen.
Viele Firmen nutzen solche Tools, weil sie schnell und einfach sind.
Doch echte Barrierefreiheit braucht mehr:
- gutes Design und klare Struktur
- saubere Technik
- Tests mit betroffenen Menschen
Wichtig:
Eine barrierefreie Website funktioniert für alle –
auch ohne extra Klick auf ein Symbol.
Barrierefreiheit auf Knopfdruck?
Es ist ein Klick, der sich gut anfühlt.
Rechts oben, zwischen Cookie-Banner, Chatbot und Newsletter-Popup: ein kleines Icon. Ein Menschlein, ein „A11y“-Symbol, manchmal gleich mit dem Versprechen, die Welt werde jetzt einfacher. Ein Klick – und schon gibt es einen größeren Kontrast, eine größere Schrift, Fokusmarkierungen, eine Vorlesefunktion. Barrierefreiheit: aktiviert. Teilhabe als Schalter – funktioniert das?
Wer auf Barrierefreiheit angewiesen ist, klickt selten auf Symbole. Sie*Er klickt auf „In den Warenkorb“. Auf „Weiter“. Auf „Zahlungspflichtig bestellen“. Und scheitert – wenn es schlecht läuft – genau dort, wo kein Zusatzmenü hilft: an einem verschwundenen Fokus, an einem Formular ohne Labels, an einer Fehlermeldung, die nur rot ist und sonst nichts erklärt, an einer Navigation, die sich per Tastatur nicht bedienen lässt.
Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) – und bringt Barrierefreiheit in weite Teile der Privatwirtschaft als Pflicht. Wer die Anforderungen ignoriert, riskiert Sanktionen; das Gesetz sieht Bußgelder bis zu 100.000 Euro vor. Das ist, auf dem Papier, ein ordentlicher Hebel. In der Realität wirkt er bisher jedoch noch recht verhalten. Aber in einigen Chefetagen ist Barrierefreiheit angekommen. In manchen Organisationen als echte Veränderung, in anderen als Projekt für „später“, in wieder anderen als Ticket im Sprint Planning: „Wir sind dran.“
Und dann gibt es jene weitere Kategorie, die man kaum übersehen kann, weil sie überall auftaucht: das Icon. Der Knopf zur Barrierefreiheit. Barrierefreiheit als Feature.
Die Verführung des Zeichens
Overlay-Tools – oft „Accessibility Widgets“ genannt – sind meist Drittanbieter-Skripte, die sich in eine Website einbinden lassen. Sie legen eine zusätzliche Bedienoberfläche über die Seite und bieten verschiedene Funktionen an; manchmal auch „KI-Fixes“, die automatisch reparieren sollen, was im Code oder Content schiefgelaufen ist.
Das klingt nach Hilfe. Und manchmal ist es auch eine Hilfe: für Menschen, die keine eigenen assistiven Technologien nutzen oder sie nicht gut konfigurieren können; für Situationen, in denen „Text ruhiger darstellen“ oder „Vorlesen“ kurzfristig unterstützt.
Aber Komfort ist nicht dasselbe wie Barrierefreiheit.
Warum werden solche Tools trotzdem massenhaft gekauft? Nicht aus schlechter Absicht, sondern aus Organisationslogik. Overlays sind schnell, sichtbar und wirken kostengünstig – zumindest im Vergleich zu „Wir bauen Prozesse, Kompetenz und ein barrierefreies Design-System auf“. Sie liefern, was Systeme lieben: ein Zeichen.
Ein sichtbares Zeichen dafür, dass etwas „getan“ ist. Und sie liefern es in der perfekten Form: als kleines Icon, das niemanden stört, der ohnehin keine Barrieren erlebt.
Wer die Perspektive von Menschen mit Behinderung ernst nimmt, versteht schnell, warum Overlays so oft enttäuschen.
Warum „noch eine Ebene“ oft zur nächsten Barriere wird
Wer die Perspektive von Menschen mit Behinderung ernst nimmt, versteht schnell, warum Overlays so oft enttäuschen. Viele Nutzer*innen arbeiten längst mit einem sehr persönlichen Setup: Screenreader mit eigenen Kurzbefehlen, Browser- und Betriebssystem Einstellungen, Vergrößerungssoftware, alternative Eingaben. Ein Overlay kommt dann nicht als neutraler Helfer, sondern als neues System mit eigener Logik – und diese Logik kollidiert nicht selten mit dem, was ohnehin schon funktioniert.
Verbände warnen genau davor. Der Deutsche Blinden- und Sehbehindertenverband (DBSV) schreibt ausdrücklich, Overlays könnten eine Website nicht „auf Knopfdruck“ umfassend barrierefrei machen und könnten im Gegenteil neue Barrieren erzeugen, besonders für blinde Menschen. Das EDF (European Disability Forum) und die IAAP (International Association of Accessibility Professionals) betonen außerdem, Overlays könnten Assistive Technology stören oder Nutzer*inneneinstellungen überschreiben und damit Websites für manche Menschen weniger zugänglich machen.
Das Problem ist nicht, dass Overlays etwas tun. Das Problem ist, dass sie oft an der falschen Stelle ansetzen.
Viele Barrieren sind keine Darstellungsprobleme, sondern Struktur- und Interaktionsprobleme:
- ein Menü, das per Tastatur nicht erreichbar ist
- ein Fokus, der hinter Modals verschwindet
- Formulareingaben ohne Labels
- Fehlermeldungen, die nur Farbe nutzen
- Überschriften, die optisch nach Struktur aussehen, aber programmatisch keine sind
Das sind keine Schönheitsfehler. Das sind Zugangsfehler.
Der Markt der Gewissheit
Dass dieser Markt gerade wächst, ist kein Zufall. Das BFSG erhöht den Druck. Unternehmen wollen „etwas tun“. Und wo Druck herrscht, entsteht ein Angebot – oft nicht als Verbesserung, sondern als Beruhigung. Am liebsten als Satz, der klingt wie ein Feuerlöscher, der sich selbst bedient.
Schauen wir uns diese Sätze an.
Eye-Able ist aktuell omnipräsent und bewirbt sein Assist-Widget mit „Über 25 Funktionen“, „In Minuten installiert“ und: „BITV getestet und barrierefrei zertifiziert“. Das ist Marketing, klar. Und Marketing darf übertreiben, aber bitte nicht bei Grundrechten. Der wichtige Unterschied: Eye-Able formuliert an anderer Stelle selbst, dass „volle Barrierefreiheit“ beziehungsweise „volle rechtliche Konformität“ nur durch Anpassungen am System erreicht werde, also nicht allein durch ein Widget. Man muss sich für diese Aussagen zwar bis in die FAQs begeben und sich nicht von den schönen bunten Bildern und Überschriften ablenken lassen, aber damit ziehen sie eine Grenze: Das Widget kann Zusatzfunktionen bieten, aber es ersetzt nicht die Substanz.
Viele Betreiber*innen kaufen ein Overlay in der Hoffnung, damit „Barrierefreiheit“ als Ganzes einzukaufen. In der Praxis kaufen sie häufig Zusatzfunktionen, nicht automatisch eine barrierefreie Website.
Digi Access setzt noch einen drauf – mit einer Formulierung, die klingt, als könne man Barrierefreiheit wie ein Software‑Update ausrollen: Man „behebt technisch automatisierbare Barrieren direkt auf Websites“ und mache „Fortschritte und verbleibenden Handlungsbedarf transparent“. Das ist, für sich genommen, immerhin genauer als die großen Heilsversprechen: Es gibt Barrieren, die sich technisch automatisiert reduzieren lassen – und es gibt welche, die bleiben. Nur folgt unmittelbar darunter ein Satz, der diese Ehrlichkeit wieder wegwischt: „Wir liefern Lösungen. Keine To‑Do‑Listen.“ Rhetorisch elegant, logisch schwierig: Wer „verbleibenden Handlungsbedarf“ transparent macht, liefert am Ende genau das, was man im Projektalltag To‑do‑Liste nennt – inklusive „empfohlener Maßnahmen“, wie es die Seite selbst beschreibt. Und wenn dann zusätzlich mit „Erfüllung rechtlicher Vorgaben wie WCAG 2.2“ und sogar „automatischer Aktualisierung der WCAG 2.2‑Konformität“ geworben wird, kippt die Sprache wieder in jene Zone, in der Barrierefreiheit weniger nach Nutzung klingt als nach Beruhigung: als könne Konformität im laufenden Betrieb „dauerhaft“ automatisch nachgezogen werden, ohne dass sich Menschen an Design, Code, Content und Tests die Hände schmutzig machen müssen.
Und genau da liegt das wiederkehrende Missverständnis, dass der Markt so gern pflegt:
Ein Widget kann eine Website für manche Nutzer*innen zugänglicher machen, weil es Zusatzfunktionen anbietet. Die spannendere Frage ist aber: Wie nützlich ist das im Alltag – für welche Menschen – und in welchen Situationen? Und welche Erwartung wird bei Kund*innen erzeugt? Denn viele Betreiberinnen und Betreiber kaufen ein Overlay in der Hoffnung, damit „Barrierefreiheit“ als Ganzes einzukaufen. In der Praxis kaufen sie häufig Zusatzfunktionen, nicht automatisch eine barrierefreie Website.
Wer Barrierefreiheit als „fertig“ bewirbt, verschiebt den Maßstab: weg von „Können Menschen das wirklich nutzen?“ hin zu „Können wir das intern abhaken?“ Und genau in diesem Moment geraten Menschen mit Behinderungen zuverlässig in den Hintergrund: Sie werden zur Randbedingung in einem Compliance-Projekt.
Und dann gibt es Formulierungen, die so klingen, als hätte jemand Barrierefreiheit mit einem Plug-in verwechselt:
Barrierefrei Digital aus Landau schreibt: Skript ins Body-Tag einfügen und „Ihre Webseite ist ab sofort barrierefrei. Alle gesetzlichen Anforderungen sind erfüllt.“
„Ab sofort“ klingt einfach wunderbar. Es funktioniert auch bei anderen komplexen Projekten: ab sofort nachhaltig, ab sofort konfliktfrei, ab sofort klimaneutral. Man muss nur irgendwo ein Skript einfügen.
Wawsome schreibt: „Sofortige WCAG 2.1 & 2.2-Konformität für jede Website. In unter 60 Sekunden einsatzbereit. Kein Redesign, kein Code erforderlich.” An späterer Stelle wird dann von „unterstützt die WCAG 2.2 AA-Konformität” gesprochen. Es sind genau diese Art von Details die es manchen Menschen schwer macht, den Unterschied zu erkennen.
Hier ist der Ton nicht nur frech, er wird gefährlich. Denn wer Barrierefreiheit als „fertig“ oder „sofort Konform” bewirbt, verschiebt den Maßstab: weg von „Können Menschen das wirklich nutzen?“ hin zu „Können wir das intern abhaken?“. Und genau in diesem Moment geraten Menschen mit Behinderungen zuverlässig in den Hintergrund: Sie werden zur Randbedingung in einem Compliance-Projekt.
Dass solche Versprechen nicht nur moralisch fragwürdig, sondern auch rechtlich riskant sind, zeigt ein Blick in die USA. Dort warb der Overlay-Anbieter accessiBe mit der Idee, sein „AI“-Produkt könne Websites WCAG-konform machen. Die US-Verbraucherschutzbehörde FTC erließ 2025 eine (zustimmungsbasierte) Anordnung, die accessiBe irreführende Werbeaussagen untersagt und eine Zahlung von 1 Million US-Dollar vorsieht.
Man könnte das als amerikanische Übertreibung abtun. Oder als Hinweis darauf verstehen, dass „macht compliant“ in diesem Feld kein harmloser Slogan ist, sondern eine Behauptung mit Folgen.
Denn die Technik kann diese Gewissheit gar nicht liefern. Selbst dann nicht, wenn alle Beteiligten es ernst meinen.
Selbst in einem künstlichen Labor-Setting bleibt ein großer Teil unsichtbar, wenn man nur automatisiert prüft.
Was wirklich hilft: weniger glamourös, aber wirksam
Wenn man eine Website betreibt und nicht nur ein Symbol einkaufen möchte, führt kein Weg an einer unromantischen Einsicht vorbei: Barrierefreiheit ist Arbeit. Aber sie ist Arbeit, die sich in Schritte zerlegen lässt.
1. Bewusstsein und Wissen in der Organisation aufbauen
Barrierefreiheit scheitert selten am bösen Willen, häufiger an Unkenntnis. Product Owner, Design, Entwicklung, Content: Alle brauchen Basiswissen. Was bedeuten WCAG? Was ist die EN 301 549? Warum gibt es diese Standards, wer hat sie entwickelt und vor allem für wen? Wer das nicht weiß, kann auf der eigenen Website schwer systematisch verbessern, was er nicht benennen kann.
Workshops helfen, Schulungen auch. Zusätzlich Audits von qualifizierten Prüfer*innen und Berater*innen, die nicht nur trockene Prüfberichte ausspucken, sondern mit den Verantwortlichen priorisieren, Lösungswege entwickeln, Verantwortlichkeiten klären.
2. Barrierefreiheit ins Design-System und in die Prozesse integrieren
Nicht „am Ende prüfen“, sondern in Komponenten, Patterns und QA verankern. Wer ein barrierefreies Design-System hat, muss Barrierefreiheit nicht bei jedem Button neu erfinden. Wer Definition-of-Done-Kriterien hat, diskutiert Barrierefreiheit nicht als Extra, sondern als Qualitätsmerkmal.
Automatisierte Tools sind nützlich. Sie finden Muster. Sie geben Hinweise. Sie helfen bei der Priorisierung. Sie können gute Alarmanlagen sein. Nur sind Alarmanlagen kein Brandschutzkonzept.
In einem Audit des britischen Government Digital Service wurden absichtlich Barrieren in eine Testseite eingebaut und dann mit automatisierten Tools geprüft: Das beste Tool fand nur 40%, das schlechteste 13% der eingebauten Probleme. Das ist keine Kleinigkeit, das ist der Kern: Selbst in einem künstlichen Labor-Setting bleibt ein großer Teil unsichtbar, wenn man nur automatisiert prüft.
Wie soll dann ein Widget, das über eine Website gelegt wird, „alle gesetzlichen Anforderungen erfüllen“? Es kann Kontrast anbieten, ja. Es kann Schrift vergrößern. Es kann Vorlesen. Es kann Menschen kurzfristig unterstützen. Aber es kann nicht zuverlässig:
- fehlende Labels im Formular „herzaubern“.
- eine kaputte Tastatur-Navigation reparieren
- Fokuslogik in Modals korrekt nachbauen
- irreführende Fehlermeldungen verständlich machen
- komplexe Interaktionen rechts- und praxistauglich „WCAG-konform“ nachrüsten.
Das sind keine Randfälle. Das sind die Stellen, an denen die Nutzung scheitert und damit die Teilhabe.
Wer mit Betroffenen testet und arbeitet, lernt schneller und lernt das Richtige.
3. Ohne Menschen mit Behinderung geht es nicht
Nicht als symbolische Abnahme, sondern als echte Perspektive im Prozess. Barrieren zeigen sich oft dort, wo Teams sie nicht erwarten: in Fokus-Reihenfolgen, in Fehlermeldungen, in dynamischen Modals, in Texten, die formal korrekt und praktisch unverständlich sind. Wer mit Betroffenen testet und arbeitet, lernt schneller und lernt das Richtige.
Und selbst wenn eine Website formal WCAG-konform wirkt: Menschen sind vielfältig. Bedürfnisse auch. Barrierefreiheit ist mehr als ein Häkchen im Gesetz.
4. Monitoring, wenn die Grundlagen feststehen
Monitoring ist ab einer gewissen Projektgröße sinnvoll bis notwendig. Es macht aber erst dann wirklich Sinn, wenn Barrierefreiheit in den Prozessen etabliert ist. Sonst misst man zuverlässig, dass man kein System hat.
5. Kommunikation nach außen als Service
Wenn etwas nicht funktioniert, ist entscheidend, ob es einen klaren Kontaktweg gibt, ob Rückmeldungen ernst genommen werden, ob sichtbar ist, dass Barrierefreiheit ein Prozess ist und nicht nur ein Symbol.
Und ja: Das gilt nicht nur für Konzerne mit Abteilungen, Budgets und Beauftragten. Auch kleine Organisationen, Vereine, Mittelständler*innen können Barrierefreiheit ernsthaft angehen. Nicht, indem sie „alles“ sofort perfekt machen, sondern indem sie anfangen, systematisch besser zu werden.
Niemand verlangt 100 Prozent Barrierefreiheit über Nacht. Aber Bewusstsein und Wissen in der Organisation sind kein Luxusprojekt. Sie sind der erste Schritt und oft der Schritt, der den Unterschied macht: zwischen einem Icon als Beruhigung und einem Prozess, der wirklich trägt.
Die eigentliche Frage ist eine Haltungsfrage
Am Ende sind Overlays weniger eine Tool-Frage als eine Haltungsfrage: Will ich Teilhabe ermöglichen oder Teilhabe als Feature simulieren? Will ich eine Website bauen, die mit Assistive Technology funktioniert oder will ich Menschen in ein Zusatzmenü schicken?
Ein Overlay kann Ergänzung sein. Es kann Komfort bieten. Es kann, in bestimmten Situationen, helfen. Aber es ist nicht die Substanz. Und wenn es als Abkürzung verkauft oder verstanden wird, werden am Ende die falschen Dinge optimiert: nicht die Nutzung, sondern das Gefühl, etwas getan zu haben.
Vielleicht ist das der ehrlichste Maßstab:
Eine barrierefreie Website erkennt man nicht daran, dass sie ein Barrierefreiheits-Menü hat. Man erkennt sie daran, dass Menschen sie einfach nutzen können ohne erst Barrierefreiheit aktivieren zu müssen.
Weitere interessante Informationen und Fakten zum Thema Overlay Tools findet man auf der Webseite www.overlayfactsheet.com .
