Die Wahl zwischen einem Accessibility-Overlay und einer manuellen Behebung ist eine der folgenreichsten Entscheidungen, die Website-Betreiber im Jahr 2025 treffen können. Dieser Leitfaden legt genau dar, was jeder Ansatz leistet, wo jeder an seine Grenzen stößt und wie zukunftsorientierte Teams beide kombinieren, um wirklich inklusive und rechtlich belastbare Websites zu erstellen.

Im Jahr 2024 führten 25% aller Klagen zur digitalen Barrierefreiheit in den Vereinigten Staaten – über 1.000 Fälle – Barrierefreiheits-Overlay-Widgets ausdrücklich als Hindernisse statt als Lösungen an. Im selben Jahr verhängte die Federal Trade Commission gegen einen der größten Overlay-Anbieter der Branche wegen irreführender Werbung eine Geldstrafe von 1 Million $. Dennoch verlassen sich Millionen von Websites weiterhin auf ein schwebendes Symbol einer Toolbar als ihre primäre Barrierefreiheitsstrategie. Wenn Sie Website-Eigentümer, Entwickler oder Compliance-Manager sind und versuchen, die Debatte „Overlays versus Remediation“ zu verstehen, ist dieser Leitfaden für Sie: kein Hype, kein Anbietermarketing – nur ein rigoroser Blick darauf, was jeder Ansatz tatsächlich leistet, wo er wirklich hilft und wie Sie eine Strategie aufbauen, die vor Gericht Bestand hat und vor allem für echte Nutzer mit Behinderungen tatsächlich funktioniert.

Was sind Accessibility Overlays und wie funktionieren sie?

Accessibility Overlays – auch Accessibility Widgets oder Toolbars genannt – sind JavaScript-basierte Produkte, die über eine bestehende Website geladen werden. Sie präsentieren den Nutzern typischerweise ein Bedienfeld mit Optionen wie Textvergrößerung, Hochkontrastmodus, Vergrößerung des Cursors und verschiedenen Behinderungs-„Profilen“ (z. B. ein Screenreader-Modus oder ein Umschalter für eine dyslexiefreundliche Schriftart). Eine zweite Kategorie von Overlay-Funktionalität versucht, Barrierefreiheitsfehler im Hintergrund automatisch zu erkennen und zu beheben, ohne jegliche Nutzerinteraktion, mithilfe regelbasierter Automatisierung oder KI.

Die Attraktivität liegt auf der Hand. Die Installation bedeutet typischerweise, dass ein einzelnes Script-Tag in das <head>-Element Ihrer Website eingefügt wird, und die Abonnementkosten beginnen bereits bei 49–500 $ pro Monat. Für eine kleine Unternehmerin oder einen kleinen Unternehmer, die oder der gerade ein Abmahnschreiben erhalten hat und schnell handeln muss, ist das Angebot unwiderstehlich: eine Codezeile, sofortige Bereitstellung und ein Konformitätszertifikat für das eigene Rechtsteam. Die Realität, wie wir ausführlich untersuchen werden, ist weitaus komplexer.

Es ist wichtig, zwischen zwei sehr unterschiedlichen Dingen zu unterscheiden, die oft unter dem Label „Overlay“ zusammengefasst werden. Erstens gibt es nutzerseitige Einstellungskontrollen – Werkzeuge, mit denen Besucher Textgröße, Farbkontrast, Bewegungsreduktion und ähnliche Anzeigeeinstellungen anpassen können. Diese haben für viele Nutzer einen echten Nutzen und sind eine durchdachte Erweiterung, wenn sie auf einer bereits barrierefreien Website aufbauen. Zweitens gibt es automatisierte Compliance-Reparatur-Tools – Produkte, die behaupten, WCAG-Verstöße automatisch zu erkennen und zu beheben, ohne den zugrunde liegenden Quellcode zu verändern. Diese zweite Kategorie hat regulatorische Maßnahmen, Massenklagen und nahezu einhellige Verurteilung durch die Community der Barrierefreiheitsprofis auf sich gezogen. Diese Unterscheidung zu verstehen, ist von enormer Bedeutung, wenn man ein Produkt in diesem Bereich bewertet.

