Resource

Why most cookie banners still do not comply

Published 2025-11-11 · Updated 2026-03-03 · 8 min read · By the Europlabs team

The failures we find most often in EU cookie consent setups: pre-consent firing, unequal reject paths, bundled purposes and inaccessible banners.

The gap between config and behaviour

Nearly every site we review has a consent management platform installed and configured. Nearly every one of them also loads something it should not before anyone has clicked anything. The configuration is not the system — the page is. Anything added outside the CMP's tagging, whether hard-coded into a template, injected by a third-party embed, or added by a team that did not know the process, fires regardless of what the dashboard says.

So the only meaningful test is a network capture on a clean profile. Below are the six failures we find most often, roughly in order of frequency.

Failure 1: firing before consent

Article 5(3) of the ePrivacy Directive requires consent before storing or accessing information on a user's device, with narrow exemptions for what is strictly necessary to provide the service the user requested. Analytics is not strictly necessary. Advertising is definitely not.

The usual sources, in order: an embedded video iframe that sets cookies on load; a chat or support widget added directly to the template; a tag manager container that fires its own tags before the consent signal arrives; a font, map or CAPTCHA request that transmits the IP address to a third party before any interaction. The last category is not a cookie at all, which is exactly why it survives cookie-focused reviews.

Failure 2: refusing is harder than accepting

Consent must be freely given. Supervisory authorities across several Member States have been consistent on what that means at the interface level: if accepting takes one click, refusing must too. A prominent “Accept all” button next to a low-contrast “Manage preferences” link that leads to a panel of toggles is not an equal choice, and has been the subject of repeated enforcement decisions.

Related patterns that fail for the same reason: a reject button styled as plain text while accept is a filled button; a settings panel that requires saving each category separately; and a banner that reappears on every page load after refusal but remembers acceptance permanently.

Failure 3: bundled purposes

Consent must be specific. A single toggle covering “analytics, personalisation and marketing” does not let anyone consent to one and refuse another. Purposes need to be separable, and described in terms a person can act on — “to measure which pages are visited” rather than “to improve your experience”.

Legitimate interest deserves a mention here. Some frameworks default advertising vendors to legitimate interest rather than consent. For storing or reading information on a device, ePrivacy requires consent; legitimate interest is not an available basis for that access, whatever the vendor list says.

Failure 4: no record of consent

The GDPR accountability principle means you must be able to demonstrate that consent was given. In practice: a record of who consented, when, to which purposes, under which version of the notice, and by what mechanism. Most CMPs store this. Not all of them are configured to, and almost nobody tests that the record actually exists until someone asks for it.

The check takes two minutes: give consent, then look for the stored record. If all you have is a cookie on the user's own device saying consent=true, you have the user's copy, not yours.

Failure 5: the banner is not operable

The banner is a modal dialogue and the first interactive element every visitor meets. We regularly find banners that trap keyboard focus, do not move focus into themselves when they appear, have no accessible name or role, render the reject control at contrast below 3:1, or cannot be dismissed with Escape.

This is a double failure and the two halves reinforce each other. It is a WCAG failure under 2.1.2, 4.1.2 and 1.4.3. It is also a consent validity problem: a person who cannot operate the reject control has not freely given anything, so every downstream processing based on that consent is on weak ground.

Since WCAG 2.2, sticky banners have an extra exposure — success criterion 2.4.11 requires that the focused element not be entirely hidden, and a bottom-anchored cookie bar is the classic way to obscure focus on the elements behind it.

Failure 6: the policy does not match reality

A published cookie policy listing eleven cookies while the site sets thirty-four is a very common finding, and it is a transparency failure independent of everything above. Policies are typically written once and never reconciled against what marketing added afterwards.

Whatever else you do, generate the inventory from actual observed behaviour rather than from memory, and re-run it after any campaign or tag change.

How to check yours this afternoon

1. Open a private window with a clean profile and the network panel recording.
2. Load your homepage and a product or article page. Do not touch the banner.
3. List every third-party request and every cookie, localStorage and sessionStorage write. Anything not strictly necessary here is a finding.
4. Reload, click reject, and repeat. Anything that still fires is a more serious finding.
5. Unplug the mouse and operate the banner by keyboard only, including reaching and activating reject.
6. Accept, then verify a consent record exists on your side, not just on the device.
7. Compare the observed inventory against your published cookie policy line by line.

That sequence finds most of what a paid review finds. Where a review adds value is the parts that are easy to misjudge alone: whether an exemption genuinely applies, whether your purpose descriptions are specific enough, and having an independent written record with dates.

---