Barrierefreier Cookie-Banner: WCAG 2.2, BFSG und § 25 TDDDG in der Praxis

Kurze Antwort: Der Cookie-Banner ist auf den meisten Websites das erste interaktive Element und gehört zugleich zu den häufigsten Barrierefreiheitsfehlern im Web. Damit ein Einwilligungsbanner den Anforderungen der WCAG 2.2 entspricht, muss er vollständig per Tastatur bedienbar sein, ohne Fokusfalle, mit korrektem Namen, korrekter Rolle und korrektem Zustand für assistive Technologien, mit sichtbarem Fokus sowie ausreichendem Kontrast und Zielflächen von mindestens 24 × 24 CSS-Pixeln oder gleichwertigem Abstand. In Deutschland entsteht daraus eine doppelte Rechtslage: Ein unbedienbarer Banner schwächt die Wirksamkeit der Einwilligung nach § 25 TDDDG in Verbindung mit der DSGVO und kann bei Diensten im Anwendungsbereich des Barrierefreiheitsstärkungsgesetzes (BFSG) zugleich eine Barrierefreiheitsanforderung verletzen. Dieser Leitfaden ordnet die Kriterien zu, zeigt die richtigen Tastatur- und Screenreader-Muster und schließt mit einer Prüfcheckliste. Dies ist keine Rechtsberatung.

Inhaltsverzeichnis

• Warum Cookie-Banner so häufig scheitern
• Doppelte Rechtslage: § 25 TDDDG und BFSG
• BFSG, BITV 2.0 und EN 301 549: wer wofür zuständig ist
• Welche WCAG-2.2-Kriterien für einen Cookie-Banner gelten
• Screenreader-Verhalten richtig umsetzen
• Tastaturmuster: Fokusreihenfolge, ESC, keine Fallen
• Typische Fehler in verbreiteten CMP-Bannern
• Prüfcheckliste: Tastatur, Screenreader, automatischer Scan
• Wie cerez.io den Banner baut
• Häufig gestellte Fragen
• Quellen

Warum Cookie-Banner so häufig scheitern

Seit dem 28. Juni 2025 gilt in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG), mit dem die Richtlinie (EU) 2019/882 umgesetzt wurde. Seither prüfen viele Betreiber ihre Shops, Buchungsstrecken und Kundenportale zum ersten Mal systematisch auf Barrierefreiheit. Auffällig oft fällt dabei ausgerechnet das Bauteil durch, das niemand als „Inhalt“ wahrnimmt: der Cookie-Banner. Dafür gibt es drei strukturelle Gründe.

Erstens ist der Banner das erste interaktive Element. Ist er für Tastatur- oder Screenreader-Nutzende nicht bedienbar, ist faktisch die gesamte Website blockiert, ganz gleich wie sauber der Rest umgesetzt ist.

Zweitens werden Banner per Drittanbieter-Skript nachgeladen. Sie liegen außerhalb des Dokumentflusses, häufig am Ende des DOM, in Overlays mit hohem z-index. Daraus entstehen die klassischen Fehlerbilder: Der Fokus landet hinter dem Overlay, der Banner wird zuletzt oder gar nicht angekündigt, und die visuelle Reihenfolge weicht von der Vorlesereihenfolge ab.

Drittens entstehen Banner unter Conversion-Druck. Die Optimierung auf Zustimmungsraten führt zu kontrastarmen Ablehnen-Links, winzigen Schließen-Symbolen und anklickbaren div-Elementen, die wie Schaltflächen aussehen. Jede dieser Entscheidungen lässt sich einem WCAG-Verstoß zuordnen.

Prüfende bezeichnen Einwilligungsdialoge deshalb regelmäßig als wiederkehrende Quelle kritischer Fehler, weil dasselbe Template über Tausende von Seiten ausgerollt wird. Umgekehrt gilt: Wer die Vorlage repariert, repariert die erste Interaktion auf jeder Seite.

Doppelte Rechtslage: § 25 TDDDG und BFSG

Ein nicht barrierefreier Cookie-Banner ist kein reiner UX-Mangel. Er berührt in Deutschland zwei voneinander unabhängige Rechtsbereiche.

