Der Cookie-Banner ist auf den meisten Websites das erste Element, mit dem Besucherinnen und Besucher in Kontakt kommen, oft noch bevor ein einziger Inhalt sichtbar wird. Genau dieser Consent-Dialog wird bei Barrierefreiheitsprüfungen regelmäßig übersehen, obwohl er technisch ein interaktives Modul mit Buttons, Kontrollkästchen und Fokusverhalten ist. Im WebAIM-Million-Report 2025 wiesen 94,8 Prozent (WebAIM Million 2025) der untersuchten Startseiten nachweisbare WCAG-2-Fehler auf, viele davon in genau solchen Bedienelementen. Sobald der Zugang zur Seite an die Zustimmung gekoppelt ist, wird der Banner zum Türsteher der gesamten Dienstleistung. Dieser Beitrag zeigt, woran Consent-Banner nach WCAG 2.2 AA scheitern und wie ein WCAG-2.2-Audit die typischen Fehler aufdeckt, bevor die Marktüberwachung sie beanstandet.
Wann ein Cookie-Banner unter das BFSG fällt
Das Barrierefreiheitsstärkungsgesetz (BFSG) verlangt, dass die digitale Dienstleistung selbst barrierefrei ist, also die Website, der Online-Shop oder die App. Der Consent-Dialog ist ein Teil dieser Benutzeroberfläche und nicht davon zu trennen. Technisch stützt sich das BFSG auf die harmonisierte Norm EN 301 549, die für Web-Inhalte auf die Erfolgskriterien der WCAG verweist (BFSG). Ein Banner, das die WCAG-Kriterien verletzt, ist damit eine Barriere innerhalb einer ansonsten geprüften Seite. Wie die Anforderungen des BFSG im Detail aussehen und warum die Norm EN 301 549 hinter dem BFSG den Prüfmaßstab liefert, ordnen wir in eigenen Beiträgen ein.
Besonders deutlich wird die Tragweite, wenn der Zugang an die Zustimmung gekoppelt ist. Bei einer Cookie-Wall oder einem bezahlten werbefreien Modell nach dem Muster Zustimmen oder Bezahlen kommt niemand am Dialog vorbei. Wer den Banner dann nicht mit der Tastatur oder einem Screenreader bedienen kann, ist von der gesamten Dienstleistung ausgeschlossen, nicht nur von einer Zusatzfunktion. Aus einem übersehenen Detail wird so eine harte Zugangsbarriere, die im Prüffall schwer wiegt.
Der Prüfmaßstab liegt fest
Die typischen Barrieren im Consent-Banner
Consent-Banner scheitern selten an einem einzigen groben Fehler, sondern an einer Summe kleiner Versäumnisse. Sechs Muster begegnen uns in Audits besonders häufig. Jedes lässt sich einem konkreten Erfolgskriterium der WCAG 2.2 zuordnen, was die Behebung planbar macht.
Fehlende Fokus-Falle
Ein modaler Banner sollte den Tastaturfokus im Dialog halten, bis eine Auswahl getroffen ist. Fehlt diese Falle, wandert der Fokus hinter den offenen Dialog (WCAG 2.4.3, 2.4.11).
Nicht per Tastatur erreichbar
Buttons und Schalter, die nur per Maus funktionieren, sperren alle aus, die mit der Tastatur navigieren. Das verletzt das grundlegende Kriterium der Tastaturbedienbarkeit (WCAG 2.1.1).
Kontrast unter 4,5:1
Blasse Button-Beschriftungen, graue Kategorie-Labels und dünne Hilfetexte unterschreiten oft die Mindestwerte für Textkontrast (WCAG 1.4.3).
Keine Screenreader-Ansage
Ohne role=dialog, ohne Beschriftung und ohne Fokusübergabe bleibt der Banner für Screenreader stumm oder verwirrend (WCAG 4.1.2, 1.3.1).
Ablehnen schwächer gewichtet
Ist Ablehnen kleiner, blasser oder tiefer versteckt als Zustimmen, entsteht eine ungleiche Gewichtung, die auch datenschutzrechtlich beanstandet wird (EDPB).
Zu kleine Ziele
Winzige Schalter und Schließen-Symbole sind für motorisch eingeschränkte Nutzer schwer zu treffen. WCAG 2.2 fordert eine Mindest-Zielgröße (WCAG 2.5.8).
Kontrast: 4,5:1 auf Buttons, Labels und Hilfetexten
Zu geringer Textkontrast ist die mit Abstand häufigste Barriere im Web: Der WebAIM-Million-Report 2025 fand ihn auf 79,1 Prozent (WebAIM Million 2025) der geprüften Startseiten, im Schnitt 29,6 (WebAIM Million 2025) einzelne Vorkommen pro Seite. Consent-Banner sind ein Hauptschauplatz dafür, weil ihre Gestaltung oft auf dezente Zurückhaltung setzt: hellgraue Ablehnen-Buttons, blasse Kategorie-Beschriftungen und dünn gesetzte Erläuterungstexte. Was zurückhaltend wirken soll, unterschreitet damit häufig die Lesbarkeitsschwelle.
Die WCAG 2.2 AA setzt klare Werte an: normaler Text braucht ein Kontrastverhältnis von mindestens 4,5:1 (W3C Web Accessibility Initiative), großer Text von mindestens 3:1. Für grafische Bedienelemente wie Umrandungen von Schaltern, Kontrollkästchen und den Fokusrahmen gilt nach Erfolgskriterium 1.4.11 ein Mindestwert von 3:1 (W3C Web Accessibility Initiative). Diese Werte lassen sich messen, sie sind keine Frage des Geschmacks. Ein sauber gepflegtes Design-System, das Kontraste als Tokens hinterlegt, verhindert den Fehler an der Wurzel; wie stark Farbkontraste über die Lesbarkeit entscheiden, zeigt die Praxis täglich.
Kontrast ist messbar, nicht Geschmackssache
Tastatur und Fokus: Falle statt Sackgasse
Wer nicht mit der Maus arbeitet, bewegt sich mit der Tab-Taste durch die Seite. Erfolgskriterium 2.1.1 verlangt, dass jede Funktion per Tastatur erreichbar ist, Kriterium 2.1.2, dass die Tastatur nirgends in einer Falle stecken bleibt (W3C Web Accessibility Initiative). Ein Consent-Banner muss beides zugleich leisten: Innerhalb des offenen Dialogs soll der Fokus zwischen den Bedienelementen kreisen und nicht in die dahinterliegende Seite entkommen, doch dieser Kreis darf keine echte Sackgasse sein, aus der die Auswahl-Buttons nicht mehr erreichbar sind. Wie leer ausgezeichnete Schaltflächen die Bedienung sabotieren, zeigen die WebAIM-Zahlen: leere Buttons auf 29,6 Prozent (WebAIM Million 2025) und leere Links auf 45,4 Prozent (WebAIM Million 2025) der Startseiten.
- Nicht fokussierbar: Ein Schließen-Symbol oder Schalter, der nur per Klick reagiert, bleibt für die Tastatur unsichtbar (WCAG 2.1.1).
- Kein sichtbarer Fokus: Ohne deutlichen Fokusrahmen ist nicht erkennbar, welches Element gerade aktiv ist (WCAG 2.4.7).
- Fokus entkommt: Bei fehlender Fokus-Falle springt die Tab-Reihenfolge hinter den Banner in die noch bedienbare Seite dahinter (WCAG 2.4.3).
- Verdeckter Fokus: Ein fixierter Banner überdeckt das fokussierte Element, sodass nicht sichtbar ist, wo man sich befindet (WCAG 2.4.11).
- Escape ohne Wirkung: Der Dialog lässt sich nicht per Tastatur schließen oder mit einer klaren Auswahl verlassen.
Neu in WCAG 2.2: Fokus nicht verdeckt
Screenreader: die richtige Ansage
Ein Screenreader liest nicht das Bild, sondern den Code. Damit der Banner als eigenständiger Dialog erkannt wird, braucht er eine passende Rolle und einen Namen: role=dialog oder ein natives dialog-Element, dazu aria-modal und eine Beschriftung über aria-labelledby, die auf die Überschrift des Banners zeigt. Beim Öffnen sollte der Fokus in den Dialog wandern, damit die Ansage überhaupt beginnt. Fehlt diese Auszeichnung, verletzt der Banner die Kriterien zu Name, Rolle und Wert sowie zu Struktur und Beziehungen (WCAG 4.1.2, 1.3.1).
Ein zweiter blinder Fleck sind die Kategorie-Schalter. Kontrollkästchen für Statistik, Marketing oder Komfort brauchen eine programmatisch verknüpfte Beschriftung, sonst hört die Nutzerin nur Kontrollkästchen aktiviert, ohne zu wissen, wofür. Fehlende Formularbeschriftungen sind laut WebAIM auf 48,2 Prozent (WebAIM Million 2025) der Startseiten vorhanden und damit einer der häufigsten Fehler überhaupt. Wie Screenreader-Optimierung und barrierefreie Formulare im Detail funktionieren, vertiefen wir in eigenen Beiträgen; im Consent-Banner gelten dieselben Regeln wie in jedem anderen Formular.
Eine Website ist nur dann barrierefrei, wenn sie die Anforderungen auch ohne nachträgliches Hilfswerkzeug erfüllt. Das gilt für den Consent-Dialog genauso wie für den Rest der Seite.
Ablehnen so leicht wie Zustimmen
An dieser Stelle treffen sich Barrierefreiheit und Datenschutz. Der Europäische Datenschutzausschuss hält in seinen Leitlinien zu manipulativem Design fest, dass Zustimmen und Ablehnen mit gleicher visueller Gewichtung auf derselben Ebene angeboten werden müssen (EDPB). Ein Reject-Button, der kleiner, blasser oder erst nach mehreren Klicks erreichbar ist, gilt als irreführendes Muster. Für die Barrierefreiheit hat dieselbe Gestaltung eine zweite Folge: Der blasse Ablehnen-Button unterschreitet den Kontrastwert, und der versteckte Pfad verlängert den Tastaturweg. Wer die Gleichwertigkeit ernst nimmt, erfüllt beide Regelwerke in einem Zug.
Gleichwertigkeit prüfen
Prüfkriterien nach WCAG 2.2 AA im Überblick
Die folgende Übersicht ordnet die wichtigsten Erfolgskriterien den konkreten Fehlern zu, die uns im Consent-Banner begegnen. Sie eignet sich als Checkliste für die eigene Prüfung, ersetzt aber nicht den Blick auf das reale Verhalten mit Tastatur und Screenreader. Die neuen Kriterien der WCAG 2.2 verschärfen dabei vor allem die Anforderungen an Fokus und Zielgröße.
| WCAG-Kriterium | Anforderung | Häufiger Fehler im Banner |
|---|---|---|
| 2.1.1 Tastatur | Alle Bedienelemente per Tastatur nutzbar | Schalter reagiert nur auf Mausklick |
| 2.4.7 Fokus sichtbar | Erkennbarer Fokusrahmen | Kein oder unsichtbarer Fokus auf Buttons |
| 2.4.11 Fokus nicht verdeckt | Fokussiertes Element bleibt sichtbar | Fixierter Banner überdeckt den Fokus |
| 1.4.3 Kontrast | Text mindestens 4,5:1 | Blasser Ablehnen-Button und graue Labels |
| 1.4.11 Kontrast Bedienelemente | Umrandungen und Fokus mindestens 3:1 | Kaum sichtbare Schalter-Umrisse |
| 4.1.2 Name, Rolle, Wert | Rolle und Name für Hilfstechnik | Fehlendes role=dialog und aria-label |
| 2.5.8 Zielgröße | Ziele mindestens 24 mal 24 Pixel | Winzige Schalter und Schließen-Symbole |
Umsetzung in sechs Schritten
Ein barrierefreier Consent-Banner entsteht nicht durch ein zusätzliches Werkzeug, sondern durch saubere Arbeit an Markup, Verhalten und Design-System. Die folgenden Schritte führen von der Bestandsaufnahme zur nachweisbaren Konformität.
- Rolle und Struktur setzen: Den Banner als modalen Dialog auszeichnen, mit role=dialog oder nativem dialog-Element, aria-modal und einer Beschriftung über die Überschrift.
- Fokus verwalten: Beim Öffnen den Fokus in den Dialog legen, ihn innerhalb halten und beim Schließen an die auslösende Stelle zurückgeben.
- Tastaturwege prüfen: Jeden Button und Schalter per Tab erreichen, mit sichtbarem Fokus und einem klaren Weg zum Verlassen des Dialogs.
- Kontraste festlegen: Text auf mindestens 4,5:1, Umrandungen und Fokus auf mindestens 3:1, hinterlegt als Tokens im Design-System.
- Gleichwertigkeit herstellen: Zustimmen und Ablehnen auf der ersten Ebene, in vergleichbarer Größe, Kontrast und Reihenfolge.
- Prüfen und dokumentieren: Mit Tastatur und Screenreader testen, jeden Befund einem Kriterium zuordnen und das Ergebnis in einer Erklärung zur Barrierefreiheit festhalten.
Aus dieser Reihenfolge ergibt sich zugleich der Anschluss an das Gesamtbild. Ein einzelner geprüfter Banner nützt wenig, wenn der Rest der Seite ungeprüft bleibt; die barrierefreie Umsetzung betrachtet die Oberfläche als Ganzes. Ein WCAG-2.2-Audit liefert dafür die priorisierte Maßnahmenliste, und ein laufendes BFSG-Monitoring erkennt, wenn ein späteres Update des Consent-Tools eine neue Barriere einführt.
Quellen und Studien