Cookie-Banner barrierefrei gestalten

Ein Cookie-Banner ist Teil der Website und unterliegt damit denselben Anforderungen wie alles andere darauf – zusätzlich muss er datenschutzrechtlich eine echte, freiwillige Entscheidung ermöglichen. Praktisch heißt das: per Tastatur vollständig bedienbar, mit sichtbarem Fokus, der nicht verdeckt wird, und mit einer Ablehnung, die genauso leicht erreichbar ist wie die Zustimmung.

Das Erste, was viele auf einer Website treffen, ist der Consent-Layer – und genau er ist oft die erste Barriere: ein Fokus, der im Nichts hängt, Schaltflächen, die die Tastatur nicht erreicht, oder ein „Ablehnen“, das absichtlich versteckt wird. Er berührt damit zwei Welten gleichzeitig: Barrierefreiheit und Datenschutz. Das Unangenehme daran: Beide Welten kommen zu denselben Forderungen, aber aus völlig verschiedenen Richtungen.

Das Wichtigste in Kürze

• Der beste Banner ist keiner. Wer nur technisch unbedingt erforderliche Cookies setzt, braucht nach § 25 Abs. 2 TDDDG keine Einwilligung.
• Blockierend oder nicht ist die eine Weichenstellung, aus der alles Weitere folgt: Fokus-Falle ja/nein, Dialog-Semantik ja/nein.
• Natives <dialog> mit showModal() liefert Top-Layer, Inertisierung des Hintergrunds, Startfokus und Esc-Verhalten geschenkt.
• Ablehnen so leicht wie Zustimmen – auf derselben Ebene, als echter Button, gleich groß und gleich sichtbar.
• „Einstellungen“ ist keine Ablehnung. Ein Banner mit „Alle akzeptieren“ und „Einstellungen“ bietet nur einen der beiden Wege an.
• Der Widerruf muss so einfach sein wie die Einwilligung – also ein dauerhaft erreichbarer, tastaturbedienbarer Einstiegspunkt.

Der beste Banner ist keiner

Vorweg, weil ehrlich: Der zugänglichste Consent-Layer ist der, den es nicht gibt. § 25 Abs. 2 TDDDG nimmt zwei Fälle von der Einwilligungspflicht aus – wenn alleiniger Zweck die Übertragung einer Nachricht über ein Telekommunikationsnetz ist (Nr. 1), oder wenn Speicherung und Zugriff unbedingt erforderlich sind, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten Dienst zur Verfügung stellen kann (Nr. 2).

Wer nur solche 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.

Ein Detail, das dabei oft untergeht: Ein Banner, der auch für einwilligungsfreie Zwecke um Zustimmung bittet, macht die Sache nicht sicherer, sondern erzeugt eine Einwilligung, die es gar nicht bräuchte – und damit eine zusätzliche Fehlerquelle.

Wann der Banner Pflicht wird

§ 25 Abs. 1 TDDDG ist der Kern: Speicherung von Informationen auf dem Endgerät oder Zugriff darauf sind nur zulässig, wenn der Endnutzer auf Grundlage klarer und umfassender Informationen eingewilligt hat. Für die Anforderungen an diese Einwilligung verweist die Norm auf die DSGVO.

Daraus folgen drei Dinge, die keine Gestaltungsfrage sind:

• Aktive Handlung. Weiterscrollen, Weiterklicken oder bloßes Weiterlesen sind keine Einwilligung; vorangekreuzte Kästchen ebenso wenig.
• Kein berechtigtes Interesse. Der Bericht der Cookie-Banner-Taskforce des Europäischen Datenschutzausschusses hält ausdrücklich fest, dass sich das Speichern und Auslesen von Informationen auf dem Endgerät nicht auf ein berechtigtes Interesse stützen lässt.
• Informiert. „Wir und 847 Partner verbessern Ihr Erlebnis“ ist keine klare und umfassende Information.

Der Sanktionsweg dafür läuft übrigens über das TDDDG, nicht über die 4-%-Bußgelder der DSGVO – die greifen erst für die nachgelagerte Verarbeitung.

Blockierend oder nicht? Die eine Weichenstellung

