← Back to blog
5 min readprivacygdprcompliancewcagaccessibility

Inaccessible Consent Banners Now Create Two Legal Liabilities, Not One

The European Accessibility Act made WCAG 2.2 enforceable in June 2025. A banner a screen reader cannot navigate invalidates GDPR consent. Cookie-free analytics sidesteps both problems.

Since June 28, 2025, a consent banner that a keyboard user cannot navigate fully is not just an accessibility failure — it is a GDPR violation. The European Accessibility Act (EAA) came into force across all 27 EU member states on that date, making WCAG 2.2 Level AA the legally enforceable standard for digital services, including the consent interfaces that analytics tools depend on.

The two regulatory regimes are now directly coupled. Fix one without the other and you are still exposed.

What the EAA actually requires

The EAA maps to the European standard EN 301 549, which in turn references WCAG 2.2. For consent interfaces, the requirements that matter most in practice are:

  • Focus not obscured (WCAG 2.4.11): When a user tabs to a button, it must not be entirely hidden behind the banner itself or a sticky header.
  • Keyboard accessibility (WCAG 2.1.1): Every interactive element — Accept, Reject, Manage Preferences — must be reachable and operable without a mouse.
  • Visible focus indicators (WCAG 2.4.7): Focus rings must be visible. Many consent management platforms suppress browser default focus styles for cosmetic reasons, which fails this criterion.
  • Sufficient color contrast (WCAG 1.4.3): Text against background must meet 4.5:1 for body text. Pale grey "Reject All" links next to bold blue "Accept" buttons are a common failure pattern.
  • No auto-dismissal: The banner cannot close without explicit user interaction. Timed auto-accept, even after several seconds, is invalid.

Penalties vary by member state. Germany enforces up to €100,000 per violation. Spain escalates to €1,000,000 for severe cases. France combines monetary fines with possible suspension of the non-compliant service.

Why accessibility failures invalidate GDPR consent

GDPR Recital 32 requires consent to be "freely given, specific, informed and unambiguous." Article 7 adds that withdrawing consent must be "as easy as giving it." These requirements only hold if the user can actually access the consent interface.

A screen reader user who cannot navigate to the "Reject" button cannot withhold consent. The consent that your analytics pipeline records for that user is legally meaningless — not because they rejected it, but because the mechanism was inaccessible. Under GDPR, that counts as no consent at all.

The CNIL made this logic explicit in its September 2025 enforcement action against Google, where a €325 million fine followed partly from asymmetric design — accept required one click, reject required navigating to a settings screen. Any design that makes refusal structurally harder than acceptance, including a banner a keyboard user cannot fully operate, undermines the legal validity of every consent record it produces.

The audit results are not encouraging

Independent testing of widely-used consent management platforms in 2025 found that not a single solution examined met full WCAG 2.2 Level AA compliance. Common failures included suppressed focus indicators, insufficient contrast on secondary action buttons, and banner markup positioned late in the DOM — causing screen readers to encounter page content before the consent interface.

These are not edge cases. They are the default behavior of tools that tens of thousands of sites deploy to use analytics without running the legal analysis themselves.

What a compliant banner would cost you operationally

Assume you fix the accessibility problems. You now have a banner that a screen reader can fully navigate, with keyboard-accessible controls, sufficient contrast, and no auto-dismissal. You still face:

  • Data loss from rejection: Studies consistently show 15–30% of visitors either reject analytics cookies or dismiss the banner without interacting. That population is invisible to your analytics.
  • Consent rate variability by device: Mobile users close banners at higher rates than desktop users. Your analytics data is systematically biased toward users who accepted on desktop.
  • Ongoing maintenance: WCAG 2.2 is already in development toward WCAG 3.0. Each update to your consent platform is a potential regression in accessibility compliance that you need to retest.

Fixing the banner addresses the EAA exposure. It does not address the data quality problem.

The structural alternative

Cookie-free analytics that never touches the device — no cookies, no localStorage, no fingerprinting — does not trigger PECR consent requirements. No consent mechanism is required, so no consent interface exists to be inaccessible.

The daily visitor hash approach — SHA-256(IP + UA + SALT_SECRET + YYYY-MM-DD) — runs entirely server-side at the edge, produces no persistent identifier, and stores nothing on the visitor's device. There is no interaction for WCAG to govern and no consent record for GDPR to validate.

This is not a workaround. It is the technical consequence of building an analytics system that genuinely does not process personal data. When there is nothing to consent to, the consent machinery and all of its compliance obligations disappear.

The two questions worth asking now

If your site currently runs analytics behind a consent banner, two questions determine your exposure:

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?

The first question is the EAA question. The second is the data quality question. A compliant consent banner that 20% of visitors dismiss still leaves you with a 20% blind spot that compounds over time as your decisions are made on incomplete traffic data.

Neither question arises if there is no banner to navigate.