The French data protection authority CNIL published formal guidance on dark patterns in consent interfaces in early 2022, followed by enforcement action against organizations whose banners exhibited specific design failures. The German DSK issued similar guidance. The Irish DPC, the Spanish AEPD, and the Italian Garante have all referenced interface design in consent-related enforcement proceedings. The message from regulators across the EU is not subtle: how your banner looks is a compliance question, not just a UX preference.
This makes cookie banner design unusual territory — the intersection of regulatory compliance and interaction design, where a button color or click count can constitute evidence of non-compliance. What follows is a breakdown of the patterns that DPAs have specifically named, the patterns that consistently pass scrutiny, and the cases where the line is genuinely less clear.
Patterns Regulators Have Explicitly Named
Pre-checked consent boxes. This one is definitively settled law, not interpretation. GDPR Article 7(2) requires that consent be unambiguous and based on a clear affirmative action. A pre-checked box is not an affirmative action — it requires the user to actively uncheck to withhold consent, reversing the burden. The CJEU confirmed in Planet49 (C-673/17) that pre-checked boxes do not constitute valid consent. Any banner that uses them for non-essential processing is non-compliant on its face.
Reject hidden behind "Manage preferences." A banner that displays Accept All prominently and routes the reject path entirely through a preference center — requiring visitors to navigate to preferences, understand category descriptions, and manually toggle each category off — imposes significantly higher friction for rejection than for acceptance. CNIL guidance (January 2022) and subsequent enforcement decisions have framed this as an asymmetric design that impairs the freedom of consent. The fix is ensuring Reject All appears at the primary screen level, not exclusively inside a submenu.
Gray or low-contrast reject buttons. When the Accept button uses a filled, high-contrast design and the Reject button is rendered in a muted or near-invisible style, the visual hierarchy steers visitors toward acceptance without any deceptive text. This has been explicitly cited by the CNIL as a dark pattern. The visual weight of the two primary choices should be comparable. This does not require identical styling, but it does require that both buttons be clearly readable and visually prominent at the same level.
Consent walls. Requiring consent to access site content — "accept or leave" without offering a genuine alternative — is problematic under GDPR's "freely given" requirement. The EDPB Opinion 5/2019 on consent clarifies that if access to a service is made conditional on consent, that consent is generally not freely given. There is nuance here around paid alternatives and legitimate business models, but a blanket "accept all cookies or you cannot read this article" pattern on a general website is consistently found non-compliant by DPAs.
Repeated re-prompting after rejection. Showing a consent prompt again to visitors who recently and explicitly rejected, at each new session or even on each page, has been described as pestering behavior designed to wear down resistance. Once a visitor has made a clear choice, that choice should be respected for a reasonable period. Most implementations use a 6 to 12-month window before re-prompting, which is generally accepted as reasonable.
Patterns That Consistently Pass Scrutiny
The compliant design space is well-defined, even if it is less discussed than the dark patterns:
Bottom bar with equal-weight binary choice. A banner anchored to the bottom of the viewport, showing Accept All and Reject All at equal visual weight — same font size, similar contrast, similar button size — is the baseline compliant design. It is non-blocking, clearly visible, and presents the choice without steering. Many DPA-published guidance documents include visual examples consistent with this pattern.
Accept All / Reject All / Manage preferences (three-option layout). This pattern adds granularity without removing the easy rejection path. Accept All and Reject All appear at the primary level; Manage preferences is available for visitors who want control over individual categories. Provided the three options are genuinely equally accessible and the preference center is not designed to create friction, this is a strongly compliant design.
Clear, plain-language purpose description. "We use cookies to understand how you use our site and to show relevant advertising" is plain language. "We process personal data for the purposes of performance measurement, behavioral analysis, and cross-device audience segmentation" is not — it's accurate, but it fails the comprehensibility test that GDPR's information requirement implies. The banner text should communicate what is actually happening in language a general visitor can evaluate.
Functional-only by default with explicit consent for analytics and advertising. Running strictly necessary cookies (session management, shopping cart, authentication) without a consent prompt, and requiring a positive choice before loading any analytics or advertising scripts, is the correct architecture. The default state — pre-consent — should involve zero non-essential tracking.
The Less Clear Cases
We are not saying that every design decision outside the explicitly compliant pattern is automatically a dark pattern. There are genuinely contested areas:
Contextual nudge language. Wording like "Help us improve" or "Support this free service" on the consent banner is not the same as deceptive language, but it is nudging visitors toward acceptance. Whether this constitutes manipulation depends on the specific framing and context. DPAs have not uniformly ruled against positive framing; the line is roughly between honest value explanation ("this site is free because of advertising, which requires your consent to be relevant") and manipulative pressure ("Accepting supports independent journalism" as a banner headline with no further context).
Banner position and z-index. A banner that renders in a standard bottom bar but uses a z-index that covers navigation elements can effectively prevent site usage without technically being a modal. This has a similar effect to a consent wall without being one formally. Whether this passes DPA scrutiny depends on whether there is a clear way to dismiss the banner without accepting — if the X button or Reject All is accessible, the visitor has a genuine choice even if the banner is visually prominent.
A/B testing banner designs. Testing two compliant banner variants — both with Reject All at primary level, both with equal button weight — against each other for consent rate differences is generally fine. Testing a compliant variant against a dark-pattern variant to measure the difference is not. The distinction matters: learning what language communicates best within a compliant design space is reasonable; using A/B tests to find the most effective manipulation and deploying the winner is not.
Practical Checklist Before Deployment
Before publishing a new or updated consent banner, a short verification sequence:
- Count the clicks required to reject all non-essential cookies. It should match the click count for accepting all.
- Check the visual contrast of Accept versus Reject at the primary screen level using browser dev tools. Both should pass WCAG AA contrast for text on their respective backgrounds, and neither should be visually dominant over the other.
- Confirm no consent-purpose checkboxes are pre-checked on initial load.
- Verify that the page is usable — navigation functions, content is readable — if a visitor dismisses the banner without making a choice, and that no non-essential scripts have fired in the pre-choice state.
- Confirm the banner does not re-appear within a session after a visitor has made an explicit choice.
- Check on mobile: bottom bars that obscure large portions of a mobile screen have different friction profiles than desktop. Ensure the reject option is accessible without scrolling on common mobile viewport sizes.
This checklist covers the most commonly cited failure modes in DPA findings. It does not guarantee compliance with every possible regulatory interpretation — privacy law continues to develop — but it addresses the patterns regulators have already shown willingness to act on.
This article is for educational purposes and does not constitute legal advice. Consult qualified legal counsel regarding consent interface compliance in your specific jurisdiction.