Warum Barrierefreiheit und Einwilligung jetzt überlappen

Die DSGVO verlangt, dass die Einwilligung von jedem Nutzer eingeholt werden kann, nicht nur von denen, die ein Banner sehen und darauf klicken können. Der Europäische Datenschutzausschuss hat klargestellt, dass wenn eine betroffene Person nicht in sinnvoller Weise mit dem Einwilligungs-Interface interagieren kann — aufgrund einer Behinderung, die die Website nicht berücksichtigt hat — die Einwilligung nicht wirksam erteilt wurde. Das bedeutet, dass die Cookies von vornherein nicht geladen werden dürfen.

Auf der Seite der Barrierefreiheit macht der European Accessibility Act (EAA), der in den nationalen Rechtsvorschriften aller EU-Mitgliedstaaten umgesetzt wurde, WCAG 2.1 AA zum Minimum für Websites und Apps des Privatsektors, die Verbraucherdienste anbieten. Das Sanktionsregime variiert je nach Land, liegt aber typischerweise zwischen 50.000 und 500.000 Euro pro Verstoß, zuzüglich Marktabzugsanordnungen bei anhaltender Nichteinhaltung.

Die grundlegenden WCAG-Anforderungen für Cookie-Banner

Tastaturbedienbarkeit

Jedes Banner-Steuerelement — Akzeptieren, Ablehnen, Einstellungen verwalten, Schließen — muss ausschließlich mit der Tastatur erreichbar und bedienbar sein. Benutzer sollten in der Lage sein, mit Tab in logischer Reihenfolge durch die Schaltflächen zu navigieren und diese mit Enter oder Space zu aktivieren. Der Fokus muss mit einem Mindestkontrasterhältnis von 3:1 zum Hintergrund sichtbar sein.

Fokus-Trap in modalen Bannern

Wenn das Banner die Interaktion mit dem Rest der Seite blockiert, muss der Tastaturfokus innerhalb des Banners gefangen bleiben, bis der Benutzer eine Wahl trifft. Benutzer sollten nicht in der Lage sein, mit Tab aus dem Banner heraus auf die darunter liegende Seite zu scrollen. Wenn der Fokus gefangen war und das Banner schließt, sollte der Fokus zu dem Element zurückkehren, das das Banner ausgelöst hat, oder zu einem sinnvollen Standard.

Screenreader-Ankündigungen

Das Banner muss als Dialog mit einem zugänglichen Namen und einer Rolle angekündigt werden. Verwenden Sie role="dialog" oder role="alertdialog" mit aria-labelledby, das auf die Banner-Überschrift zeigt, und aria-describedby, das auf den erklärenden Text zeigt.

Farbkontrast

Fließtext muss einen Kontrast von 4,5:1 zum Hintergrund erfüllen; großer Text (18pt+ oder 14pt fett) benötigt 3:1. Schaltflächentext, Icons und Fokusindikatoren haben alle ihre eigenen Kontrastmindestanforderungen. Eine hellgraue „Ablehnen"-Schaltfläche auf weißem Hintergrund ist ein häufiger WCAG-Fehler, den wir bei Audits sehen.

Keine ausschließlich farbbasierten Hinweise

Verlassen Sie sich nicht ausschließlich auf Farbe, um Akzeptieren von Ablehnen zu unterscheiden. Verwenden Sie deutliche Beschriftungen, Icons oder Formen, damit Nutzer mit Farbblindheit die Schaltflächen unterscheiden können.

Dark Patterns und Barrierefreiheit

WCAG 2.2 führt neue Kriterien ein, die direkt auf Dark Patterns abzielen — besonders relevant für Einwilligungen:

• 3.3.8 Zugängliche Authentifizierung — verbietet kognitive Rätsel als Einwilligungshindernis.
• 3.3.7 Redundante Eingabe — Benutzer sollten nicht erneut Informationen eingeben müssen, nur um die Einwilligung zu widerrufen.
• 2.4.11 Fokus nicht verdeckt — das Banner selbst sollte den Fokusindikator von Elementen dahinter nicht verdecken.
• 2.5.7 Ziehbewegungen — wenn Ihr Banner eine Zieh-zum-Akzeptieren-Interaktion verwendet, muss eine Einzel-Zeiger-Alternative existieren.

RTL und Internationalisierung

Barrierefreiheit erstreckt sich auf Rechts-nach-links-Sprachen (Arabisch, Hebräisch, Persisch, Urdu) und auf die Aussprache von Screenreadern:

• Setzen Sie dir="rtl" auf das Banner, wenn die Dokumentensprache RTL ist, damit Schaltflächenreihenfolge und Fokusfluss der Leserichtung entsprechen.
• Verwenden Sie korrekte lang-Attribute bei übersetzten Banner-Texten, damit Screenreader Wörter mit der richtigen Phonetik aussprechen.
• Ikonographie spiegeln — Pfeile, Chevrons und Fortschrittsindikatoren sollten für RTL-Gebietsschemas umgekehrt werden.

Ihr Banner auf WCAG-Konformität testen

Verlassen Sie sich nicht auf ein einzelnes Tool. Kombinieren Sie automatisiertes Scanning mit echten Tests mit unterstützender Technologie:

• axe DevTools oder Lighthouse — erkennt automatisch ca. 30–40 % der WCAG-Fehler.
• NVDA oder JAWS auf Windows, VoiceOver auf Mac/iOS, TalkBack auf Android — testen Sie mit echten Screenreadern. Kann das Banner nur mit dem Screenreader angekündigt, navigiert und geschlossen werden?
• Nur-Tastatur-Navigation — stecken Sie die Maus aus. Wenn Sie nicht Akzeptieren, Ablehnen und Einstellungen verwalten können, können Tastaturnutzer das auch nicht.
• Farbenblindheitssimulation — Chrome DevTools hat eingebaute Simulatoren für Sehbeeinträchtigungen. Überprüfen Sie, ob Akzeptieren und Ablehnen unter Protanopie, Deuteranopie und Tritanopie unterscheidbar sind.
• Auf 400 % zoomen — WCAG verlangt, dass Inhalte bei 400 % Zoom ohne horizontales Scrollen nutzbar bleiben. Banner mit fester Position scheitern häufig an diesem Test.

Häufige Barrierefreiheitsfehler, die wir sehen

• Ablehnen hinter einem Zahnrad-Icon versteckt — Dark Pattern plus Barrierefreiheitsfehler (kein zugänglicher Name auf dem Icon-Button).
• Fokus erreicht das Banner nie — Banner, die visuelle Aufmerksamkeit stehlen, aber in der Tab-Reihenfolge übersprungen werden.
• Modales Banner ohne Fokus-Trap — Benutzer können auf die Hintergrundseite tabben, während das Banner behauptet, die Interaktion zu blockieren.
• Kein aria-live bei Einstellungsänderungen — Screenreader-Nutzer hören keine Bestätigung, dass ihre Wahl gespeichert wurde.
• Übersetzte Banner ohne lang-Attribut — Screenreader sprechen spanischen Text mit englischer Phonetik aus.

Wie FlexyConsent Barrierefreiheit bereitstellt