Nicht Barrierefreie Einwilligungsbanner Erzeugen Jetzt Zwei Rechtliche Risiken, Nicht Nur Eines

Seit dem 28. Juni 2025 ist ein Einwilligungsbanner, das ein Tastaturnutzer nicht vollständig navigieren kann, nicht nur ein Barrierefreiheitsversagen — es ist ein DSGVO-Verstoß. Der European Accessibility Act (EAA) trat an diesem Tag in allen 27 EU-Mitgliedstaaten in Kraft und machte WCAG 2.2 Level AA zum rechtlich durchsetzbaren Standard für digitale Dienste, einschließlich der Einwilligungs-Interfaces, von denen Analytics-Tools abhängen.

Die beiden Regulierungsregime sind nun direkt gekoppelt. Beheben Sie das eine ohne das andere, und Sie sind weiterhin exponiert.

Was der EAA tatsächlich verlangt

Der EAA verweist auf den europäischen Standard EN 301 549, der wiederum auf WCAG 2.2 Bezug nimmt. Für Einwilligungs-Interfaces sind die in der Praxis wichtigsten Anforderungen:

• Fokus nicht verdeckt (WCAG 2.4.11): Wenn ein Nutzer mit Tab zu einem Button springt, darf dieser nicht vollständig hinter dem Banner selbst oder einem Sticky-Header verborgen sein.
• Tastaturzugänglichkeit (WCAG 2.1.1): Jedes interaktive Element — Akzeptieren, Ablehnen, Einstellungen verwalten — muss ohne Maus erreichbar und bedienbar sein.
• Sichtbare Fokus-Indikatoren (WCAG 2.4.7): Fokusringe müssen sichtbar sein. Viele Consent-Management-Plattformen unterdrücken die Browser-Standard-Fokus-Styles aus kosmetischen Gründen, was dieses Kriterium verletzt.
• Ausreichender Farbkontrast (WCAG 1.4.3): Text gegenüber dem Hintergrund muss für Fließtext 4,5:1 erfüllen. Blassgraue „Alle ablehnen"-Links neben fettgedruckten blauen „Akzeptieren"-Buttons sind ein häufiges Fehlermuster.
• Keine automatische Schließung: Das Banner kann nicht ohne ausdrückliche Nutzerinteraktion geschlossen werden. Zeitgesteuertes automatisches Akzeptieren, selbst nach mehreren Sekunden, ist ungültig.

Die Strafen variieren je nach Mitgliedstaat. Deutschland verhängt bis zu 100.000 € pro Verstoß. Spanien eskaliert in schweren Fällen auf 1.000.000 €. Frankreich kombiniert Geldbußen mit der möglichen Aussetzung des nicht konformen Dienstes.

Warum Barrierefreiheitsversagen die DSGVO-Einwilligung unwirksam macht

Erwägungsgrund 32 der DSGVO verlangt, dass die Einwilligung „freiwillig, für den bestimmten Fall, in informierter Weise und unmissverständlich" abgegeben wird. Artikel 7 fügt hinzu, dass der Widerruf der Einwilligung „so einfach wie deren Erteilung" sein muss. Diese Anforderungen gelten nur, wenn der Nutzer tatsächlich auf das Einwilligungs-Interface zugreifen kann.

Ein Screenreader-Nutzer, der nicht zum „Ablehnen"-Button navigieren kann, kann seine Einwilligung nicht verweigern. Die Einwilligung, die Ihre Analytics-Pipeline für diesen Nutzer aufzeichnet, ist rechtlich bedeutungslos — nicht weil er sie verweigert hat, sondern weil der Mechanismus nicht zugänglich war. Nach der DSGVO zählt das als überhaupt keine Einwilligung.

Die CNIL hat diese Logik in ihrer Durchsetzungsmaßnahme vom September 2025 gegen Google ausdrücklich gemacht, bei der eine Geldbuße von 325 Millionen Euro teilweise auf asymmetrisches Design folgte — Akzeptieren erforderte einen Klick, Ablehnen erforderte das Navigieren zu einer Einstellungsmaske. Jedes Design, das die Ablehnung strukturell schwieriger macht als die Annahme — einschließlich eines Banners, das ein Tastaturnutzer nicht vollständig bedienen kann — untergräbt die rechtliche Gültigkeit jedes Einwilligungsdatensatzes, den es erzeugt.