Was ist manuelle Remediation?

Manuelle Remediation bezeichnet den Prozess, systematisch Barrierefreiheitsfehler im tatsächlichen Quellcode einer Website zu identifizieren und sie direkt zu beheben – in HTML, CSS, JavaScript und allen zugrunde liegenden Templates oder Komponenten. Sie beginnt mit einem Accessibility Audit: einer strukturierten Überprüfung, die automatisierte Scantools (die einen Teil der erkennbaren Probleme schnell aufdecken können) mit Tests durch Expertinnen und Experten kombiniert, die tatsächliche unterstützende Technologien wie JAWS, NVDA, VoiceOver und Switch-Access-Geräte einsetzen.

Der Audit erzeugt einen detaillierten Bericht, der jeden Fehler dokumentiert, den jeweiligen WCAG-2.1- oder 2.2-Erfolgskriterien zuordnet und Schweregrade sowie Remediationsempfehlungen enthält. Entwickler setzen die Korrekturen dann direkt im Code-Repository um: Sie fügen Formularfeldern korrekte <label>-Zuordnungen hinzu, korrigieren die Überschriftenhierarchie, stellen sicher, dass interaktive Elemente zugängliche Namen haben, implementieren korrekte ARIA-Rollen und -Zustände für dynamische Komponenten, korrigieren Farbkontrastwerte, fügen aussagekräftigen Alternativtext hinzu und so weiter. Nachdem die Korrekturen implementiert wurden, validiert eine zweite Testrunde – einschließlich erneuter Tests mit Nutzern unterstützender Technologien – die Änderungen.

Dieser Prozess dauert länger und kostet anfangs mehr als die Installation eines Widgets. Professionelle Accessibility Audits für eine Website mittlerer Größe liegen typischerweise zwischen 2.500 und 20.000 $, und die technische Remediation kann je nach Komplexität weitere 5.000 bis 20.000 $ hinzufügen. Laufende Wartung – automatisiertes Monitoring kombiniert mit regelmäßigen manuellen Re-Audits – schlägt mit 200 bis 2.000 $ pro Monat zu Buche. Diese Zahlen können im Vergleich zu einem Overlay-Abonnement von 99 $ pro Monat hoch erscheinen. Aber wie wir sehen werden, sieht der Kostenvergleich ganz anders aus, wenn man das rechtliche Risiko, die Dauerhaftigkeit der Lösung und den tatsächlichen Gegenwert berücksichtigt.

Das zentrale technische Problem von Overlays

Die grundlegende Einschränkung jedes Overlay-Tools ist architektonischer Natur, und keine noch so große KI-Raffinesse kann sie vollständig überwinden: Overlays injizieren JavaScript, das den gerenderten DOM nach dem Laden einer Seite verändert, aber Screenreader und andere unterstützende Technologien parsen den HTML-Quellcode zum Ladezeitpunkt – bevor dieses JavaScript ausgeführt wird. Das bedeutet, dass viele „Korrekturen“, die ein Overlay vornimmt, für genau die unterstützenden Technologien unsichtbar sind, die das Produkt angeblich unterstützen soll.

Selbst wenn man dieses Timing-Problem außer Acht lässt, können automatisierte Erkennungstools – einschließlich der fortschrittlichsten KI-gestützten Overlays – realistisch nur etwa 30% der Verstöße gegen WCAG-Erfolgskriterien identifizieren. Die verbleibenden 70% der Probleme erfordern menschliches Urteilsvermögen: etwa zu beurteilen, ob der Alternativtext eines Bildes im Kontext sinnvoll ist (nicht nur vorhanden), ob die Beziehungen in einer komplexen Datentabelle korrekt vermittelt werden, ob ein ARIA-Live-Region-Attribut korrekt verwendet wird oder ob ein mehrstufiger Formularablauf tatsächlich per Tastatur navigierbar ist. Ein Overlay kann einem Bild ein alt-Attribut hinzufügen; es kann jedoch nicht zuverlässig bestimmen, ob der von ihm generierte Text dieses Bild im Kontext korrekt beschreibt.