Bevor eine Zeile Code entsteht, muss diese Frage beantwortet sein:

• Blockierend (modal): Die Seite ist erst nach einer Entscheidung nutzbar. Dann verhält sich der Banner wie ein modaler Dialog – mit Fokus hinein, Fokus halten und Esc.
• Nicht blockierend: Ein Hinweis, der die Seite nicht sperrt. Dann gehört er nicht in eine Fokus-Falle, braucht keine Dialog-Semantik und darf die Tab-Reihenfolge nicht sprengen.

Beides ist zulässig, und keins von beiden ist automatisch barrierefrei oder automatisch rechtssicher. Das Understanding-Dokument des W3C nennt „den Banner modal machen“ sogar ausdrücklich als eine Lösung für das Verdeckungsproblem – die Wahl bleibt trotzdem eine Abwägung.

Der modale Banner mit nativem <dialog>

Wenn er blockiert, ist das native <dialog> heute die klar beste Grundlage. Der Browser liefert kostenlos, was man sonst mühsam nachbaut:

<dialog id="consent" aria-labelledby="consent-titel">
  <h2 id="consent-titel">Cookies auf dieser Seite</h2>
  <p>
    Notwendige Cookies sind gesetzt. Zusätzlich möchten wir die Nutzung messen –
    nur mit Ihrer Einwilligung.
  </p>
  <div class="consent-aktionen">
    <button type="button" value="reject" autofocus>Alle ablehnen</button>
    <button type="button" value="accept">Alle akzeptieren</button>
    <button type="button" value="settings" class="ghost">Auswählen</button>
  </div>
</dialog>

const dialog = document.getElementById('consent');
dialog.showModal();

// Esc gilt als Ablehnung, nicht als „später entscheiden"
dialog.addEventListener('cancel', () => speichern('reject'));

Was showModal() mitbringt: Platzierung im Top Layer, automatisches inert für alles außerhalb, den Startfokus nach den in der HTML-Spezifikation definierten Schritten, Schließen per Esc und ::backdrop zum Abdunkeln des Hintergrunds.

Drei Dinge, die man dabei falsch machen kann:

• Kein tabindex auf <dialog>. MDN ist hier ungewöhnlich deutlich: Das Attribut darf an diesem Element nicht verwendet werden.
• Kein role="dialog" und kein aria-modal="true" von Hand. Die Rolle ist implizit, und bei showModal() ist aria-modal ohnehin implizit true. Doppelt gesetzt richtet es eher Schaden an.
• Startfokus bewusst setzen. Ohne autofocus greift die Spezifikationsregel: erst autofocus am <dialog> selbst, sonst der Focus-Delegate, sonst der Dialog. Bei einem Consent-Layer will man das steuern – ich setze autofocus auf „Alle ablehnen“, weil das die zurückhaltendste Vorbelegung ist.

Zum Esc-Verhalten noch ein Gedanke, der über Technik hinausgeht: Esc darf hier nicht „wegklicken ohne Entscheidung“ bedeuten, denn dann würde ohne Einwilligung weitergesurft – aber auch nicht „akzeptieren“. Die einzige saubere Auslegung ist Esc = ablehnen. Deshalb sollte man closedby="none" hier nicht einsetzen, um Esc zu unterbinden; das Attribut ist ohnehin noch jung und nicht überall verfügbar.

Fallback ohne <dialog>

Wo das native Element nicht in Frage kommt, muss man alles selbst bauen:

<div class="consent" role="dialog" aria-modal="true" aria-labelledby="consent-titel">
  <h2 id="consent-titel">Cookies auf dieser Seite</h2>
  …
</div>

document.getElementById('seite').inert = true; // nicht aria-hidden!

Wichtig ist hier inert auf dem Seiten-Wrapper, nicht aria-hidden: aria-hidden versteckt den Hintergrund nur vor Screenreadern, die Tastatur tabbt weiter fröhlich hindurch. Dazu kommt eine eigene Fokus-Falle und der Rückfokus nach dem Schließen. Die WAI-ARIA Authoring Practices formulieren letzteren so: Der Fokus geht zurück zu dem Element, das den Dialog geöffnet hat – sofern es noch existiert. Bei einem beim Seitenaufruf automatisch geöffneten Banner gibt es dieses Element nicht; dann gehört der Fokus an den Anfang des Hauptinhalts, auf ein Element mit tabindex="-1".