Erste Ebene: Wirksamkeit der Einwilligung. § 25 des Telekommunikation-Digitale-Dienste-Datenschutz-Gesetzes (TDDDG, im Mai 2024 aus dem TTDSG umbenannt) verlangt für das Speichern von Informationen auf Endeinrichtungen und den Zugriff darauf eine Einwilligung, sofern er nicht unbedingt erforderlich ist. Deren Anforderungen richten sich nach der DSGVO: freiwillig, für den bestimmten Fall, in informierter Weise und unmissverständlich abgegeben (Art. 4 Nr. 11 DSGVO) und nachweisbar (Art. 7 Abs. 1 DSGVO).

Genau hier wird Barrierefreiheit zur Rechtsfrage. Wenn ein Screenreader den Banner nie ankündigt, kann die Einwilligung schwerlich „in informierter Weise“ erfolgt sein. Wenn eine Tastaturnutzerin die Schaltfläche „Ablehnen“ nicht erreicht, während „Alle akzeptieren“ per Enter erreichbar ist, wird die Freiwilligkeit angreifbar. Und Protokolle, die aus solchen Situationen stammen, genügen der Nachweispflicht nach Art. 7 Abs. 1 DSGVO nur eingeschränkt.

Zweite Ebene: Barrierefreiheitsrecht. Das BFSG richtet sich an die private Wirtschaft und erfasst neben bestimmten Produkten auch Verbraucherdienstleistungen, darunter den elektronischen Geschäftsverkehr. Fällt Ihr Angebot darunter, ist der Cookie-Banner Teil der Benutzeroberfläche und damit Teil des Prüfumfangs wie jede andere Komponente.

Für Dienstleistungen sieht das BFSG eine eng gefasste Ausnahme für Kleinstunternehmen vor, die in den häufigen Fragen erläutert wird; für Produkte gilt sie nicht. Die Marktüberwachung haben die Länder in der Marktüberwachungsstelle der Länder für die Barrierefreiheit von Produkten und Dienstleistungen (MLBF) mit Sitz in Magdeburg gebündelt; dort können Verbraucherinnen und Verbraucher Barrieren melden. Welche Rechtsfolgen im Einzelfall drohen, gehört zu Ihrer Rechtsberatung. Der technische Kern bleibt auf beiden Ebenen derselbe: ein Banner, den alle bedienen können.

BFSG, BITV 2.0 und EN 301 549: wer wofür zuständig ist

In Diskussionen werden BFSG und BITV 2.0 häufig vermischt. Das sind zwei verschiedene Regime mit unterschiedlichen Adressaten.

Praktisch bedeutet das: Ein privatwirtschaftlicher Online-Shop richtet sich nach dem BFSG, ein Bundesportal nach der BITV 2.0. Die gemeinsame technische Klammer ist die europäische Norm EN 301 549, die sich weitgehend mit den WCAG 2.1 beziehungsweise 2.2 auf Stufe AA deckt; wer nach WCAG 2.2 AA arbeitet, arbeitet damit auch auf die Norm hin. Hintergründe zum europäischen Rahmen finden Sie in unserem Überblick zum European Accessibility Act.

Für Unternehmen mit türkischem Markt kommt das Rundschreiben 2025/10 hinzu, das WCAG 2.2 Stufe A plus die Prüfliste des Ministeriums verbindlich macht. Da Tastaturbedienbarkeit, Fokusreihenfolge und korrekte Rollen sämtlich Stufe-A-Kriterien sind, scheitert ein Banner mit Fokusfalle dort bereits an der niedrigsten existierenden Hürde.

Welche WCAG-2.2-Kriterien für einen Cookie-Banner gelten

Die WCAG 2.2 kennen kein Kapitel „Cookie-Banner“. Ein Einwilligungsdialog berührt aber eine überraschend lange Liste von Erfolgskriterien.

Zwei Kriterien sind neu in WCAG 2.2. 2.4.11 Fokus nicht verdeckt existiert wegen klebriger Overlays: Verdeckt Ihr unten fixierter Banner den fokussierten Link vollständig, ist das ein Verstoß; teilweises Verdecken erfasst erst das strengere AAA-Kriterium 2.4.12. 2.5.8 Zielgröße setzt 24 × 24 CSS-Pixel als Untergrenze, die viele „x“-Symbole nicht erreichen, mit Ausnahmen unter anderem für Ziele im Fließtext und für gleichwertigen Abstand.