Bestimmte Kategorien von Problemen können Overlays strukturell nicht beheben, darunter:

Fehler in semantischem HTML – Verwendung von <div>, wo ein <button> erforderlich wäre, oder eine fehlerhafte Überschriftenhierarchie, die in ein Template eingebrannt ist
Fehlende oder falsche Formularbeschriftungen – korrekte Label-Zuordnungen müssen im Quellmarkup vorhanden sein
Fokusmanagement in dynamischen Inhalten – Modale, Karussells und Routenwechsel in Single-Page-Apps erfordern Implementierung auf Code-Ebene
Videountertitel und Audiodeskriptionen – die Barrierefreiheit von Inhalten kann nicht durch eine JavaScript-Schicht hinzugefügt werden
PDF- und Dokumentenbarrierefreiheit – vollständig außerhalb des Anwendungsbereichs eines Web-Overlays
In CSS verankerter Farbkontrast – ein Overlay kann einen Kontrast-Umschalter anbieten, aber es kann das Designsystem Ihrer Marke nicht für Nutzer ändern, die nicht wissen, dass sie es aktivieren müssen

Konformität mit WCAG bedeutet, alle anwendbaren Erfolgskriterien auf einem bestimmten Level zu erfüllen. Da Overlays nachweislich nicht in der Lage sind, das gesamte Spektrum dieser Kriterien abzudecken, können sie die Compliance, die sie versprechen, nicht liefern – unabhängig davon, wie ausgefeilt ihre KI angeblich ist.

Die rechtliche Realität: Overlays ziehen Klagen an, sie verhindern sie nicht

Die Klagedaten erzählen eine konsistente Geschichte. Im Jahr 2023 wurden über 900 Unternehmen, die Accessibility Widgets nutzten, verklagt – ein Anstieg um 62% gegenüber dem Vorjahr. 2024 stieg diese Zahl auf über 1.000 und machte etwa 25% aller in diesem Jahr eingereichten Klagen zur Web-Barrierefreiheit aus. Allein in der ersten Hälfte des Jahres 2025 richteten sich 456 Klagen gegen Websites, auf denen Accessibility Widgets installiert waren, was 22,64% aller ADA-Fälle in diesem Zeitraum ausmachte – und die monatliche Rate overlay-spezifischer Klagen lag konstant höher als im gleichen Zeitraum 2024.

Ein Teil des Grundes, warum Overlays eher Klagen anziehen, als sie zu verhindern, liegt darin, wie Kanzleien auf Klägerseite arbeiten. Tools wie BuiltWith machen es trivial, zu identifizieren, welche Websites bestimmte Overlay-Produkte verwenden. Klägeranwälte wissen aus umfangreicher Erfahrung, dass eine Website mit Overlay sehr wahrscheinlich weiterhin schwerwiegende zugrunde liegende WCAG-Verstöße enthält – weil das Overlay sie nicht beheben kann. Die Präsenz des Widgets fungiert zudem als Beleg dafür, dass sich das Unternehmen seiner Barrierefreiheitsverpflichtungen bewusst war, was die Rechtsposition der Klägerseite sogar stärken kann, indem es nahelegt, dass sich das Unternehmen für eine unzureichende Abkürzung entschieden hat, statt in gutem Glauben zu handeln.

Gerichte waren eindeutig. In der Einigung in LightHouse for the Blind v. ADP, Inc. wurde ausdrücklich festgehalten, dass „Overlay-Lösungen nicht ausreichen, um Barrierefreiheit zu erreichen“, und ADP verpflichtet, echte Remediation auf Quellcode-Ebene zu verfolgen. In Murphy v. Eyebobs verlangte der Vergleich vollständige WCAG-2.1-Konformität, eine Accessibility-Beratung und interne Schulungen des Personals – genau die Dinge, die ein Overlay eigentlich überflüssig machen sollte. Im April 2025 kam die FTC in ihrer endgültigen Anordnung gegen accessiBe, in deren Rahmen das Unternehmen mit 1 Million $ belegt wurde, zu dem Schluss, dass seine Compliance-Behauptungen „nicht durch kompetente und verlässliche Belege gestützt“ seien. Dies sind keine Ausreißer; sie stehen für einen klaren rechtlichen Konsens, dass die Simulation von Barrierefreiheit nicht dasselbe ist wie ihre tatsächliche Erreichung.