Der nicht blockierende Banner

Blockiert der Layer nicht, ist die Lösung schlichter – und die belastbarste Referenz dafür ist das GOV.UK Design System:

<body>
  <section class="cookie-banner" role="region" aria-label="Cookie-Hinweis">
    <h2>Cookies auf dieser Seite</h2>
    <p>…</p>
    <button type="button">Alle akzeptieren</button>
    <button type="button">Alle ablehnen</button>
    <a href="/cookies.html">Mehr erfahren</a>
  </section>

  <a class="skip" href="#main">Zum Inhalt springen</a>
  …

Der Banner steht direkt nach dem öffnenden <body> und vor dem Sprunglink – so ist er das Erste, was Tastatur und Screenreader erreichen, ohne dass man ihn in eine Falle sperren muss. Er bekommt eine eigene Landmark mit aria-label und eine sichtbare Überschrift. Was er nicht bekommt: ein dauerhaftes aria-live="polite" über dem gesamten Banner – das zerhackt den Lesefluss.

Für die Bestätigung nach der Auswahl nutzt GOV.UK eine Meldung mit role="alert" und tabindex="-1", auf die der Fokus verschoben wird – bewusst ohne sichtbaren Fokusindikator, damit sie nicht wie ein Bedienelement wirkt.

Fokus nicht verdecken (2.4.11)

Ein am unteren Rand klebender Banner verdeckt gern genau das Element, das gerade den Fokus hat. Das WCAG-2.2-Kriterium 2.4.11 Fokus nicht verdeckt (Stufe AA) verlangt, dass ein fokussiertes Bedienelement nicht vollständig verdeckt wird – und das Understanding-Dokument nennt Cookie-Banner ausdrücklich als Beispiel für genau diesen Fall.

Zwei Präzisierungen, die häufig fehlen: Es geht um vollständige Verdeckung. Teilverdeckung verletzt erst das AAA-Kriterium 2.4.12. Und: Es genügt nicht, das Problem zu kennen – es gibt eine dokumentierte Technik dagegen.

:root { --consent-hoehe: 12rem; }

html { scroll-padding-block-end: var(--consent-hoehe); }

// Die Höhe mitziehen, wenn der Banner umbricht oder gezoomt wird
new ResizeObserver(([eintrag]) => {
  document.documentElement.style.setProperty(
    '--consent-hoehe',
    `${eintrag.target.offsetHeight}px`,
  );
}).observe(document.querySelector('.cookie-banner'));

scroll-padding-block-end sorgt dafür, dass der Browser beim Fokussieren weit genug scrollt, damit das Element über dem Banner landet. Alternativen: den Banner modal machen oder ihn ausblenden, solange anderswo gearbeitet wird. Das GOV.UK Design System hat sich 2023 aus genau diesem Grund entschieden, Cookie-Banner nicht am oberen Seitenrand festzukleben.

Ablehnen muss so leicht sein wie Zustimmen

Barrierefreiheit ist hier auch eine Frage der Fairness. „Alle akzeptieren“ als bunter Riesenknopf und „Ablehnen“ als blasser Mini-Link ist ein Dark Pattern – und aus beiden Richtungen angreifbar.

Die Negativliste, die sich in Prüfungen immer wieder findet:

• „Einstellungen“ statt „Ablehnen“. Ein Weg zu einer zweiten Ebene ist keine Ablehnung.
• Vorangekreuzte Kästchen oder Kategorien, die auf „an“ stehen.
• Ablehnen als Textlink neben einem Button.
• Wiederholte Einblendung nach einer Ablehnung.
• Confirmshaming („Nein, ich möchte kein besseres Erlebnis“).
• Beschönigende Formulierungen, die den Zweck verschleiern.

Was Gerichte und Aufsicht dazu sagen

Zwei Bezugspunkte lohnen sich, und beide muss man richtig einordnen.

