Ein Barrierefreiheits-Overlay ist eine Schicht, die einer Website nachträglich per JavaScript hinzugefügt wird und Besuchern einige Anzeigeeinstellungen bietet. Es kann nützlich sein, behebt jedoch nicht die strukturellen Barrierefreiheitsprobleme im Quellcode der Seite. In diesem Leitfaden erklären wir den Unterschied zwischen dem Overlay-Ansatz und echtem WCAG-2.2-Scannen, die Grenzen von Overlays und einen ehrlichen Weg zur Konformität. Dieser Inhalt stellt keine Rechtsberatung dar.
Ein Barrierefreiheits-Overlay ist eine Schicht, die nachträglich per JavaScript über eine bestehende Website gelegt wird. In der Regel öffnet es eine kleine Schaltfläche und bietet Besuchern einige Anzeigeeinstellungen, etwa das Vergrößern von Text, das Erhöhen des Kontrasts, das Stoppen von Animationen oder eine Lesehilfe. Diese Einstellungen können für manche Nutzer eine praktische Erleichterung sein.
Entscheidend ist, was ein Overlay nicht leistet. Ein Overlay behebt nicht die strukturellen Barrierefreiheitsprobleme, die im Quellcode der Seite vorhanden sind. Ein fehlender Alternativtext, eine fehlerhafte Überschriftenhierarchie, ein nicht beschriftetes Formularfeld, ein unzureichender Farbkontrast oder eine per Tastatur nicht erreichbare Komponente werden durch eine zur Laufzeit darübergelegte Anzeigeschicht nicht dauerhaft behoben. Diese Probleme liegen in der HTML-, CSS- und ARIA-Ebene, also im Quellcode selbst, und dort gehört auch die Lösung hin.
Auf dem Markt gibt es zwei grundlegende Ansätze zur Barrierefreiheit. Sie sind nicht dasselbe und führen nicht zum selben Ergebnis. Im Folgenden vergleichen wir beide sachlich und ohne Übertreibung.
Ein Overlay arbeitet auf der Präsentationsschicht. Es verändert zur Laufzeit das Erscheinungsbild der Seite; es vergrößert Text, kehrt Farben um, stoppt Bewegung. Es ist schnell installiert und hinterlässt eine sichtbare Schaltfläche. Es misst jedoch nicht, meldet keine Verstöße und ändert den Quellcode nicht. Die strukturellen Probleme unter der Seite bleiben bestehen; das Overlay deckt sie lediglich mit einer Anzeigeschicht ab.
Scannen arbeitet auf Code-Ebene. Es prüft die Seite anhand der WCAG-2.2-Erfolgskriterien, erkennt Verstöße und meldet sie nach Schweregrad (kritisch, schwerwiegend, mittel, gering). Die Ausgabe ist keine sichtbare Schaltfläche, sondern ein messbarer Befund: welches Element welches Kriterium wie stark verletzt. Diese Befunde leiten die im Quellcode vorzunehmenden Korrekturen an und ermöglichen es, den Fortschritt mit einer Punktzahl zu verfolgen.
Beide sind keine Gegensätze, sondern ergänzen sich. Ein gut gestaltetes Widget, das Besuchern nützliche Anzeigeeinstellungen bietet, ist wertvoll; ein Overlay allein ersetzt jedoch nicht die erforderliche Messung und die Korrekturen im Quellcode. Sinnvolle Barrierefreiheitsarbeit beginnt mit dem Scannen.
Die Barrierefreiheits-Community und Fachleute weisen seit Langem darauf hin, dass automatische Overlays allein keine WCAG-Konformität schaffen. Der Grund ist struktureller Natur: Da ein Overlay nicht misst und den Quellcode nicht ändert, löst es die zugrunde liegenden Verstöße nicht. Darüber hinaus kann das Overlay in manchen Fällen selbst mit assistiver Technologie, etwa Screenreadern, in Konflikt geraten und ein bereits funktionierendes Erlebnis stören. Aus diesem Grund sollte ein Overlay nicht als Ausgangspunkt eines Barrierefreiheitsprogramms gelten, sondern höchstens als dessen Ergänzung.
Dies hat auch auf regulatorischer Ebene konkrete Form angenommen. Im Jahr 2025 verhängte die US-Handelskommission (FTC) gegen den Overlay-Anbieter accessiBe ein Bußgeld von 1 Million USD wegen irreführender Behauptungen, sein automatisches Werkzeug mache Websites WCAG-konform. Dies ist eine öffentliche, konkrete Entscheidung, die zeigt, dass die Behauptung, ein automatisches Werkzeug schaffe allein Konformität, von einer Behörde zurückgewiesen wurde. Quelle: ftc.gov.
Sinnvolle Barrierefreiheit schreitet nicht über eine Schaltfläche voran, sondern über einen messbaren Kreislauf. Die vier Schritte sind ein wiederkehrender Prozess, keine einmalige Aufgabe.
Scannen Sie die Seite anhand der WCAG-2.2-Erfolgskriterien. Automatisches Scannen deckt maschinell erkennbare Verstöße auf, etwa fehlende Alternativtexte, Kontrastprobleme, nicht beschriftete Formularfelder und eine fehlerhafte Überschriftenstruktur. Das ist eine objektive Momentaufnahme des aktuellen Zustands.
Melden Sie die Verstöße nach Schweregrad: kritisch, schwerwiegend, mittel, gering. Diese Reihenfolge erlaubt es, begrenzte Zeit für die wirkungsvollsten Probleme einzusetzen. Eine Konformitätspunktzahl (0-100) macht den Fortschritt über die Zeit messbar.
Hier liegt die eigentliche Arbeit. Die erkannten Verstöße werden in der HTML-, CSS- und ARIA-Ebene, also im Quellcode, behoben: fehlender Alternativtext wird ergänzt, die Überschriftenhierarchie korrigiert, Formularfelder beschriftet, der Kontrast behoben. Keine Laufzeitschicht erledigt das dauerhaft für Sie.
Dokumentieren Sie Ihre Arbeit mit einer Barrierefreiheitserklärung. Nach EAA Artikel 13 beschreibt eine Erklärung transparent Ihren Konformitätsstatus, bekannte Einschränkungen und einen Feedback-Kanal. Die Erklärung macht das Ergebnis des Prozesses sichtbar und nachvollziehbar.
cerez.io garantiert keine vollständige WCAG-Konformität; es misst Ihre Situation, meldet Verstöße und hilft, sie mit einer Erklärung zu dokumentieren. Unser Ansatz ist kein Overlay; er beruht auf einem echten WCAG-2.2-Scanner und einem echten Barrierefreiheits-Widget, das in einem Shadow DOM läuft.
Die Plattform scannt Ihre Website anhand der WCAG-2.2-Erfolgskriterien, erkennt Verstöße nach Schweregrad (kritisch, schwerwiegend, mittel, gering) und erstellt eine Konformitätspunktzahl von 0 bis 100 mit einem priorisierten Verstoßbericht. Damit wird der Mess- und Berichtsschritt abgedeckt, den ein Overlay nicht leistet.
VerfügbarDas echte Barrierefreiheits-Widget läuft isoliert in einem Shadow DOM. Es zerstört das CSS der Host-Website nicht und greift nicht in die Seitenstruktur ein. Es bietet Besuchern mehr als 40 Funktionen und mehr als 10 Profile; das ist eine kontrollierte, isolierte Komponente, keine oberflächliche Anzeigeschicht.
VerfügbarDie Plattform hilft Ihnen, die Barrierefreiheitserklärung nach EAA Artikel 13 zu erstellen: Konformitätsstatus, bekannte Einschränkungen und einen Feedback-Kanal. Damit wird das letzte Glied des vierstufigen Prozesses, die Dokumentation, abgeschlossen.
VerfügbarScannen Sie Ihre Website anhand von WCAG 2.2, sehen Sie Verstöße nach Schweregrad, fügen Sie das Shadow-DOM-Widget hinzu und beginnen Sie mit der Erstellung Ihrer EAA-Erklärung. Einrichtung in 5 Minuten.