Cookie-Banner auf Barrierefreiheit testen: Checkliste

Der Cookie-Banner ist die digitale Haustür Deiner Website: Scheitert die Bedienung mit Tastatur oder Screenreader bereits hier, bleibt Besuchern der gesamte Webauftritt versperrt. Unter dem Barrierefreiheitsstärkungsgesetz (BFSG) ist ein unzugänglicher Consent-Dialog deshalb ein kritisches Risiko für den gesamten Online-Auftritt.

Um Deinen Cookie-Banner auf Barrierefreiheit zu testen, gehe alle angebotenen Auswahlmöglichkeiten durch. Öffne die Einstellungen, lehne optionale Cookies ab und kontrolliere, was danach mit dem Tastaturfokus passiert. Wiederhole den Ablauf auch nach einer Zustimmung.

Ein Banner kann beim Laden der Seite funktionieren und erst in den Einstellungen eine Barriere zeigen. Im Beispiel weiter unten fehlt dort der Dialogtitel. Ein Scan vor dem Öffnen findet diesen Fehler nicht.

Cookie-Banner auf Barrierefreiheit testen: Wo Du anfängst

Beginne in einem frischen Browserprofil ohne gespeicherte Einwilligung. Notiere die Seite, den Browser, die Bildschirmgröße und die Version Deines Consent-Tools. Wenn Du nur Cookies löschst, kontrolliere auch, ob das Tool seinen Zustand zusätzlich im lokalen Speicher ablegt.

Ein Consent-Management-Tool, kurz CMP, speichert die Cookie-Auswahl und zeigt die Schaltflächen und Einstellungen dafür an. Prüfe es mit Deinen Texten, Deinem Theme und innerhalb Deiner Website.

Notiere die Wege, die Besucher nutzen können. Dazu gehören die erste Auswahl, die Einstellungen und das spätere Ändern der Entscheidung. Teste Ablehnen und Zustimmen jeweils mit einem frischen Ausgangszustand. Sonst kann die gespeicherte Auswahl den nächsten Versuch verändern.

Unser Leitfaden zum Testen einer barrierefreien Website erklärt, welche Prüfungen Du automatisieren kannst und welche Du selbst durchführen musst.

Ist Dein Banner modal oder bleibt die Seite bedienbar?

Ein modaler Dialog blockiert die Seite im Hintergrund. Ein nicht modaler Banner lässt die übrige Seite weiter bedienen.

Für modale Dialoge beschreibt das W3C-Dialogmuster den Ablauf: Der Fokus gelangt hinein, Tab bleibt innerhalb des Dialogs und Escape schließt ihn. Nach dem Schließen kehrt der Fokus normalerweise zum Auslöser zurück. Bei einem Banner, der von selbst erscheint, brauchst Du stattdessen einen sinnvollen Anschluss auf der Seite.

Ein nicht modaler Banner sollte den Fokus nicht einschließen. Prüfe hier besonders, ob er einen fokussierten Link vollständig verdeckt. Das behandelt WCAG 2.4.11. Teilweise Überdeckung ist unter diesem Kriterium erlaubt. Ein gut nutzbarer Aufbau lässt trotzdem möglichst viel sichtbar.

Gehe den Ablauf einmal ohne Maus durch

Du solltest jede angebotene Auswahl mit der Tastatur erreichen und auslösen können. WCAG 2.1.1 verlangt Tastaturbedienbarkeit.

1. Lade die Seite neu. Drücke Tab und notiere, wo der Fokus beginnt. Bei einem modalen Banner darf er nicht auf der blockierten Seite weiterwandern.

2. Gehe vorwärts und rückwärts. Nutze Tab und Shift+Tab. Du solltest jederzeit erkennen, welches Element den Fokus hat. Ein sichtbarer Fokus gehört zu WCAG 2.4.7.

3. Lehne optionale Cookies ab. Nutze die dafür vorgesehene Schaltfläche. Prüfe danach, ob Du die Seite weiter bedienen kannst. Halte getrennt fest, ob Deine Auswahl gespeichert wurde.

4. Starte frisch und stimme zu. Prüfe, ob Du nach dem Zustimmen die Seite weiter bedienen kannst.