VG Hannover, Urteil vom 19. März 2025 (Az. 10 A 5385/22). Das Gericht verlangte konkret drei gleich große, gleich sichtbare und gleichermaßen unschwer erkennbare Schaltflächen auf der zentralen Bedienebene. Beanstandet wurden unter anderem, dass die Ablehnung deutlich aufwendiger war als die Zustimmung und dass der Banner wiederholt eingeblendet wurde. Wichtig für die Einordnung: Das ist ein erstinstanzliches Verwaltungsgerichtsurteil, keine höchstrichterliche Rechtsprechung – zur Rechtskraft liegen keine belastbaren Informationen vor.

EDSA-Cookie-Banner-Taskforce, Bericht vom 18. Januar 2023. Der Bericht bildet den kleinsten gemeinsamen Nenner der Aufsichtsbehörden bei der Bearbeitung einer Beschwerdewelle ab; er ist ausdrücklich keine eigenständige Empfehlung und keine Freigabe. Die Kernlinie: Wo auf einer Ebene ein Zustimmen-Button steht, muss auf derselben Ebene auch eine Ablehnung möglich sein. Bemerkenswert ist, was der Bericht nicht sagt: Eine allgemeine Vorgabe zu Farbe oder Kontrast der Schaltflächen könne den Verantwortlichen nicht auferlegt werden – das bleibt Einzelfallprüfung. Nur der Extremfall (Text, der sich kaum vom Hintergrund abhebt) wird als Verstoß benannt.

Für die Praxis heißt das: Die Gleichwertigkeit ergibt sich nicht aus einer Farbvorschrift, sondern aus Erreichbarkeit, Klickaufwand und Erkennbarkeit. Und genau da trifft sich das Datenschutzrecht mit der Barrierefreiheit – denn Kontrast und Zielgröße sind dort sehr wohl in Zahlen geregelt.

Größe, Kontrast, Klickfläche: die Zahlen

Drei Klarstellungen dazu, weil sie regelmäßig durcheinandergehen:

• 44 × 44 Pixel sind AAA (2.5.5), nicht AA. Die AA-Grenze liegt bei 24 × 24 – mit fünf Ausnahmen, von denen für Banner vor allem die Spacing-Ausnahme greift.
• Der Standard-Fokusring des Browsers muss die 3:1 nicht erfüllen – 1.4.11 nimmt die vom Browser bestimmte Darstellung aus. Die Pflicht entsteht in dem Moment, in dem du outline überschreibst.
• Reflow verlangt 320 CSS-Pixel, nicht „400 % Zoom“. Die 400 % sind nur die daraus abgeleitete Prüfmethode bei 1280 px Fensterbreite. Mehr dazu unter Reflow, Zoom & Textabstände.

.cookie-banner button {
  min-inline-size: 2.75rem;
  min-block-size: 2.75rem;
  padding: 0.6rem 1.2rem;
}

.cookie-banner button:focus-visible {
  outline: 3px solid #0b3d91;
  outline-offset: 2px;
}

/* Auf 320 px muss der Inhalt umbrechen statt zu scrollen */
.consent-aktionen { display: flex; flex-wrap: wrap; gap: 0.5rem; }
.cookie-banner { max-block-size: 50vh; overflow-y: auto; }

Und weil das Icon-Kreuz der Klassiker ist:

<button type="button">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24" width="16" height="16">
    <path d="M6 6l12 12M18 6L6 18" stroke="currentColor" stroke-width="2"/>
  </svg>
  <span class="visually-hidden">Alle ablehnen und schließen</span>
</button>

Nachmessen lässt sich der Kontrast mit dem Kontrast-Check.

Die zweite Ebene: Kategorien richtig auszeichnen

Sobald es eine Auswahlebene gibt, wird der Banner zum Formular – und Formularsemantik ist erstaunlich oft das Erste, was in Consent-Tools fehlt.

