Cookie-Banner barrierefrei gestalten

WCAG 2.1.1, 2.4.3, 1.4.3, 4.1.2 · mittel · etwa 60 Minuten · Stand 08.11.2026

Worum es geht

Ein Cookie-Banner erscheint meist beim ersten Besuch und verdeckt einen Teil der Seite. Wenn er sich nicht per Tastatur bedienen lässt, der Screenreader ihn nicht findet oder der Fokus dahinter auf der Seite herumspringt, kommen manche Menschen nicht weiter in deinen Shop. Häufige Probleme: Der Banner steht im Code ganz am Ende der Seite, die Buttons sind div-Elemente, die Schrift ist zu blass, oder "Ablehnen" ist als kleiner grauer Textlink versteckt. Die wichtigsten WCAG-Kriterien hier sind Tastaturbedienung (2.1.1), sinnvolle Fokusreihenfolge (2.4.3), Kontrast (1.4.3) sowie Name und Rolle der Bedienelemente (4.1.2).

Wen es betrifft

Menschen, die nur mit Tastatur oder Schaltern arbeiten. Sie müssen den Banner erreichen und schließen können, bevor sie den Shop nutzen.
Blinde Menschen mit Screenreader. Sie müssen erfahren, dass ein Banner da ist, was er fragt und welche Buttons es gibt.
Menschen mit Sehbehinderung, die blasse Schrift oder kleine Links schlecht erkennen.
Menschen mit Vergrößerung, bei denen ein großer Banner den ganzen sichtbaren Bereich füllt.

So behebst du es

Echte Buttons verwenden. Jede Wahl ist ein <button> mit sichtbarem Text. So ist sie per Tab erreichbar, mit Enter und Leertaste auslösbar und wird als Button angesagt (2.1.1, 4.1.2).

Schlecht:

<div class="cookie-ok" onclick="zustimmen()">OK</div>
<span class="klein grau" onclick="ablehnen()">ablehnen</span>

Gut:

<button type="button" data-wahl="alle">Alle akzeptieren</button>
<button type="button" data-wahl="notwendig">Nur notwendige</button>

Zustimmen und Ablehnen gleich leicht machen. Beide Wahlmöglichkeiten stehen auf der ersten Ebene des Banners, als gleichartige Buttons in gleicher Größe, gleicher Schrift und mit ausreichendem Kontrast. Niemand soll erst in "Einstellungen" suchen müssen, um abzulehnen.

Den Banner als Dialog umsetzen und den Fokus hineinsetzen. Das native <dialog>-Element mit showModal() erledigt viel von selbst: Der Browser setzt den Fokus in den Dialog, Inhalte dahinter sind nicht erreichbar, und Escape schließt ihn. Damit stimmt die Fokusreihenfolge (2.4.3), und niemand tabbt unbemerkt hinter dem Banner durch die Seite.

<dialog id="cookie-dialog" aria-labelledby="cookie-titel" aria-describedby="cookie-text">
  <h2 id="cookie-titel">Cookies in unserem Shop</h2>
  <p id="cookie-text">
    Wir nutzen notwendige Cookies, damit der Shop funktioniert. Mit deiner
    Zustimmung nutzen wir weitere Cookies für Statistik.
    Mehr dazu in der <a href="/datenschutz">Datenschutzerklärung</a>.
  </p>
  <div class="cookie-aktionen">
    <button type="button" data-wahl="alle">Alle akzeptieren</button>
    <button type="button" data-wahl="notwendig">Nur notwendige</button>
    <button type="button" aria-expanded="false" aria-controls="cookie-optionen">
      Einstellungen
    </button>
  </div>
  <form id="cookie-optionen" hidden>
    <fieldset>
      <legend>Welche Cookies erlaubst du?</legend>
      <input type="checkbox" id="c-notwendig" checked disabled>
      <label for="c-notwendig">Notwendig (immer aktiv)</label>
      <input type="checkbox" id="c-statistik" name="statistik">
      <label for="c-statistik">Statistik</label>
    </fieldset>
    <button type="submit">Auswahl speichern</button>
  </form>