Die Audit-Ergebnisse sind nicht ermutigend

Unabhängige Tests weit verbreiteter Consent-Management-Plattformen im Jahr 2025 ergaben, dass keine einzige untersuchte Lösung vollständige WCAG 2.2 Level AA Konformität erfüllte. Häufige Fehler umfassten unterdrückte Fokus-Indikatoren, unzureichenden Kontrast bei sekundären Aktions-Buttons und Banner-Markup, das spät im DOM positioniert war — was dazu führte, dass Screenreader Seiteninhalte vor dem Einwilligungs-Interface antrafen.

Dies sind keine Randfälle. Es ist das Standardverhalten von Tools, die Zehntausende von Websites einsetzen, um Analytics zu nutzen, ohne die rechtliche Analyse selbst durchzuführen.

Was Sie ein konformes Banner operativ kostet

Angenommen, Sie beheben die Barrierefreiheitsprobleme. Sie haben jetzt ein Banner, das ein Screenreader vollständig navigieren kann, mit tastaturzugänglichen Bedienelementen, ausreichendem Kontrast und ohne automatische Schließung. Sie stehen immer noch vor:

• Datenverlust durch Ablehnung: Studien zeigen konsistent, dass 15–30 % der Besucher entweder Analytics-Cookies ablehnen oder das Banner schließen, ohne zu interagieren. Diese Population ist für Ihre Analytics unsichtbar.
• Variabilität der Einwilligungsrate nach Gerät: Mobilnutzer schließen Banner häufiger als Desktop-Nutzer. Ihre Analytics-Daten sind systematisch verzerrt zugunsten von Nutzern, die auf Desktop akzeptiert haben.
• Laufende Wartung: WCAG 2.2 ist bereits in der Entwicklung hin zu WCAG 3.0. Jedes Update Ihrer Consent-Plattform ist eine potenzielle Regression in der Barrierefreiheits-Konformität, die Sie erneut testen müssen.

Die Behebung des Banners adressiert die EAA-Exposition. Sie adressiert nicht das Datenqualitätsproblem.

Die strukturelle Alternative

Cookie-freies Analytics, das das Gerät nie berührt — keine Cookies, kein localStorage, kein Fingerprinting — löst keine PECR-Einwilligungspflichten aus. Es ist kein Einwilligungsmechanismus erforderlich, also existiert auch kein Einwilligungs-Interface, das nicht zugänglich sein könnte.

Der Ansatz des täglichen Besucher-Hashs — SHA-256(IP + UA + SALT_SECRET + YYYY-MM-DD) — läuft vollständig serverseitig am Edge, erzeugt keine persistente Kennung und speichert nichts auf dem Gerät des Besuchers. Es gibt keine Interaktion, die WCAG regulieren müsste, und keinen Einwilligungsdatensatz, den die DSGVO validieren müsste.

Dies ist keine Umgehung. Es ist die technische Konsequenz daraus, ein Analytics-System zu bauen, das tatsächlich keine personenbezogenen Daten verarbeitet. Wenn es nichts gibt, dem zugestimmt werden müsste, verschwindet die Einwilligungsmaschinerie und all ihre Compliance-Verpflichtungen.

Die zwei Fragen, die jetzt es wert sind, gestellt zu werden

Wenn Ihre Website derzeit Analytics hinter einem Einwilligungsbanner betreibt, bestimmen zwei Fragen Ihre Exposition:

1. Can a keyboard-only user reach the "Reject All" option in your banner
   without a mouse, with a visible focus indicator, on every browser
   you support?

2. If yes — what percentage of visitors reject or dismiss the banner,
   and how does your analytics account for that gap?

Die erste Frage ist die EAA-Frage. Die zweite ist die Datenqualitätsfrage. Ein konformes Einwilligungsbanner, das 20 % der Besucher ablehnen, hinterlässt Sie immer noch mit einem 20-%-Blindfleck, der sich im Laufe der Zeit verstärkt, da Ihre Entscheidungen auf unvollständigen Traffic-Daten basieren.

Keine der beiden Fragen stellt sich, wenn es kein Banner zu navigieren gibt.