Barrierefreie Cookie-Banner: DSGVO und BFSG gleichzeitig erfüllen

Das Dilemma: DSGVO fordert Cookie-Banner, BFSG fordert Barrierefreiheit

Fast jede Webseite hat ein Cookie-Banner. Und fast jedes Cookie-Banner hat Barrierefreiheits-Probleme: nicht per Tastatur bedienbar, Fokus springt nicht zum Banner, der „Alle ablehnen“-Button ist schwer zu finden, Kontraste sind zu gering, und Screenreader lesen den Banner-Text nicht korrekt vor.

Seit dem Inkrafttreten des Barrierefreiheitsstärkungsgesetzes (BFSG) im Juni 2025 stehen Webseitenbetreiber vor einer Doppelpflicht: Die DSGVO (Art. 7, § 25 TDDDG) verlangt eine informierte Einwilligung vor dem Setzen nicht-essentieller Cookies. Das BFSG verlangt, dass diese Einwilligung barrierefrei einholbar ist. Ein Cookie-Banner, das Tastatur-Nutzer oder Screenreader-Nutzer aussperrt, verletzt beide Regelwerke gleichzeitig.

Die Konsequenzen sind doppelt schmerzhaft: Datenschutzverstöße können Abmahnungen und Bußgelder nach sich ziehen. BFSG-Verstöße können mit Bußgeldern bis zu 100.000 € geahndet werden. Ein nicht-barrierefreies Cookie-Banner ist damit eines der risikoreichsten Elemente auf deiner Webseite.

Was ein barrierefreies Cookie-Banner braucht

Ein WCAG-konformes Cookie-Banner muss mehrere technische Anforderungen erfüllen. Hier die wichtigsten:

Fokus-Management

Wenn das Cookie-Banner erscheint, muss der Tastaturfokus automatisch auf den Banner springen. Das ist besonders bei Overlay-Bannern kritisch, die den restlichen Seiteninhalt blockieren. Ohne korrektes Fokus-Management können Tastatur-Nutzer den Banner nicht bedienen und bleiben auf der Seite gefangen.

Tastatur-Bedienbarkeit (SC 2.1.1)

WCAG SC 2.1.1 (Keyboard, Level A) ist eines der grundlegendsten Kriterien: Alle Funktionen müssen per Tastatur erreichbar sein. Für Cookie-Banner bedeutet das:

• Tab: Alle Buttons (Akzeptieren, Ablehnen, Einstellungen) müssen per Tab erreichbar sein
• Enter/Space: Buttons müssen per Enter oder Leertaste aktivierbar sein
• Escape: Sollte den Banner schließen (mit Standard-Auswahl „Ablehnen“)
• Sichtbarer Fokus (SC 2.4.7): Der aktive Button muss visuell hervorgehoben sein

Focus-Trap Pattern

Wenn dein Cookie-Banner als modaler Dialog den Seiteninhalt blockiert, muss der Tastaturfokus im Banner eingeschlossen bleiben. Das nennt man Focus-Trap. Ohne Focus-Trap kann ein Tastatur-Nutzer hinter den Banner tabben und mit verdeckten Elementen interagieren – das ist verwirrend und gefährlich.

Code-Beispiel – Focus-Trap:

