Barrierefreie Komponenten · Interaktive Widgets
Cookie-Banner barrierefrei gestalten
Das Erste, was viele auf einer Website treffen, ist der Cookie-Banner – und genau er ist oft die erste Barriere: ein Fokus, der im Nichts hängt, Buttons, die die Tastatur nicht erreicht, oder ein „Ablehnen“, das absichtlich versteckt wird. Dabei berührt der Banner zwei Welten: Barrierefreiheit und Datenschutz.
Die beste Lösung: keiner
Vorweg, weil ehrlich: Der zugänglichste Banner ist der, den es nicht gibt. Wer nur technisch notwendige Cookies setzt und auf datenschutzfreundliche Analyse ohne Einwilligung baut, braucht keinen Consent-Layer. Diese Website geht genau diesen Weg – kein Banner, keine Barriere, schnellere Seite. Wo ein Banner aber nötig ist, muss er zugänglich sein.
Fokus richtig führen
Blockiert der Banner die Nutzung der Seite (echte Einwilligungspflicht), verhält er sich wie ein modaler Dialog:
- Fokus beim Erscheinen in den Banner setzen.
- Fokus halten (Fokus-Falle), solange er die Seite blockiert.
- Tastaturbedienung für alle Optionen; Esc möglichst als „Ablehnen/Schließen“.
-
role="dialog"mitaria-labelledbyauf die Überschrift.
Ist der Banner nicht blockierend, gehört er nicht in eine Fokus-Falle – dann reicht ein normaler, gut platzierter Bereich, der die Tastatur-Reihenfolge nicht sprengt.
Randnotiz – Fokus nicht verdecken (WCAG 2.4.11). Ein am unteren Rand klebender Banner verdeckt gern genau das Element, das gerade den Fokus hat. Das neue WCAG-2.2-Kriterium „Fokus nicht verdeckt“ verlangt, dass das fokussierte Element sichtbar bleibt – plane den Platz ein oder blende den Banner, solange anderswo gearbeitet wird.
Keine dunklen Muster
Barrierefreiheit ist auch eine Frage der Fairness. „Alle akzeptieren“ als bunter Riesenknopf, „Ablehnen“ als blasser Mini-Link – das ist ein Dark Pattern und datenschutzrechtlich angreifbar.
- Gleichwertige Buttons: Annehmen und Ablehnen optisch und in der Bedienung ebenbürtig.
- Kontrast für beide Optionen ausreichend (siehe Farbkontraste).
- Echte Buttons mit klaren Beschriftungen, nicht „OK“ für „alles annehmen“.
Häufige Fehler
- Fokus bleibt hinter dem Banner auf der Seite, die man gar nicht bedienen kann.
- Nur per Maus bedienbar – Tastatur erreicht die Buttons nicht.
- „Ablehnen“ versteckt oder mehrere Klicks tief vergraben.
- Banner verdeckt den Fokus am Seitenrand (Verstoß gegen 2.4.11).
-
Kein
role="dialog"/Label, sodass der Zweck unklar bleibt.
Häufige Fragen
Muss der Banner ein modaler Dialog sein?
Nur wenn er die Nutzung wirklich blockiert. Dann gelten Fokus-Falle und Dialog-Semantik. Ein nicht blockierender Hinweis sollte keine Falle sein.
Reicht ein „Alle akzeptieren“-Button?
Nein. Aus Datenschutzsicht braucht es eine ebenso einfache Ablehnung. Aus Barriere-Sicht müssen beide Wege gleich gut bedienbar sein.
Wie vermeide ich den Banner ganz?
Indem du auf einwilligungspflichtige Cookies und Dienste verzichtest – datenschutzfreundliche Analyse und nur essenzielle Cookies kommen ohne Consent-Layer aus. Details auf der Datenschutz-Seite.
Fazit
Der beste Cookie-Banner ist keiner – sonst gilt: wie ein modaler Dialog behandeln, solange er blockiert, vollständig per Tastatur bedienbar, den Fokus nicht verdecken und Annehmen wie Ablehnen gleichwertig anbieten. So wird aus der ersten Hürde ein fairer, zugänglicher erster Eindruck.