Einwilligungsdialog
Der Cookie-Banner: die erste Barriere Ihrer Website
Der Cookie-Banner ist oft das erste Hindernis einer Website. Die häufigsten Fehler bei Fokus, Tastatur, Kontrast und Beschriftung – und wie Sie sie prüfen.
Stand: · keine Rechtsberatung
Bevor ein Besucher Ihre Website sieht, sieht er den Einwilligungsdialog. Er ist die erste Bedienfläche überhaupt – und für viele Menschen die letzte. Lässt er sich nicht mit der Tastatur bedienen, bleibt die Seite dahinter gesperrt. Wird er vom Screenreader nicht als Dialog erkannt, liest der Screenreader die Seite vor, während sie für alle anderen verdeckt ist. Beides ist alltäglich.
Warum der Banner zur Website gehört
Die WCAG gelten für alles, was auf einer Seite zu sehen und zu bedienen ist – auch für Inhalte, die ein fremdes Werkzeug einblendet. Wer über seine Website Verträge mit Verbrauchern schließt, muss nach dem BFSG den ganzen Weg barrierefrei anbieten, und der beginnt beim Banner. Dass die Technik von einem Anbieter kommt, ändert daran nichts: Verantwortlich bleibt, wer die Website betreibt.
Trotzdem bleibt der Banner bei vielen Prüfungen außen vor. Viele automatische Prüfwerkzeuge blenden ihn vor dem Scan aus oder klicken ihn weg, damit er die Messung nicht stört. Das Ergebnis sieht dann besser aus, als die Website ist.
Die häufigsten Fehler
Der Fokus erreicht den Banner nicht
Der Dialog liegt im Quelltext ganz am Ende der Seite. Wer mit der Tabulatortaste losgeht, wandert zuerst durch die gesamte – verdeckte – Seite, bevor er beim Banner ankommt. Oder der Fokus kommt nie an. Betroffen sind 2.1.1 Tastatur und 2.4.3 Fokus-Reihenfolge.
Der Fokus verschwindet hinter dem Banner
Ein Banner, der am unteren Rand stehen bleibt, verdeckt beim Tabben die Links darunter. Man sieht nicht mehr, wo man ist. Genau dafür ist in WCAG 2.2 ein neues Kriterium hinzugekommen: 2.4.11 Fokus nicht verdeckt (Minimum).
„Ablehnen“ ist kaum zu sehen
„Alle akzeptieren“ als leuchtender Knopf, „Ablehnen“ als hellgrauer Text daneben: Das ist nicht nur datenschutzrechtlich heikel, es scheitert oft auch am Kontrast. Text braucht mindestens 4,5 : 1 gegen seinen Hintergrund, Ränder und Flächen von Bedienelementen mindestens 3 : 1 – siehe 1.4.3 Kontrast (Minimum) und 1.4.11 Nicht-Text-Kontrast.
Knöpfe ohne Namen
Das „X“ zum Schließen ist ein Symbol ohne Text, die Schalter in den Einstellungen sind gestaltete Kästchen statt echter Bedienelemente. Der Screenreader sagt dann „Schaltfläche“ – aber nicht, welche. Das verletzt 4.1.2 Name, Rolle, Wert.
Ein Dialog, der keiner ist
Optisch liegt der Banner über der Seite, technisch steht er einfach im Text. Der Screenreader erfährt nicht, dass gerade ein Dialog offen ist, und liest munter die Seite dahinter vor. Ein modaler Dialog braucht die passende Rolle, einen Namen und einen Fokus, der ihn nicht verlässt, solange er offen ist – bis er mit einer Entscheidung oder mit Escape geschlossen wird.
Die falsche Sprache
Viele Banner bringen ihre Texte in mehreren Sprachen mit. Steht auf einer deutschen Seite ein englischer Text ohne eigene Sprachangabe, liest ihn der Screenreader mit deutscher Aussprache vor – kaum verständlich. Betroffen ist 3.1.2 Sprache von Teilen.
Bei Zoom nicht mehr bedienbar
Bei 400 % Zoom ist der Bildschirm nur noch 320 Pixel breit. Viele Banner füllen dann den ganzen Bildschirm, ohne dass man in ihnen scrollen kann – die Knöpfe liegen unerreichbar unterhalb. Siehe 1.4.10 Reflow.
Zu kleine Ziele
„Einstellungen“ oder „Mehr erfahren“ als winziger Textlink direkt neben einem anderen: Auf dem Telefon trifft man das falsche. Bedienelemente brauchen mindestens 24 × 24 Pixel oder genug Abstand – 2.5.8 Zielgröße (Minimum), ebenfalls neu in WCAG 2.2.
Der Test in fünf Minuten
Dafür brauchen Sie nichts außer einem Browser. Öffnen Sie Ihre Website in einem privaten Fenster, damit der Banner erscheint, und legen Sie die Maus weg:
- Drücken Sie die Tabulatortaste. Landet der Fokus im Banner – und sehen Sie, wo er ist?
- Erreichen Sie alle Knöpfe – Akzeptieren, Ablehnen, Einstellungen – und lassen sie sich mit Enter oder Leertaste auslösen?
- Öffnen Sie die Einstellungen. Lassen sich die Schalter mit der Tastatur umlegen? Sehen Sie, ob sie an oder aus sind?
- Treffen Sie eine Entscheidung. Wohin springt der Fokus danach? Er sollte an einer sinnvollen Stelle der Seite landen, nicht im Nichts.
- Laden Sie die Seite erneut und zoomen Sie auf 400 % (Strg bzw. Cmd und Plus). Erreichen Sie die Knöpfe noch?
- Wer mag: Schalten Sie VoiceOver (Mac: Cmd + F5) oder NVDA ein. Wird der Banner als Dialog mit einem Namen angesagt?
Scheitert einer dieser Schritte, haben Sie ein Problem gefunden, das jeden Besucher betrifft, der so arbeitet – auf jeder Seite, beim ersten Besuch.
Wenn der Banner von einem Anbieter kommt
Die meisten Websites nutzen ein fertiges Werkzeug zur Einwilligungsverwaltung. Das ist vernünftig – aber kein Freibrief. Vieles lässt sich in dessen Einstellungen beheben: Farben und Kontraste, die Sprache, oft auch die Position. Fragen Sie den Anbieter nach seiner Erklärung zur Barrierefreiheit und danach, wie er mit gemeldeten Fehlern umgeht. Und prüfen Sie das Ergebnis selbst – mit den Schritten oben –, nachdem Sie etwas umgestellt haben.
Wie Barrierefreiheit-Check den Banner prüft
Wir blenden den Einwilligungsdialog nicht aus. Wir prüfen ihn zuerst und wählen ihn danach ab, um auch die Seite darunter messen zu können. Erkannt werden derzeit 7 verbreitete Dialoge, darunter Usercentrics, Cookiebot und CookieYes. Befunde im Banner stehen im Bericht wie alle anderen – mit der Stelle, an der sie auftreten, und dem Kriterium, gegen das sie verstoßen.
Was eine automatische Prüfung am Banner nicht sehen kann – ob die Fokusführung nach der Entscheidung sinnvoll ist, ob die Texte verständlich sind –, gehört zur Prüfung von Hand. Mehr dazu im Artikel Was eine automatische Barrierefreiheitsprüfung findet – und was nicht.