<form method="dialog">
  <fieldset>
    <legend>Notwendig</legend>
    <p class="hinweis">
      Diese Cookies sind für den Betrieb erforderlich und lassen sich nicht
      abwählen.
    </p>
    <input type="checkbox" id="c-noetig" checked disabled>
    <label for="c-noetig">Technisch notwendige Cookies</label>
  </fieldset>

  <fieldset>
    <legend>Reichweitenmessung</legend>
    <input type="checkbox" id="c-analyse" name="zwecke" value="analyse">
    <label for="c-analyse">Anonyme Statistik zur Nutzung dieser Seite</label>

    <details>
      <summary>Welche Cookies sind das?</summary>
      <table>
        <caption>Cookies zur Reichweitenmessung</caption>
        <thead>
          <tr><th scope="col">Name</th><th scope="col">Anbieter</th><th scope="col">Dauer</th></tr>
        </thead>
        <tbody>
          <tr><td>_pk_id</td><td><span lang="en">Matomo</span></td><td>13 Monate</td></tr>
        </tbody>
      </table>
    </details>
  </fieldset>

  <button type="submit" value="save">Auswahl speichern</button>
</form>

Die Punkte, auf die es ankommt:

• Echte <input type="checkbox"> mit <label for>, kein nachgebauter ARIA-Switch. Siehe Labels & Beschriftungen.
• Ein <fieldset> mit <legend> pro Zweck – damit die Zuordnung auch dann stimmt, wenn man sich die Felder einzeln vorlesen lässt (Fieldset & Legend).
• Alles außer „notwendig“ standardmäßig unchecked.
• <details>/<summary> für Detailtexte statt ARIA-Disclosure-Bastelei (Details & Summary).
• Cookie-Listen als echte <table> mit <caption> und <th scope>, nicht als display: table auf <div>s.
• lang an fremdsprachigen Dienstnamen – in einer Cookie-Tabelle betrifft das fast jede Zeile (3.1.2 Sprache von Teilen).

Widerruf: der vergessene halbe Weg

Die DSGVO verlangt, dass der Widerruf so einfach ist wie die Erteilung. Praktisch heißt das: ein dauerhaft erreichbarer, im Tab-Fluss liegender Einstiegspunkt – üblicherweise ein Link oder Button „Cookie-Einstellungen“ im Fußbereich.

Zwei Fallen: Ein schwebendes Grafik-Icon ohne zugänglichen Namen ist keine Lösung. Und der sichtbare Text muss im zugänglichen Namen enthalten sein – steht „Cookie-Einstellungen“ auf dem Button, darf der Name nicht „Datenschutz-Präferenzen verwalten“ lauten, sonst findet die Sprachsteuerung ihn nicht (2.5.3).

Was nicht vorgeschrieben ist: eine bestimmte Widerrufslösung. Der EDSA-Bericht stellt ausdrücklich fest, dass Betreibern keine konkrete Umsetzung – insbesondere keine Hovering-Lösung – auferlegt werden kann. Gefordert ist die leichte Erreichbarkeit, nicht das Icon unten links.

Wenn ein fremdes Tool den Banner baut

In der Praxis kommt der Layer meist von einem Consent-Management-Anbieter. Das ändert an der Verantwortung nichts: Nach dem BFSG ist der Betreiber der Dienstleistung verpflichtet, nicht sein Werkzeuglieferant.

Eine Fallstudie von Make Things Accessible hat elf Banner kommerzieller und offener Anbieter getestet – bestanden hat dort nur die GOV.UK-Variante vollständig. Das ist eine Momentaufnahme und kein Urteil über einzelne Produkte, aber es sagt genug über die Ausgangslage.

Was hilft:

• Vor der Auswahl eine Barrierefreiheitserklärung oder VPAT anfordern – und sie lesen, statt dem Siegel zu glauben. Eine staatliche Zertifizierung für Consent-Tools gibt es nicht.
• Selbst testen, bevor der Vertrag steht: zehn Minuten Tab-Durchlauf reichen für ein erstes Urteil.
• CSS- und JS-Overrides als Notlösung – Klickflächen vergrößern, Fokusindikatoren wiederherstellen, Buttons angleichen.
• Nachbessern lassen und die Anfrage dokumentieren; das gehört später in die Barrierefreiheitserklärung.

Fällt der Cookie-Banner unter das BFSG?