Das europäische Bild ist ebenso klar. Der European Accessibility Act, der im Juni 2025 vollständig in Kraft trat, verlangt WCAG-2.1-AA-Konformität für digitale Produkte und Dienstleistungen, die innerhalb der EU verkauft werden. Die Europäische Kommission hat öffentlich erklärt, dass Accessibility Overlays – ob KI-gestützt oder nicht – keinen gültigen Weg zur WCAG-Konformität darstellen. Für Organisationen, die in EU-Märkten tätig sind oder in diese verkaufen, bergen Overlay-Only-Strategien zusätzlich zum Klagerisiko auch regulatorische Risiken.

Wo Overlays dennoch echten Mehrwert bieten können

Angesichts all dessen wäre es intellektuell unehrlich zu behaupten, Overlays hätten keinerlei legitime Rolle. Die haben sie – aber nur in einem spezifischen, gut verstandenen Kontext: als ergänzende Nutzereinstellungsschicht, die auf einer bereits barrierefreien Website aufsetzt.

Nutzerseitige Kontrollen für Textgröße, Kontrasteinstellung, Bewegungsreduktion, Zeilenabstand und Schriftartwechsel bieten echten Nutzen für Nutzer mit Sehbeeinträchtigungen, kognitiven Behinderungen, Photosensitivität oder Leseschwierigkeiten, die ihre Erfahrung über das hinaus anpassen möchten, was das Betriebssystem bereitstellt. Diese Funktionen werden dann wirklich wertvoll, wenn die Basiserfahrung bereits barrierefrei ist – weil sie die Nutzbarkeit erweitern, statt zu versuchen, grundlegende strukturelle Mängel zu kompensieren.

Overlays können auch während einer Remediation-Übergangsphase eine legitime Rolle spielen. Wenn Sie eine große, komplexe Website haben und einen realistischen Zeitrahmen von 6–12 Monaten, um eine vollständige Remediation auf Quellcode-Ebene abzuschließen, kann ein Overlay, das parallel zu aktiven Remediation-Arbeiten eingesetzt wird, einige oberflächliche Probleme adressieren, während die tiefergehende Arbeit im Gange ist – vorausgesetzt, es wird als temporäre Brücke verstanden, nicht als Ziel. Das Risiko liegt hier in der organisatorischen Trägheit: Die Präsenz eines Widgets kann falsches Vertrauen schaffen und die eigentliche Arbeit verlangsamen, wenn Stakeholder glauben, das Problem sei bereits gelöst.

Das Accsible SDK ist als widgetbasiertes Tool mit dieser Philosophie im Hinterkopf konzipiert: Es bietet nutzerkonfigurierbare Accessibility-Kontrollen und Erweiterungsfunktionen, die die bestehende Barrierefreiheitsbasis einer Website ergänzen und den Nutzern eine sinnvolle Kontrolle über ihre Erfahrung geben. Die Unterscheidung zwischen Erweiterung und Ersatz ist die entscheidende. Ein Overlay, das einem Nutzer, der Ihre Website bereits navigieren kann, hilft, dies komfortabler zu tun, ist kategorisch etwas anderes als ein Overlay, das behauptet, Ihre nicht barrierefreie Website sei nun konform.

Manuelle Remediation: Vorteile, Nachteile und Ablauf

Der entscheidende Vorteil manueller Remediation ist, dass sie tatsächlich funktioniert. Korrekturen auf Quellcode-Ebene adressieren prinzipiell 100% der WCAG-Erfolgskriterien – einschließlich komplexer interaktiver Muster, Video-Barrierefreiheit, Dokumenten-Remediation und der semantischen Strukturprobleme, die kein automatisiertes Tool erfassen kann. Die Korrekturen sind dauerhaft: Sie hängen nicht davon ab, dass auf jeder Seite ein Drittanbieter-Script geladen wird, sie erzeugen keine Datenschutzbedenken durch das Tracking von Nutzereinstellungen und sie kollidieren nicht mit den Konfigurationen unterstützender Technologien, die Nutzer mit Behinderungen sorgfältig für ihre eigenen Workflows angepasst haben.