Beachten Sie die Konformitätsstufe: Tastaturbedienbarkeit, Fokusfallen, Fokusreihenfolge sowie Name, Rolle und Wert liegen sämtlich auf Stufe A, sind also nicht die Kür, sondern der Mindeststandard.

Screenreader-Verhalten richtig umsetzen

Es gibt zwei legitime Muster. Welches ARIA korrekt ist, hängt davon ab, welches Sie wählen.

Muster 1: nicht blockierender Banner. Die Seite bleibt bedienbar, der Banner sitzt oben oder unten. Verwenden Sie hier kein role="dialog" mit aria-modal="true", denn nichts ist modal. Stattdessen:

• Fassen Sie den Banner in eine Landmarke, etwa role="region" mit aria-label="Cookie-Einwilligung", damit Screenreader-Nutzende ihn gezielt finden und überspringen können.
• Stehlen Sie beim Laden nicht den Fokus, sondern machen Sie den Banner in natürlicher Tab-Reihenfolge früh erreichbar.
• Soll das Erscheinen angekündigt werden, nutzen Sie eine höfliche Live-Region (aria-live="polite").

Muster 2: blockierender Dialog. Die Seite ist gesperrt, bis eine Entscheidung getroffen wurde. Dann muss sich der Banner wie ein echter modaler Dialog verhalten, entsprechend dem Dialog-Muster der W3C ARIA Authoring Practices:

• role="dialog" mit aria-modal="true", dazu aria-labelledby auf die Überschrift und aria-describedby auf den Erklärungstext.
• Beim Öffnen den Fokus in den Dialog bewegen, üblicherweise auf das erste Bedienelement.
• Den Fokus im Dialog halten, solange er offen ist. Das ist die einzige Situation, in der eingeschlossener Fokus korrekt ist, und sie schließt die Detailansicht „Einstellungen verwalten“ ein.
• Beim Schließen den Fokus dorthin zurückgeben, wo die Person vorher war.

In beiden Mustern brauchen die Kategorieschalter echte Semantik: ein button mit aria-pressed, ein Element mit role="switch" und aria-checked oder eine native Checkbox. Nur so wird „Analyse, aus“ gesprochen. Die Speicherbestätigung gehört in eine Statusmeldung (role="status"), nicht in einen Fokussprung.

Tastaturmuster: Fokusreihenfolge, ESC, keine Fallen

Hier scheitern die meisten Banner still, weil eine mausbasierte QA es nie bemerkt. Die Regeln sind kurz:

• Erreichbar: Der Banner muss kurz nach dem Laden per Tab erreichbar sein, nicht erst nach zweihundert anderen Elementen, sei es über eine frühe Position im DOM oder über gezieltes Fokusmanagement.
• Logische Reihenfolge: Überschrift, Beschreibung, Link zur Cookie-Richtlinie, Kategorieschalter, dann die Aktionsschaltflächen. Gleichwertige Optionen gehören nebeneinander: „Ablehnen“ und „Akzeptieren“ direkt hintereinander, nicht durch drei Absätze getrennt.
• Kein positiver tabindex: Niemals tabindex="1" oder höher zur Steuerung der Reihenfolge einsetzen; das zerstört die Tab-Sequenz der übrigen Seite.
• Escape schließt, ohne als Einwilligung gewertet zu werden: In einem modalen Banner soll die Escape-Taste den Dialog schließen. Entscheidend ist, dass ein Schließen ohne Entscheidung als „keine Einwilligung“ gilt und niemals als „akzeptiert“; ein Wegklicken als Zustimmung zu werten, ist ein Dark Pattern und ein Problem für die Wirksamkeit der Einwilligung. Kurz gefasst: ESC ohne Zustimmungsfiktion.
• Keine Fallen in beide Richtungen: Im nicht modalen Muster muss man den Banner verlassen können. Im modalen Muster darf man nicht in die inaktive Seite dahinter tabben.
• Sichtbarer Fokus: Jedes Bedienelement braucht eine Fokusanzeige mit mindestens 3:1 Kontrast zum Hintergrund. Ein entferntes outline ohne Ersatz verstößt gegen 2.4.7.