</dialog>

const dialog = document.getElementById('cookie-dialog');
const optionen = document.getElementById('cookie-optionen');
const einstellungen = dialog.querySelector('[aria-controls="cookie-optionen"]');

if (!localStorage.getItem('cookie-wahl')) dialog.showModal();

function speichern(wahl) {
  localStorage.setItem('cookie-wahl', wahl);
  dialog.close();
}

dialog.querySelectorAll('[data-wahl]').forEach((btn) =>
  btn.addEventListener('click', () => speichern(btn.dataset.wahl))
);

einstellungen.addEventListener('click', () => {
  const offen = einstellungen.getAttribute('aria-expanded') === 'true';
  einstellungen.setAttribute('aria-expanded', String(!offen));
  optionen.hidden = offen;
});

optionen.addEventListener('submit', (e) => {
  e.preventDefault();
  speichern(optionen.statistik.checked ? 'statistik' : 'notwendig');
});

Escape schließt einen modalen Dialog. Lege fest, was das bedeutet. Naheliegend ist, es wie "Nur notwendige" zu behandeln oder den Banner beim nächsten Seitenaufruf erneut zu zeigen.

Keine Falle bauen. Der Fokus bleibt nur so lange im Dialog, bis eine Wahl getroffen ist. Danach muss man ganz normal weiter durch die Seite kommen (2.1.2).
Wenn du keinen modalen Dialog willst: Platziere den Banner im HTML am Anfang des <body>, damit er als Erstes per Tab erreichbar ist, und gib ihm einen Namen, etwa <section aria-labelledby="cookie-titel">. Achte dann darauf, dass ein fixierter Banner fokussierte Elemente auf der Seite nicht vollständig verdeckt. Das beschreibt das neue WCAG-2.2-Kriterium 2.4.11 Focus Not Obscured (Minimum).

Kontrast prüfen (1.4.3). Text und Buttonbeschriftung im Banner brauchen mindestens 4.5:1 zum Hintergrund. Prüfe mit unserem Kontrast-Prüfer. Das gilt für beide Buttons gleichermaßen.

.cookie-aktionen button {
  padding: 0.75rem 1.25rem;
  font: inherit;
  color: #ffffff;
  background: #1a4fd6; /* etwa 6.7:1 mit Weiß */
  border: 2px solid #1a4fd6;
}
.cookie-aktionen button:focus-visible {
  outline: 3px solid #1a1a1a;
  outline-offset: 2px;
}

Wahl später ändern können. Ein Link oder Button "Cookie-Einstellungen" im Footer öffnet den Dialog erneut. Auch er muss per Tastatur bedienbar sein.

Wenn du ein fertiges Consent-Tool nutzt, prüfe dessen Einstellungen auf diese Punkte. Viele Tools erlauben, Farben, Button-Reihenfolge und Darstellung anzupassen.

So prüfst du es

Privates Fenster öffnen, damit der Banner erscheint. Drücke Tab. Landet der Fokus im Banner? Kannst du jede Wahl mit Enter oder Leertaste auslösen?
Fokus nach dem Schließen: Kommst du danach ganz normal weiter durch die Seite? Springt der Fokus nicht an eine unerwartete Stelle?
Screenreader: Lade die Seite mit NVDA oder VoiceOver. Wird der Dialog mit seinem Titel angesagt? Werden die Buttons als Buttons mit ihrem Text vorgelesen?
Vergleich Zustimmen und Ablehnen: Sind beide Buttons gleich groß, gleich gut lesbar und in der gleichen Anzahl Schritte erreichbar?
axe DevTools meldet unter anderem Buttons ohne Namen (button-name), Dialoge ohne Namen (aria-dialog-name) und zu geringen Kontrast (color-contrast). Prüfe den Banner, solange er sichtbar ist.
Zoom auf 200 %: Bleiben alle Buttons sichtbar und erreichbar, oder schneidet der Banner etwas ab?