Aus rechtlicher Sicht ist manuelle Remediation der einzige Ansatz, der Gerichte und Regulierungsbehörden konsequent überzeugt hat. Ein datiertes Konformitätszertifikat, ein detaillierter VPAT (Voluntary Product Accessibility Template) und dokumentierte Audit- und Remediation-Unterlagen stellen die bestmögliche Good-Faith-Compliance-Verteidigung in einem Rechtsstreit dar. Organisationen, die ein strukturiertes, von Expertinnen und Experten geführtes Barrierefreiheitsprogramm nachweisen können, befinden sich in einer grundlegend anderen rechtlichen Position als solche, die sich auf ein Widget-Abonnement verlassen.

Die ehrlichen Nachteile manueller Remediation sind jedoch real. Kosten und Zeit sind die Hauptbarrieren. Ein gründlicher Audit einer 50-seitigen Unternehmenswebsite kann 8.000–20.000 $ kosten, wobei die Remediation je nach technischem Schuldenstand weitere 10.000–30.000 $ hinzufügen kann. Große Unternehmensanwendungen können in den sechsstelligen Bereich gehen. Für kleine Unternehmen und Startups kann diese Investition unerschwinglich erscheinen – und genau diese Lücke nutzen Overlay-Anbieter mit ihrer Positionierung als kostengünstiges Monatsabonnement aus.

Manuelle Remediation erfordert zudem laufende Investitionen. Websites sind nicht statisch: Neue Inhalte, Funktionsupdates, Design-Refreshes und Drittanbieter-Integrationen bringen regelmäßig neue Barrierefreiheitsprobleme mit sich. Ein einmaliges Remediation-Projekt ohne laufendes Monitoring- und Wartungsprogramm wird innerhalb weniger Monate zu einem Compliance-Drift führen. Die effektivsten Organisationen behandeln Barrierefreiheit wie Sicherheit: als kontinuierliche Disziplin, nicht als einmaliges Projekt.

Eine praktische Accessibility-Strategie aufbauen: beide Ansätze kombinieren

Die Darstellung von „Overlay versus manuelle Remediation“ als binäre Wahl verfehlt, was kluge Organisationen tatsächlich tun. Die am besten vertretbaren und effektivsten Barrierefreiheitsstrategien nutzen automatisierte Tools strategisch – als Infrastruktur für Erkennung und Monitoring, nicht als Compliance-Abkürzung – und verankern alles in Korrekturen auf Quellcode-Ebene.

Hier ist ein praktischer Rahmen für unterschiedliche organisatorische Situationen:

Kleines Unternehmen mit begrenztem Budget: Beginnen Sie mit einem automatisierten Scan, um die wirkungsstärksten Probleme zu identifizieren, priorisieren Sie die Behebung kritischer Barrieren im Quellcode (Formularlabels, Tastaturnavigation, fehlender Alternativtext, Farbkontrast) und nutzen Sie ein Nutzereinstellungs-Overlay als wertsteigernde Ergänzung – nicht als Ihre Compliance-Strategie. Dokumentieren Sie jeden Schritt, den Sie unternehmen.
Mid-Market-Organisation mit Compliance-Deadline: Beauftragen Sie sofort einen vollständigen manuellen Audit. Beginnen Sie parallel mit der Remediation kritischer und schwerwiegender Probleme. Nutzen Sie automatisiertes Monitoring, um Regressionen zwischen Auditzyklen zu verfolgen. Ein Overlay kann als temporäre Lückenmaßnahme bei bestimmten bekannten Problemen dienen, während Ihr Entwicklungsteam den Remediation-Backlog abarbeitet – setzen Sie jedoch eine klare Deadline für die Entfernung oder Umklassifizierung.
Enterprise oder regulierte Branche (Gesundheitswesen, Finanzwesen, Regierung): Manuelle Remediation ist nicht verhandelbar. Verankern Sie Barrierefreiheit von der Designphase an in Ihrem SDLC (Software Development Lifecycle). Führen Sie vierteljährliche automatisierte Scans und jährliche vollständige manuelle Audits mit Tests durch Nutzer unterstützender Technologien durch. Ein Nutzereinstellungs-Widget kann eine durchdachte UX-Ergänzung sein, trägt aber nichts zur Compliance bei.
E-Commerce: E-Commerce-Websites machen 77% aller Klagen zur Web-Barrierefreiheit aus. Checkout-Flows, Produktseiten, Formulare und dynamische Warenkorb-Interaktionen sind alles Bereiche mit hohem Klagerisiko, die Overlays nicht zuverlässig adressieren können. Remediation auf Quellcode-Ebene ist hier besonders kritisch, und laufendes Monitoring ist unerlässlich, da Produkt- und Warenkorbkomponenten häufig aktualisiert werden.