5. Öffne die Einstellungen. Erreiche jede Kategorie, ändere eine optionale Auswahl und speichere sie. Prüfe auch aufklappbare Bereiche, falls Dein Tool sie anbietet.

6. Schließe die Einstellungen. Teste die sichtbare Schließen-Schaltfläche und bei einem modalen Dialog Escape. Schließen darf keine versteckte Zustimmung bedeuten. Prüfe die gespeicherte Auswahl separat.

7. Öffne die Einstellungen später erneut. Suche den dauerhaft verfügbaren Zugang, etwa einen Link im Footer oder ein schwebendes Cookie-Symbol am Bildschirmrand. Achte bei schwebenden Buttons darauf, dass sie einen barrierefreien Namen haben (aria-label="Cookie-Einstellungen"), fokussierte Elemente im Footer nicht verdecken (WCAG 2.4.11) und ausreichend große Klickflächen haben (WCAG 2.5.8). Nach dem Schließen sollte der Fokus wieder sinnvoll zum Auslöser zurückkehren.

Wiederhole den Weg mit einem Screenreader. Achte darauf, ob der Dialog einen verständlichen Namen hat und ob die Kategorien ihren Zustand vermitteln. WCAG 4.1.2 beschreibt die Anforderungen an Namen, Rollen und Zustände von Bedienelementen. Eine fehlerfreie automatische Prüfung belegt noch keinen verständlichen Screenreader-Ablauf.

Die folgenden Lernbeispiele bündeln mehrere typische Probleme. Sie sind nicht bedienbar. Beschriftungen erkennst Du direkt in der Darstellung; Tastatur- und Fokusfehler stehen darunter, weil Du sie erst beim Bedienen bemerkst.

Schlechtes Beispiel: Was hier schiefgeht

1. Der Dialog hat keinen Namen. Ein Screenreader kann nicht verständlich ankündigen, welches Fenster sich geöffnet hat. Eine sichtbare Überschrift muss auch als Dialogname hinterlegt sein.
2. Die Auswahl bleibt unklar. „Option 1“, „Option 2“ und „Weiter“ erklären weder die Cookies noch, was die Schaltfläche speichert.
3. Die Tastaturmarkierung fehlt. Beim Drücken von Tab siehst Du nicht, welche Schaltfläche gerade ausgewählt ist.
4. Der Fokus wandert hinter das Fenster. Obwohl der Dialog die Seite blockiert, erreichst Du mit Tab verdeckte Links im Hintergrund.
5. Die Einstellungen sind später nicht erreichbar. Nach dem Schließen fehlt ein dauerhaft verfügbarer Zugang, um die Auswahl zu ändern.

Die ersten beiden Fehler siehst Du oben. Die anderen bemerkst Du erst beim Bedienen und nach dem Schließen.

Gutes Beispiel: So wird die Auswahl verständlicher

• Ein verständlicher Dialogname. „Cookie-Einstellungen“ ist sichtbar und mit dem Dialog verknüpft, damit ein Screenreader ihn ankündigen kann.
• Klare Texte und Aktionen. Die Kategorien nennen ihren Zweck. Ablehnen, Speichern und Akzeptieren sind eindeutig beschriftet.
• Sichtbarer Tastaturfokus. Eine Markierung zeigt, welches Element Du mit Enter oder der Leertaste bedienen kannst.
• Passende Fokusführung. In einem modalen Dialog bleibt Tab innerhalb des Fensters. Escape schließt es; der Fokus kehrt normalerweise zum Auslöser zurück.
• Ein Zugang für später. Ein Link „Cookie-Einstellungen“, etwa im Footer, öffnet die Auswahl erneut.

Die Fokusführung folgt dem W3C-Muster für modale Dialoge. Wenn Dein Banner die Seite weiter bedienen lässt, darf er den Fokus nicht einsperren. In beiden Fällen sollen fokussierte Elemente sichtbar bleiben.

Was im CookieConsent-Beispiel gemessen wurde

Die Lernbeispiele oben zeigen mehr Fehler als die ursprüngliche Messung. Mit CookieConsent 3.1.0 wurde geprüft: Der fehlende Dialogname wurde erst nach dem Öffnen gefunden und nach dem Ergänzen des Titels nicht mehr gemeldet. Ein zu kleiner Statistik-Schalter wurde vergrößert und erneut geprüft. Escape führte den Fokus in beiden Varianten zum Auslöser zurück.