function trapFocus(dialogEl) {
  const focusable = dialogEl.querySelectorAll(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  const first = focusable[0];
  const last = focusable[focusable.length - 1];

  dialogEl.addEventListener('keydown', function(e) {
    if (e.key === 'Tab') {
      if (e.shiftKey && document.activeElement === first) {
        e.preventDefault();
        last.focus();
      } else if (!e.shiftKey && document.activeElement === last) {
        e.preventDefault();
        first.focus();
      }
    }
    if (e.key === 'Escape') {
      // Bei Escape: Ablehnen und schließen
      rejectAllCookies();
      closeBanner();
    }
  });

  first.focus();
}

ARIA-Attribute (SC 4.1.2)

WCAG SC 4.1.2 (Name, Role, Value, Level A) verlangt, dass interaktive Elemente korrekt benannt und ihre Rolle erkennbar ist. Für Cookie-Banner bedeutet das:

<div role="dialog"
     aria-modal="true"
     aria-label="Cookie-Einstellungen"
     aria-describedby="cookie-desc">
  <p id="cookie-desc">
    Wir verwenden Cookies, um dein Erlebnis zu verbessern.
  </p>
  <button class="btn-primary">Alle akzeptieren</button>
  <button class="btn-secondary">Alle ablehnen</button>
  <button class="btn-link">Einstellungen</button>
</div>

Wichtig: aria-modal="true" signalisiert Screenreadern, dass nur der Dialog-Inhalt relevant ist. Ohne dieses Attribut lesen Screenreader möglicherweise den verdeckten Seiteninhalt mit vor.

Kontraste und Button-Gleichwertigkeit

Alle Texte und Buttons müssen die Kontrastanforderungen von SC 1.4.3 (Contrast Minimum, Level AA) erfüllen: mindestens 4,5:1 für normalen Text und 3:1 für großen Text. Prüfe die Kontraste für beide Buttons – auch den Ablehnen-Button.

Aus DSGVO-Sicht und nach aktueller Rechtsprechung müssen „Akzeptieren“ und „Ablehnen“ gleichwertig zugänglich sein. Dark Patterns wie ein großer, bunter „Akzeptieren“-Button neben einem winzigen, grauen „Ablehnen“-Link sind sowohl datenschutzrechtlich als auch aus Barrierefreiheits-Sicht problematisch.

Screenreader-Verhalten

Teste dein Cookie-Banner mit einem Screenreader (NVDA, JAWS oder VoiceOver). Prüfe dabei:

• Wird der Banner als Dialog angekündigt?
• Wird der beschreibende Text vorgelesen?
• Sind alle Buttons klar benannt (nicht nur „Button 1“, „Button 2“)?
• Wird der Seiteninhalt hinter dem Banner ignoriert (aria-modal)?
• Wird nach dem Schließen der Fokus sinnvoll zurückgesetzt?

Consent-Manager im Vergleich

Nicht jeder Consent-Manager ist automatisch barrierefrei. Hier ein Überblick über die gängigsten Lösungen und ihre Barrierefreiheits-Reife:

Cookiebot

Cookiebot bietet einen dedizierten Accessibility-Modus, der WCAG 2.1 Level AA anstrebt. Der Dialog verwendet role="dialog" und aria-modal. Fokus-Management und Tastatur-Bedienbarkeit sind im Accessibility-Modus gut umgesetzt. Cookiebot funktioniert plattformübergreifend (nicht nur WordPress).

Usercentrics

Usercentrics V2 hat das Banner in Zusammenarbeit mit Barrierefreiheits-Experten überarbeitet. Die aktuelle Version bietet WCAG-konforme Dialoge, korrektes Fokus-Management und Screenreader-Unterstützung. Achte darauf, die V2-Variante zu verwenden – ältere Versionen hatten Barrierefreiheits-Probleme.

Borlabs Cookie (WordPress)

Borlabs Cookie lässt sich barrierefrei konfigurieren, erfordert aber manuelle Anpassung. Prüfe nach der Installation: Ist der Fokus korrekt gesetzt? Funktioniert die Tab-Reihenfolge? Sind die ARIA-Attribute vorhanden?

Real Cookie Banner (WordPress)

Real Cookie Banner wirbt explizit mit WCAG-2.1-Kompatibilität und wurde von externen Accessibility-Testern geprüft. Der Banner setzt role="dialog", aria-modal und korrekte Focus-Traps ein.

Wichtig bei allen Tools: Egal welchen Consent-Manager du nutzt – teste das Banner nach der Installation immer mit Tastatur (Tab, Enter, Escape) und Screenreader (NVDA oder VoiceOver). Standard-Konfigurationen sind oft nicht barrierefrei.

Häufige Fehler in der Praxis

Bei unseren Audits mit dem bf-check Scanner sehen wir diese Fehler immer wieder:

1. Kein Fokus-Management: Der Banner erscheint, aber der Fokus bleibt auf dem <body>. Tastatur-Nutzer wissen nicht, dass ein Banner da ist.
2. Fehlende Focus-Trap: Nutzer tabben hinter den Banner und interagieren mit verdeckten Elementen.
3. Keine Escape-Taste: Der Banner lässt sich nur per Mausklick schließen.
4. Ablehnen versteckt: „Alle ablehnen“ ist nur über „Einstellungen“ erreichbar – zusätzliche Klicks, die Tastatur-Nutzer besonders belasten.
5. Schlechte Kontraste: Grauer Text auf weißem Hintergrund im Banner.
6. Kein role="dialog": Screenreader erkennen den Banner nicht als Dialog.
7. Fokus nicht zurückgesetzt: Nach dem Schließen springt der Fokus an den Seitenanfang statt zum ursprünglichen Element.

Radikale Lösung: Gar kein Cookie-Banner

Die barrierefreieste und datenschutzfreundlichste Lösung ist oft die einfachste: Kein Cookie-Banner. Wenn du keine Tracking-Cookies, keine Analytics-Cookies und keine Drittanbieter-Dienste nutzt, brauchst du gemäß § 25 TDDDG (ehemals TTDSG) kein Cookie-Banner.

Rein technisch notwendige Cookies (Session-Cookies, Warenkorb-Cookies) erfordern keine Einwilligung – weder nach DSGVO noch nach TDDDG. Serverseitiges Tracking (wie bf-check.de es nutzt) setzt keine Cookies und erfordert daher keinen Consent-Dialog.

Prüfe kritisch: Brauchst du Google Analytics wirklich? Oder reicht serverseitiges Tracking? Jedes entfernte Drittanbieter-Script ist ein Barrierefreiheits-Problem weniger, ein Datenschutz-Risiko weniger und eine schnellere Seite.

Checkliste: Barrierefreies Cookie-Banner

1. Fokus: Springt automatisch zum Banner bei Seitenaufruf
2. Focus-Trap: Fokus bleibt im Banner (bei modalen Overlays)
3. Tastatur: Tab, Enter, Space und Escape funktionieren (SC 2.1.1)
4. ARIA: role="dialog", aria-modal="true", aria-label (SC 4.1.2)
5. Kontraste: Mindestens 4,5:1 für alle Texte und Buttons (SC 1.4.3)
6. Gleichwertige Buttons: „Ablehnen“ genauso prominent wie „Akzeptieren“
7. Screenreader: Dialog wird angekündigt, alle Buttons benannt
8. Fokus-Rücksetzung: Nach Schließen springt Fokus zum Auslöser zurück

Dieser Artikel ersetzt keine Rechtsberatung. Die Anforderungen von DSGVO, TDDDG und BFSG können je nach Branche und Geschäftsmodell variieren. Ziehe im Zweifel eine spezialisierte Kanzlei für Datenschutz- und Barrierefreiheitsrecht hinzu.

Häufig gestellte Fragen