Das BFSG gilt seit dem 28. Juni 2025 – aber nicht für jede Website. Einschlägig sind „Dienstleistungen im elektronischen Geschäftsverkehr“ nach § 2 Nr. 26 BFSG, also digitale Dienste, die auf den Abschluss eines Verbrauchervertrags gerichtet sind. Eine reine Informationsseite ohne Vertragsabschluss fällt regelmäßig nicht darunter.

Wenn das BFSG greift, ist der Banner Teil der Dienstleistung – ein Bestellprozess, den man nur über einen unbedienbaren Consent-Layer erreicht, ist nicht barrierefrei.

Drei Präzisierungen, weil hier viel Halbwissen kursiert:

• Die Kleinstunternehmen-Ausnahme (§ 3 Abs. 3 BFSG) gilt nur für Dienstleistungen, nicht für Produkte – und nur bei weniger als 10 Beschäftigten und höchstens 2 Mio. € Jahresumsatz oder Bilanzsumme.
• Der Bußgeldrahmen ist gestaffelt: Nach § 37 Abs. 2 BFSG stehen bis zu 100.000 € nur für bestimmte Ordnungswidrigkeiten; für Verstöße gegen Informations- und Dokumentationspflichten sind es höchstens 10.000 €. Das sind Höchstbeträge, keine Regelsätze.
• Technischer Maßstab ist die harmonisierte Norm EN 301 549 V3.2.1, die auf WCAG 2.1 AA aufsetzt. WCAG 2.2 ist die fachlich richtige Zielmarke und wird der künftige Maßstab sein – geltende Rechtspflicht ist sie noch nicht.

Ob dich das Gesetz betrifft, klärt die BFSG-Prüfung; die Ausnahmen und Fristen stehen unter Ausnahmen, Fristen, Bußgeld.

Und das zweite Argument ist unabhängig davon tragfähig: Eine Einwilligung, die man nicht bedienen kann, ist keine wirksame Einwilligung. Wer per Tastatur den Ablehnen-Button nicht erreicht, hat nicht freiwillig zugestimmt.

Weniger Banner, ohne das Recht zu brechen

Seit dem 1. April 2025 gilt die Einwilligungsverwaltungsverordnung (EinwV). Sie schafft den Rahmen für anerkannte Dienste zur Einwilligungsverwaltung nach § 26 TDDDG: Nutzende hinterlegen ihre Entscheidung einmal zentral, Websites fragen sie ab, statt jeden einzeln zu behelligen. Die Anerkennung erteilt der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit; anerkannte Dienste stehen in einem öffentlichen Register.

Der Realitäts-Check gehört dazu: Stand Juli 2026 steht dort genau ein Dienst („Consenter“, anerkannt am 17. Oktober 2025). Und die Einbindung ist nach § 18 EinwV freiwillig – eine Befreiung von der Bannerpflicht ist sie nicht.

Für die Barrierefreiheit bringt die Verordnung übrigens nichts: § 4 EinwV verlangt eine „transparent und verständlich“ gestaltete Oberfläche; WCAG, BITV oder Barrierefreiheit kommen im Verordnungstext nicht vor.

Was sich gerade ändert

Die EU-Kommission hat am 19. November 2025 das „Digital Omnibus“-Paket vorgelegt. Der geplante Art. 88a DSGVO würde die Cookie-Einwilligung in die DSGVO verlagern und unter anderem eine Ablehnung mit einem einzigen Klick vorschreiben; Art. 88b zielte auf verbindliche maschinenlesbare Browser-Signale.

Der Stand ist allerdings unübersichtlich: Der Datenteil war Mitte 2026 noch nicht im Trilog, das Parlament hatte keine Position, und Kompromissvorschläge im Rat sahen die Streichung von Art. 88b vor. Geltendes Recht ist davon nichts – wer heute plant, plant nach § 25 TDDDG.

Selbst testen in zehn Minuten