All diese Punkte lassen sich ohne Werkzeug prüfen: Maus beiseitelegen und tabben. Kommen Sie an einer Stelle nicht weiter, haben Sie ein Problem auf Stufe A.

Typische Fehler in verbreiteten CMP-Bannern

Über Plattformen hinweg wiederholen sich dieselben Defekte. Gleichen Sie Ihren Banner damit ab:

1. div-Buttons. <div onclick="accept()"> ist für die Tab-Taste unsichtbar und wird als reiner Text vorgelesen. Verstößt gegen 2.1.1 und 4.1.2; die Lösung ist ein natives <button>.
2. Kontrastarmes Ablehnen. Eine kräftig gefüllte Akzeptieren-Schaltfläche neben einem blassgrauen Link „Ohne Zustimmung fortfahren“ unter 4,5:1. Verstößt gegen 1.4.3, und die ungleiche Gestaltung wird zusätzlich datenschutzrechtlich kritisiert.
3. Klick-Schutzschicht per z-index. Ein transparentes Overlay blockiert Mausklicks, aber nicht den Tastaturfokus. Nutzende tabben durch eine Seite, die sie nicht sehen. Verstößt gegen 2.4.11 und, weil die Fokusanzeige unsichtbar bleibt, regelmäßig auch gegen 2.4.7.
4. Erscheinen ohne Fokusmanagement und ohne Landmarke. Ein modaler Banner öffnet sich, ohne den Fokus zu bewegen, sodass der Screenreader weiter die Seite dahinter vorliest; nach dem Schließen landet der Fokus am Seitenanfang statt am Ausgangspunkt. Wird er zudem spät und ohne Region-Rolle am Ende des DOM eingehängt, entdecken Screenreader-Nutzende ihn erst nach der ganzen Seite.
5. Zustandslose Schalter. In CSS gezeichnete Kategorieschalter ohne aria-checked beziehungsweise aria-pressed. Assistive Technologie kann nicht erkennen, was an und was aus ist. Verstößt gegen 4.1.2 und 1.3.1.
6. Zu kleine Ziele. Ein 16 × 16 Pixel großes Schließen-Symbol in der Ecke. Verstößt gegen 2.5.8 und frustriert motorisch eingeschränkte ebenso wie mobile Nutzende.

Die meisten sind einzeilige Korrekturen in der Vorlage, und genau deshalb lohnt es sich, sie an der Quelle zu beheben.

Prüfcheckliste: Tastatur, Screenreader, automatischer Scan

Keine Methode deckt alles ab. Nutzen Sie alle drei Ebenen und wissen Sie, was jede übersieht.

Eine praktikable Reihenfolge:

1. Tastatur zuerst (etwa 10 Minuten): alles akzeptieren, alles ablehnen sowie Einstellungen öffnen und speichern, jeweils auch nach erneutem Öffnen über das Wieder-Einwilligen-Symbol.
2. Screenreader danach (etwa 20 Minuten): mit NVDA oder VoiceOver ohne gesetzte Cookies laden und Auffindbarkeit, gesprochene Namen, Zustandsansage und Speicherbestätigung prüfen.
3. Automatischer Scan zuletzt: axe oder Lighthouse mit geöffnetem Banner ausführen. Viele Scanner laufen erst, nachdem der Banner weggeklickt wurde, und prüfen ihn nie.

Automatische Engines finden nur einen Bruchteil der realen Barrieren; die manuellen Durchläufe sind nicht optional. Dieselbe Logik gilt auf Seitenebene, weshalb Overlays kein Ersatz für Scannen und Beheben sind: Ein Werkzeug, das die Seite nachträglich umlackiert, repariert keine fehlende Semantik.

Wie cerez.io den Banner baut

