Cookie-Banner barrierefrei gestalten: Checkliste nach WCAG und 5-Minuten-Test
Veröffentlicht am 23. Oktober 2026
Ein Cookie-Banner ist barrierefrei, wenn Besucher es allein mit der Tastatur erreichen, verstehen, bedienen und wieder verlassen können, wenn es den Fokus auf der Seite nie ganz verdeckt und wenn Texte, Schalter und Knöpfe genug Kontrast haben und bei Zoom lesbar bleiben. Welche dieser Punkte Ihr Consent-Tool von Haus aus liefert und welche Sie mit Farben, Texten, Position und eigenem CSS selbst kaputt oder richtig machen, zeigt die Checkliste unten; am Ende steht ein Test, der etwa fünf Minuten dauert.
Das Banner kommt meist von einem eigenen Anbieter, einer sogenannten Consent-Management-Plattform (CMP), und liegt über Ihrer Seite. Wie es zu Theme, Apps und Zahlungsanbietern passt und wer im Shop wofür zuständig ist, beschreibt der Überblick Barrierefreier Onlineshop: Shopify, WooCommerce, Shopware und Co.. Im Tastaturtest in 10 Minuten ist das Banner die erste Station; hier geht es tiefer: um jedes einzelne Kriterium, um die Aufteilung zwischen Anbieter und Shop und um die Frage, wie streng die Regeln wirklich sind.
Warum das Banner dazugehört
Fällt Ihr Shop unter das Barrierefreiheitsstärkungsgesetz, gilt die Pflicht nach Auffassung der Bundesfachstelle Barrierefreiheit nicht nur für den Bestellweg. Sie schreibt in ihrer FAQ zum elektronischen Geschäftsverkehr (Frage 6), § 12 Nummer 3 BFSGV und Anlage 1 Nummer 2 BFSG legen nahe, „dass tatsächlich die gesamte Website bzw. App entsprechende Anforderungen zu erfüllen hat“. Nach § 12 Nr. 3 BFSGV müssen Webseiten „einschließlich der zugehörigen Online-Anwendungen“ wahrnehmbar, bedienbar, verständlich und robust sein. Für die technische Umsetzung nennt die Bundesfachstelle in derselben FAQ (Frage 2) die EN 301 549. Die Prüfkriterien unten stammen aus den WCAG des W3C.
Das Banner ist dabei meist das Erste, was ein Besucher bedienen muss. Lässt es sich nicht schließen oder verdeckt es die Seite, kommt er gar nicht erst zum Produkt.
Und wenn das Banner von einem Anbieter stammt? Nach § 1 Abs. 4 Nr. 4 BFSG gilt das Gesetz nicht für „Inhalte von Dritten, die von dem betreffenden Wirtschaftsakteur weder finanziert noch entwickelt werden noch dessen Kontrolle unterliegen“. Nach unserer Lesart trifft das auf ein Consent-Tool kaum zu, das Sie selbst auswählen, oft bezahlen, einrichten und in Farben und Texten anpassen. Gewährleisten müssen Sie nach § 14 Abs. 3 BFSG, dass die Anforderungen „stets erfüllt werden“, also auch nach einem Update des Anbieters.
Ob Ihr Banner datenschutzrechtlich richtig ist, etwa welche Cookies eine Einwilligung brauchen, regelt § 25 TDDDG zusammen mit der DSGVO. Das ist eine eigene Prüfung und nicht Thema dieses Artikels. Hier geht es nur darum, ob alle Menschen das Banner bedienen können.
Wie streng die Regeln sind: zwei übliche Bauweisen
Ein häufiges Missverständnis: Die WCAG schreiben nicht vor, dass ein Cookie-Banner beim Laden sofort den Fokus bekommen oder als erstes Element per Tab erreichbar sein muss. Das Understanding-Dokument des W3C zu 2.4.11 Fokus nicht verdeckt beschreibt unter anderem zwei Wege, die beide bestehen:
- Modales Banner. Das Banner sperrt die Seite, bis der Besucher eine Wahl getroffen hat. Dann muss es sich auch wie ein Dialog verhalten: Der Fokus liegt im Banner, und die Seite dahinter ist für die Tastatur nicht erreichbar, bis das Banner geschlossen ist. So beschreibt das W3C modale Dialoge im Understanding-Dokument zu 2.4.3 Fokus-Reihenfolge: „focus is set within the dialog“ und der Inhalt außerhalb „becomes inert and cannot receive focus“.
- Nicht modales Banner. Das Banner bleibt am Rand stehen, und Besucher können die Seite trotzdem benutzen. Dann darf es kein fokussiertes Element vollständig verdecken. Das W3C nennt als Lösung, die Seite mit Abstand (scroll padding) so zu gestalten, dass das Banner nichts überlagert.
Das W3C schreibt dazu wörtlich: „A notification implemented as sticky content, such as a cookie banner, will fail this success criterion if it entirely obscures a component receiving focus. Ways of passing include making the banner modal so the user has to dismiss the banner before navigating through the page, or using scroll padding so the banner does not overlap other content.“ Als weiteren Weg nennt das W3C Hinweise, die keine Aktion verlangen und sich schließen, sobald sie den Fokus verlieren.
Ein Fehler ist also die Mischform: Das Banner sperrt die Seite optisch mit einem grauen Schleier, aber der Fokus wandert mit Tab trotzdem hinter das Banner auf Elemente, die Sie nicht sehen. Verschwindet das Element ganz hinter dem Banner, verletzt das 2.4.11; liegt es nur unter dem grauen Schleier, prüfen Sie, ob der Fokusrahmen dort noch 3:1 Kontrast hat (1.4.11). Kein Fehler in Stufe AA ist ein Banner, das ein fokussiertes Element nur teilweise verdeckt; 2.4.11 verlangt nur, dass es „not entirely hidden“ ist (2.4.11). Und Escape ist keine Pflicht: Nach 2.1.2 Keine Tastaturfalle genügt es, dass der Fokus mit der Tastatur wieder herauskommt; braucht das mehr als Pfeil- oder Tabtasten oder andere übliche Wege, muss das Banner sagen, wie.
Checkliste je WCAG-Kriterium: was der Anbieter liefert, was Sie einstellen
Die Kriterien und Stufen stammen aus den WCAG 2.2 in der Fassung vom 12. Dezember 2024. Die Spalten „Meist vom Anbieter“ und „Meist Ihre Einstellung“ sind unsere Einschätzung für typische Consent-Tools. Bei einem selbst programmierten Banner liegt alles bei Ihnen oder Ihrer Agentur.
| Kriterium (Stufe) | Was Sie am Banner prüfen | Meist vom Anbieter | Meist Ihre Einstellung |
|---|---|---|---|
| 2.1.1 Tastatur (A) | Lassen sich „Alle akzeptieren“, „Ablehnen“, „Einstellungen“, jeder Schalter einer Kategorie, „Speichern“ und jeder Link (Datenschutzerklärung, Impressum) mit Tab erreichen und auslösen: Knöpfe und Schalter mit Enter oder Leertaste, Links mit Enter? | Bedienelemente als echte Knöpfe und Schalter | Eigene Knöpfe, die Sie per HTML oder Skript ergänzt haben; Link „Cookie-Einstellungen“ im Fußbereich, mit dem Besucher das Banner wieder öffnen |
| 2.1.2 Keine Tastaturfalle (A) | Kommen Sie nach einer Wahl wieder aus dem Banner und aus der Detailansicht heraus? | Schließen und Zurück im Dialog | Nichts, außer Sie haben das Verhalten per Skript verändert |
| 2.4.3 Fokus-Reihenfolge (A) | Modales Banner: Liegt der Fokus im Banner, und kommt die Seite dahinter erst nach der Wahl? Nach dem Schließen: Geht der Fokus an einer sinnvollen Stelle weiter, nicht irgendwo in der Mitte der Seite? | Fokusführung im Dialog | Wahl zwischen modaler und nicht modaler Darstellung, falls das Tool beides anbietet |
| 2.4.7 Fokus sichtbar (AA) | Sehen Sie auf jedem Knopf und Schalter, wo der Fokus steht? | Fokusrahmen im Standard-Design | Eigenes CSS, das den Fokusrahmen entfernt (etwa „outline: none“); Farben, bei denen der Rahmen im Hintergrund verschwindet |
| 2.4.11 Fokus nicht verdeckt (Minimum) (AA, neu in 2.2) | Nicht modales Banner: Verschwindet beim Durchtabben ein fokussiertes Element der Seite vollständig hinter dem Banner? Verdecken sich Banner, Chat-Knopf und fixierte Leisten gegenseitig? | Abstand oder Modalität im Standard | Position des Banners, Größe, fixierte Kopf- und Fußleisten im Theme, Chat- und Overlay-Knöpfe anderer Apps |
| 1.4.3 Kontrast (Minimum) (AA) | Hat jeder Text im Banner mindestens 4,5:1, große Schrift mindestens 3:1? Besonders prüfen: hellgraue Links wie „Nur notwendige“ oder „Ablehnen“, Text auf Knöpfen in Ihrer Markenfarbe | Standardfarben | Fast immer Sie: Farben, die Sie im Tool an Ihre Marke anpassen |
| 1.4.11 Nicht-Text-Kontrast (AA) | Ist bei jedem Schalter erkennbar, ob er an oder aus ist, mit mindestens 3:1 gegenüber der Umgebung? Haben Knopfränder, die einen Knopf erst als Knopf erkennbar machen, und der Fokusrahmen mindestens 3:1? | Form der Schalter | Farben für Schalter, Ränder und Akzent |
| 4.1.2 Name, Rolle, Wert (A) | Liest ein Screenreader jeden Schalter mit Namen und Zustand vor, etwa „Marketing, Schalter, aus“? Hat das Schließen-Kreuz einen Namen statt nur „Knopf“? | Technischer Aufbau der Bedienelemente | Ein Kreuz oder Symbol, das Sie selbst ergänzt haben; leere Beschriftungen, wenn Sie Texte im Tool gelöscht haben |
| 1.3.1 Info und Beziehungen (A) | Sind Überschriften im Banner auch technisch Überschriften? Gehört jeder Erklärtext erkennbar zu seiner Kategorie? | Aufbau des Dialogs | Texte, die Sie als fett formatierten Absatz statt als Überschrift einfügen |
| 3.1.1 Sprache der Seite (A) und 3.1.2 Sprache von Teilen (AA) | Ist die Sprache der Seite technisch angegeben? Erscheint das Banner auf Ihrer deutschen Seite ganz oder teilweise auf Englisch, muss dieser Teil als Englisch ausgezeichnet sein, sonst liest ein Screenreader ihn mit deutscher Aussprache | Sprachversionen und Sprachauszeichnung | Spracheinstellung im Tool, Übersetzung eigener Texte |
| 1.4.10 Umbruch (AA) | Bei 320 CSS-Pixel Breite oder 400 Prozent Zoom: Passt das Banner auf den Bildschirm, ohne seitlich zu scrollen? Sind die Knöpfe noch erreichbar, oder ragen sie unten aus dem Bild? | Responsives Layout | Lange Texte, große Schrift, eigene Höhen- und Breitenangaben im CSS |
| 2.5.8 Zielgröße (Minimum) (AA, neu in 2.2) | Sind Knöpfe, Schalter und das Schließen-Kreuz mindestens 24 mal 24 CSS-Pixel groß oder mit genug Abstand zueinander? Auf dem Smartphone prüfen | Standardgrößen | Verkleinerte Knöpfe oder Links im eigenen CSS |
Wie Sie Kontraste nachrechnen und welche Werkzeuge es dafür gibt, steht im Ratgeber Farbkontrast nach WCAG prüfen.
Was die Anbieter selbst angeben
Wir haben nur Aussagen aufgenommen, die wir in der Dokumentation oder auf der Website des Herstellers selbst gelesen haben (alle am 23.10.2026). Es sind Herstellerangaben, keine unabhängige Prüfung durch uns. Fehlt Ihr Anbieter, heißt das nicht, dass er nichts liefert, nur dass wir keine belegte Aussage gefunden haben.
| Anbieter | Was der Hersteller angibt | Was das für Sie heißt |
|---|---|---|
| Usercentrics, auch für Cookiebot | Auf der Seite zur WCAG-Konformität nennt Usercentrics unter anderem die „Usercentrics Cookiebot CMP“ und die Web CMP und schreibt: „All layers of the Usercentrics cookie banner for all of our plans have been tested against WCAG 2.2 AA compliance requirements and have passed.“ Als Grundlage nennt die Seite einen Prüfbericht (VPAT) der Firma Zoonou Limited. | Dieselbe Seite schränkt ein: „Any custom changes to the default settings of the Usercentrics products may impact the accessibility of the banner(s)“. Wer Farben oder CSS ändert, prüft selbst nach. Fragen Sie nach dem Prüfbericht und seinem Datum. |
| Borlabs Cookie (WordPress) | In den Release-Notes zu Version 3.3: Der Dialog lasse sich mit drei Farbeinstellungen anpassen „while ensuring compliance with WCAG 2.1 Level AA accessibility requirements“; außerdem verbesserte Tastaturbedienung, und Escape setze den Fokus auf „Schließen“ oder „Zurück“. | Die Aussage zur Konformität betrifft den Farbassistenten und nennt WCAG 2.1, nicht 2.2. Aktuelle Version verwenden und Kriterien wie 2.4.11 und 2.5.8 selbst prüfen. |
| Real Cookie Banner (WordPress) | Im Hilfeartikel zur Barrierefreiheit: Das Plugin „aims to be accessible according to WCAG 2.2 Level AA standard“; es sei vollständig per Tastatur bedienbar, und der Designbereich zeige an, ob ein eigenes Design den Anforderungen genügt. | „Aims“ heißt Ziel, nicht geprüfte Konformität. Nutzen Sie die Anzeige im Designbereich, wenn Sie Farben ändern. |
| Shopify (eigenes Cookie-Banner) | Die Shopify-Hilfe zu den Datenschutzeinstellungen beschreibt, dass Sie Farben, Inhalte und Position des Banners anpassen. Eine Aussage zur Barrierefreiheit des Banners haben wir dort nicht gefunden. | Farben und Position liegen bei Ihnen; prüfen Sie 1.4.3, 1.4.11 und 2.4.11 nach jeder Änderung. Was Shopify sonst zur Barrierefreiheit belegt, steht in Shopify barrierefrei machen nach BFSG. |
Ein Widget, das nur verspricht, Ihre Seite automatisch barrierefrei zu machen, ersetzt kein barrierefreies Banner; warum, erklärt der Ratgeber Overlay-Widgets: warum ein Plugin für Barrierefreiheit nicht reicht. Prüfen Sie dort auch, ob der schwebende Knopf eines solchen Widgets Ihr Cookie-Banner überdeckt.
Fragen an Ihren Consent-Anbieter
- Gegen welchen Maßstab ist das Banner geprüft: WCAG 2.1 oder 2.2, Stufe AA? Von wem, und von wann ist der Prüfbericht?
- Gilt die Prüfung für das Standard-Design oder auch für angepasste Farben und Texte?
- Warnt das Tool, wenn Ihre Farben den Kontrast unterschreiten?
- Lässt sich das Banner modal darstellen, und wird der Fokus dann im Banner gehalten?
- Welche Sprachen gibt es, und ist die Sprache technisch ausgezeichnet?
- Welche bekannten Mängel gibt es, und bis wann werden sie behoben?
Legen Sie die Antworten ab. Sie helfen bei Ihrer Barrierefreiheitserklärung und belegen, dass Sie sich gekümmert haben.
Der 5-Minuten-Test
Öffnen Sie Ihren Shop in einem privaten Fenster, damit das Banner wieder erscheint. Die Minuten sind unser Vorschlag, keine Vorgabe. Notieren Sie jede Stelle, an der eine Antwort Nein ist, mit Browser und Bildschirmfoto.
| Minute | Was Sie tun | Bestanden, wenn | Kriterium |
|---|---|---|---|
| 0 bis 1 | Seite laden, Maus weglegen, Tab drücken, bis Sie im Banner sind. Jeden Knopf und Link einmal anspringen | Sie erreichen jedes Element und sehen immer den Fokus | 2.1.1, 2.4.7 |
| 1 bis 2 | „Einstellungen“ öffnen, einen Schalter mit der Leertaste umschalten, speichern | Der Schalter wechselt sichtbar seinen Zustand, Speichern funktioniert, Sie kommen aus der Detailansicht heraus | 2.1.1, 2.1.2, 1.4.11 |
| 2 bis 3 | Seite neu laden, diesmal nicht im Banner wählen, sondern weiter Tab drücken | Modales Banner: Der Fokus bleibt im Banner. Nicht modales Banner: Kein fokussiertes Element der Seite verschwindet ganz dahinter | 2.4.3, 2.4.11 |
| 3 bis 4 | Fenster auf etwa 1280 Pixel Breite, Zoom auf 400 Prozent; dann auf dem Smartphone öffnen | Banner passt ohne seitliches Scrollen, alle Knöpfe bleiben erreichbar und lassen sich treffen | 1.4.10, 2.5.8 |
| 4 bis 5 | Die hellsten Texte und die Knöpfe mit einem Kontrastprüfer messen; im Fußbereich den Link zu den Cookie-Einstellungen mit Tab erreichen und auslösen | Text mindestens 4,5:1, große Schrift 3:1, Banner öffnet sich wieder | 1.4.3, 2.1.1 |
Wenn Sie zusätzlich zehn Minuten haben, hören Sie das Banner einmal mit einem Screenreader, etwa VoiceOver auf dem Mac oder iPhone oder NVDA unter Windows: Werden die Schalter mit Namen und Zustand vorgelesen, und klingt der Text deutsch? Das prüft 4.1.2 und 3.1.2. Wie der Tastaturtest für den Rest des Shops geht, steht im Tastaturtest in 10 Minuten.
Wo Sie welchen Fund beheben
- Farben, Kontrast, Fokusrahmen: in den Design-Einstellungen Ihres Consent-Tools oder im eigenen CSS. Zurück zum Standard-Design ist oft die schnellste Lösung.
- Banner verdeckt den Fokus: Position ändern, Banner modal schalten, falls das Tool es anbietet, oder im Theme unten Abstand für das Banner einplanen. Prüfen Sie auch fixierte Leisten und Chat-Knöpfe.
- Tastatur, Fokusführung, Vorlesen: Das liegt fast immer im Code des Anbieters. Melden Sie den Fund mit Browser, Taste und Ergebnis, etwa: „Safari auf macOS: Nach Tab vom Knopf Ablehnen springt der Fokus hinter das Banner auf die Seite, obwohl die Seite grau gesperrt ist. WCAG 2.4.3.“ Reagiert der Anbieter nicht, wechseln Sie das Tool.
- Sprache: Spracheinstellung im Tool prüfen und eigene Texte übersetzen.
Testen Sie erneut nach jedem Update des Consent-Tools, nach jeder Änderung an Farben oder Texten und nach jeder neuen App, die etwas am Bildschirmrand einblendet.
Dieser Ratgeber ist keine Rechtsberatung. Im Zweifel klären Sie Ihren Fall mit der Bundesfachstelle Barrierefreiheit oder einer Anwältin oder einem Anwalt.
Ihr nächster Schritt
Der kostenlose Scan prüft Ihre Startseite, eine Produktseite und den Warenkorb automatisch gegen die WCAG-Regeln, ohne Anmeldung, und zeigt, was zuerst behoben werden sollte. Automatische Werkzeuge finden nur einen Teil aller Barrieren: Ob Sie Ihr Cookie-Banner nur mit der Tastatur bedienen können und ob es den Fokus verdeckt, prüfen Sie zusätzlich von Hand mit dem 5-Minuten-Test oben.
Stand: 23.10.2026. Quellen gelesen am 23.10.2026.