1. Nur mit Tab durch den Banner: Kommt der Fokus hinein? Bleibt er drin, solange blockiert wird? Kommt er wieder heraus?
2. Esc drücken. Passiert etwas Sinnvolles – und was wird gespeichert?
3. Fokus verfolgen: Ist der Indikator überall sichtbar, und wird das fokussierte Element nie vollständig verdeckt?
4. Screenreader (NVDA oder VoiceOver): Gibt es eine Überschrift? Ist der Zweck klar? Haben alle Schaltflächen Namen?
5. Fenster auf 320 px verkleinern: Bricht alles um, oder muss man seitwärts scrollen?
6. Kontrast messen – für beide Schaltflächen, nicht nur für die grüne.
7. JavaScript abschalten: Läuft irgendein einwilligungspflichtiges Skript trotzdem?
8. Widerruf durchspielen: Findest du den Weg zurück, ohne zu suchen?

Häufige Fehler

Dazu die Fehler, die nicht die WCAG, sondern das Datenschutzrecht treffen: „Einstellungen“ statt „Ablehnen“, vorangekreuzte Kästchen, Wiedervorlage nach jeder Ablehnung – und Skripte, die schon vor der Entscheidung laufen.

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 – er gehört an den Anfang des <body>, nicht in ein <dialog>.

Darf Esc als Ablehnung gelten?

Ich halte das für die einzige saubere Auslegung: Esc darf weder zustimmen noch die Entscheidung überspringen. Wichtig ist, dass das Verhalten im Banner benannt wird – dann ist es transparent statt überraschend.

Reicht ein „Alle akzeptieren“-Button?

Nein. Wo auf einer Ebene zugestimmt werden kann, muss auf derselben Ebene auch abgelehnt werden können. Ein „Einstellungen“-Button erfüllt diese Funktion nicht.

Muss der Banner beim Laden den Fokus greifen?

Wenn er blockiert: ja, sonst tabbt man in eine Seite, die man nicht bedienen kann. Wenn er nicht blockiert: besser nicht – dann reicht die Position ganz vorn im DOM.

Muss ich WCAG 2.1 oder 2.2 erfüllen?

Rechtlich verbindlich ist über die harmonisierte EN 301 549 V3.2.1 derzeit WCAG 2.1 AA. Fachlich würde ich trotzdem gegen WCAG 2.2 arbeiten – 2.4.11 und 2.5.8, die beiden für Banner wichtigsten neuen Kriterien, sind genau die, an denen Consent-Layer in der Praxis scheitern.

Was, wenn der CMP-Anbieter nicht nachbessert?

Dann bleibt die Verantwortung trotzdem bei dir. Kurzfristig helfen CSS- und JS-Overrides, mittelfristig ist der Anbieterwechsel die ehrlichere Antwort – und bis dahin gehört der bekannte Mangel in die Barrierefreiheitserklärung.

Wie vermeide ich den Banner ganz?

Indem du auf einwilligungspflichtige Cookies und Dienste verzichtest. Analyse ohne Einwilligung und nur technisch notwendige Cookies kommen ohne Consent-Layer aus – Details auf der Datenschutz-Seite.

Fazit

Der beste Cookie-Banner ist keiner. Muss einer sein, entscheidet zuerst die Frage, ob er blockiert: Dann ist ein natives <dialog> mit showModal() die Grundlage, Esc bedeutet Ablehnung, und der Fokus kommt hinein und hinterher wieder zurück. Blockiert er nicht, gehört er unauffällig an den Anfang des <body> – mit scroll-padding-block-end gegen die Verdeckung des Fokus. In beiden Fällen gilt dieselbe Regel für die Bedienung: Annehmen und Ablehnen sind gleichwertige Wege, in einem Klick erreichbar, mit 4,5 : 1 Kontrast und 24 × 24 Pixel Klickfläche. So wird aus der ersten Hürde ein fairer erster Eindruck – und aus einer angreifbaren Einwilligung eine, die trägt.

Quellen

• § 25 TDDDG – Schutz der Privatsphäre bei Endeinrichtungen (Gesetzestext – Einwilligungspflicht und die beiden Ausnahmen)
• Understanding SC 2.4.11 Focus Not Obscured (Minimum) (W3C WAI – nennt Cookie-Banner ausdrücklich als Beispielfall, mit Technik C43)