Die Namensprüfung ist eine axe-Best-Practice-Regel, kein WCAG-Erfolgskriterium. Die weiteren Fehler in den Lernbeispielen sind erläuternde Beispiele, keine zusätzlich gemessenen Ergebnisse.

So dokumentierst Du jeden Zustand

Schreibe pro Zustand auf, wie Du ihn erreicht hast und was Du beobachtet hast. Eine Zeile wie „Banner geprüft“ reicht für eine spätere Fehlerbehebung kaum aus.

Nutze diese Vorlage für Deine eigenen Ergebnisse:

• Ausgangszustand: Frisches Profil oder bereits gespeicherte Auswahl?

• Aktion: Welche Schaltfläche wurde mit welcher Taste aktiviert?

• Erwartung: Welcher Dialog sollte sich öffnen und wohin sollte der Fokus wechseln?

• Beobachtung: Was passierte tatsächlich? Ergänze Browser, Bildschirmgröße und Screenshot.

• Automatischer Befund: Regel, Selektor und geprüfter Zustand. Halte manuelle Beobachtungen getrennt fest.

• Korrektur und Nachprüfung: Welche Änderung wurde gemacht? Funktioniert derselbe Ablauf danach?

Erfasse mindestens den offenen Banner, Ablehnen, Zustimmen, die Einstellungen und die Seite nach dem Schließen. Ergänze Unterbereiche nur, wenn Dein Tool sie tatsächlich hat. Markiere ausstehende Prüfungen als offen.

Notiere, was Du gemacht hast und welches Problem auftrat. Zum Beispiel: „Ich öffne die Cookie-Einstellungen mit der Tastatur. Das Fenster hat keinen Namen, den ein Screenreader vorlesen kann.“ Ergänze den Browser und einen Screenshot.

Prüfe auch kleine Ansichten und überlagerte Inhalte

Ein Desktop-Ergebnis gilt nur für die getestete Ansicht. Wiederhole den Ablauf in einem schmalen Browserfenster und bei vergrößerter Darstellung. Lange Texte dürfen die Auswahl oder die Schließen-Schaltfläche nicht unerreichbar machen.

Prüfe auch das Zusammenspiel mit anderen Dialogen. Öffnet sich etwa ein Login über einem bereits sichtbaren Banner, muss klar bleiben, welcher Dialog gerade bedient wird. Notiere solche Kombinationen als eigenen Testfall.

Kontrolliere Textkontraste nach WCAG 1.4.3. Achte bei kleinen Schließen-Icons auf die Zielgröße. WCAG 2.5.8 nennt 24 × 24 CSS-Pixel als Mindestgröße und enthält Ausnahmen, unter anderem für ausreichenden Abstand. Die Regel lässt sich deshalb nicht allein anhand der sichtbaren Icongröße beurteilen.

Wann hilft ein automatisierter Audit?

Ein automatisierter Scan kann fehlende Namen, Strukturfehler und Kontrastprobleme erkennen. Öffne dafür den Banner oder die Einstellungen, die Du prüfen möchtest. Im Beispiel erkennt axe den fehlenden Dialogtitel erst nach dem Öffnen.

Auch die Playwright-Anleitung zur Barrierefreiheitsprüfung zeigt, wie Du vor einem Scan ein Bedienelement öffnest. Für die Fokusführung brauchst Du zusätzlich manuelle Prüfungen oder eigene Tests.

Der folgende Ablauf beschreibt, wie Du einen eigenen Audit vorbereitest. Ein navable-Lauf auf dieser Demo wurde nicht gemessen.

Im navable Audit kannst Du interaktive Zustände in Deinen Prüfablauf aufnehmen. Beschreibe Ablehnen, Zustimmen und Einstellungen als einzelne Wege. Kontrolliere im Ergebnis, ob der Audit die gewünschte Ansicht geöffnet hat. Gib bestätigte Fehler mit Selektor und Reproduktionsschritten an die Entwicklung weiter. Nach der Änderung prüfst Du denselben Weg erneut.

Im zweiten Fall meldet die Namensregel keinen Fehler mehr. Tastaturbedienung und Screenreader-Ablauf brauchen weiterhin eigene Prüfungen.

Diesen Pfad als Multi-State-Audit vorbereiten.