cerez.io liefert seinen Cookie-Einwilligungsbanner als Shadow-DOM-Komponente, die auf die beschriebenen Muster ausgelegt ist: native Button-Elemente, Fokusmanagement für die modale Position, ESC ohne Zustimmungsfiktion, sichtbare Fokusanzeigen und kontrastgeprüfte Standard-Farbschemata, wobei „Ablehnen“ dieselbe Gewichtung erhält wie „Akzeptieren“. Weil der Banner in einem Shadow Root gekapselt ist, kann Ihr Website-CSS seine Fokusstile oder seine Semantik nicht versehentlich überschreiben. Derselbe Einbindungs-Schnipsel kann zusätzlich das Barrierefreiheits-Widget laden, sodass beide Ebenen aus einer Integration stammen und gemeinsam getestet werden. Das unterstützt Ihre Arbeit an WCAG 2.2, misst den Fortschritt und dokumentiert ihn. Kein Werkzeug allein macht eine Website konform, und wir behaupten das nicht.

Häufig gestellte Fragen

Gilt das BFSG auch für den Cookie-Banner?

Kurze Antwort: Wenn Ihr Dienst in den Anwendungsbereich fällt, ja. Die WCAG und die EN 301 549 beziehen sich auf jede dargestellte Komponente, und ein Einwilligungsbanner ist die erste davon. Für öffentliche Stellen des Bundes gilt stattdessen die BITV 2.0, technisch mit derselben Normreferenz.

Kann ein nicht barrierefreier Banner die Einwilligung angreifbar machen?

Kurze Antwort: Er kann sie deutlich schwächen. Eine Einwilligung nach § 25 TDDDG in Verbindung mit der DSGVO muss informiert und freiwillig sein. Erfahren Screenreader-Nutzende nie, wozu sie zustimmen, oder erreichen Tastaturnutzende die Ablehnen-Option nicht, sind die daraus entstandenen Protokolle angreifbar. Die Bewertung im Einzelfall gehört zu Ihrer Rechtsberatung. Dies ist keine Rechtsberatung.

Wie soll ein Screenreader einen Cookie-Banner ankündigen?

Kurze Antwort: Bei einem nicht blockierenden Banner sollten Nutzende in der Tab-Reihenfolge eine beschriftete Region („Cookie-Einwilligung“) finden, Schaltflächen als Schaltflächen hören und Schalter mit ihrem Ein-/Aus-Zustand. Bei einem blockierenden Banner wandert der Fokus hinein, Überschrift und Beschreibung werden über aria-labelledby und aria-describedby angesagt, und der Fokus kehrt nach der Entscheidung zur Seite zurück.

Fällt mein Unternehmen unter die Kleinstunternehmen-Ausnahme des BFSG?

Kurze Antwort: Für Dienstleistungen greift sie nur, wenn beide Bedingungen zusammen erfüllt sind: weniger als 10 Beschäftigte und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme. Dokumentieren Sie die Zahlen, denn beim Überschreiten der Schwelle entfällt die Privilegierung. Für Produkte gilt die Ausnahme nicht, und § 25 TDDDG kennt ohnehin keine solche Ausnahme.

Wie teste ich einen Cookie-Banner mit einem Screenreader?

Kurze Antwort: Nutzen Sie NVDA (kostenlos, Windows) oder VoiceOver (in macOS und iOS enthalten). Laden Sie die Seite mit gelöschten Cookies neu, navigieren Sie ausschließlich mit der Tastatur und prüfen Sie vier Punkte: Der Banner ist auffindbar und beschriftet, jede Schaltfläche hat einen aussagekräftigen gesprochenen Namen, die Kategorieschalter geben ihren Zustand aus, und das Speichern erzeugt eine gesprochene Bestätigung.

Quellen

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI, Understanding Target Size (Minimum)
• W3C WAI, Understanding Focus Not Obscured (Minimum)
• W3C WAI, ARIA Authoring Practices: Modal Dialog Pattern
• Richtlinie (EU) 2019/882 (European Accessibility Act)
• Verordnung (EU) 2016/679 (DSGVO)
• Barrierefreiheitsstärkungsgesetz (BFSG), gesetze-im-internet.de
• § 25 TDDDG, gesetze-im-internet.de
• Bundesfachstelle Barrierefreiheit

Ein barrierefreier Einwilligungsbanner ist ein lösbares Problem: echte Schaltflächen, gesteuerter Fokus, ESC ohne Zustimmungsfiktion und gemessene Kontraste decken den größten Teil der Strecke ab. Für einen Banner, der diese Muster ab Werk mitbringt, Kostenlos starten mit cerez.io, oder vergleichen Sie die Tarife auf der Preisseite.