Einer der am meisten übersehenen Bestandteile einer nachhaltigen Accessibility-Strategie ist die Schulung der Entwickler. Wenn Ihr Team von Anfang an semantisches HTML, ARIA-Best Practices, Fokusmanagement und Muster für Tastaturnavigation versteht, sinken die Remediation-Kosten mit jedem weiteren Entwicklungszyklus drastisch. Die Organisationen, die langfristig am wenigsten für Barrierefreiheit ausgeben, sind diejenigen, die Barrierefreiheitswissen in ihre Entwicklungskultur eingebettet haben – nicht diejenigen, die das Problem an ein Drittanbieter-Script ausgelagert haben.

Wesentliche Erkenntnisse

Overlays können allein keine WCAG-Konformität erreichen. Automatisierte Tools können höchstens 30–40% der WCAG-Probleme erkennen, und Screenreader parsen den Quellcode, bevor Overlay-JavaScript ausgeführt wird – wodurch viele „Korrekturen“ für unterstützende Technologien unsichtbar bleiben. Gerichte, die FTC, die Europäische Kommission und über 800 Barrierefreiheitsprofis sind alle zum gleichen Schluss gekommen.
Der Einsatz eines Overlays ohne zugrunde liegende Remediation erhöht Ihr rechtliches Risiko, statt es zu senken. Im Jahr 2024 richteten sich 25% aller US-Klagen zur Web-Barrierefreiheit ausdrücklich gegen Websites, die Widgets verwendeten. Klägeranwälte scannen aktiv nach Overlay-Implementierungen als Klageziele, und Gerichte haben entschieden, dass die Installation eines Widgets kein Beleg für Good-Faith-Compliance ist.
Manuelle Remediation ist der einzige Weg zu echter, rechtlich belastbarer Compliance. Korrekturen auf Quellcode-Ebene sind dauerhaft, decken das gesamte Spektrum der WCAG-Erfolgskriterien ab und erzeugen die Dokumentation (Auditberichte, VPATs, Remediation-Unterlagen), die in rechtlichen und regulatorischen Kontexten tatsächlich Bestand hat.
Overlays haben eine legitime Rolle als Nutzereinstellungs-Erweiterungen – Textgröße, Kontrastkontrollen, Bewegungsreduktion – wenn sie auf einer bereits barrierefreien Website eingesetzt werden. Das Problem ist, sie als Ersatz für Barrierefreiheit zu verwenden, nicht als Ergänzung dazu.
Die kosteneffektivste Accessibility-Strategie ist proaktiv und kontinuierlich. Investitionen in Barrierefreiheit während der Entwicklung sind dramatisch günstiger als Remediation unter rechtlichem Druck. Integrieren Sie Monitoring in Ihren Workflow, schulen Sie Ihre Entwickler und behandeln Sie Barrierefreiheit als laufendes Programm – nicht als Checkbox, die Sie einmal abhaken und dann vergessen.

Barrierefreiheits-Overlay vs. manuelle Behebung: Vor- und Nachteile und wann man welche Methode einsetzen sollte