Key takeaways

A good cookie banner gives people a genuine choice, explains it plainly, and makes the website behave accordingly.

Last reviewed: 29 August 2026

For an EU/EEA-oriented banner, start with Accept all, Reject all, and Manage preferences on the first layer. Do not pre-enable optional categories. Keep non-essential technologies off until the visitor makes a valid choice, support withdrawal, and test on desktop and mobile.

Do not chase a universal “best” acceptance rate. Benchmarks rarely compare the same audience, wording, traffic source, and method. Improve comprehension without making refusal harder.

Cookie consent joins three parts: the decision interface, the website's behaviour before and after a choice, and the preference lifecycle. A polished banner cannot repair broken blocking, and perfect blocking cannot make a misleading interface fair.

The legal baseline also matters. Article 5(3) of the EU ePrivacy Directive covers storing information on, or accessing information from, a user's device; its wording is not limited to files called cookies. Where consent is required, GDPR Article 4(11) defines it as freely given, specific, informed, and unambiguous. In sections 3.1.4 and 3.1.5 of its Guidelines 05/2020 on consent, the European Data Protection Board (EDPB) explains why a cookie wall generally prevents a freely given choice and why scrolling or swiping is not a sufficiently clear affirmative action.

National implementation and guidance vary. If you serve several markets, use the cookie consent requirements by country guide to identify local differences. The practices below provide a user-respecting starting point.

Scope and methodology

This guide addresses ordinary website consent interfaces, with the EU/EEA framework as its main legal reference. It uses official legislation, regulator guidance, court material, and accessibility standards available on the review date. Legal, enforcement, and WCAG claims link to that evidence.

The article separates legal baselines from design recommendations. Words such as “must” refer to the cited rule in the stated context. Phrases such as “sensible default” and “good starting point” are practical recommendations, not claims that one design fits every jurisdiction.

National laws and site facts can change the result. UK rules, analytics exemptions, paid-or-consent models, and technologies without device storage may need separate assessment. This is general information, not legal advice.

The observational test below compares a fresh browser state before a choice, after refusal, after selective consent, and after withdrawal. A scanner sees only the routes and interactions tested; it cannot establish every vendor role, legal basis, or untested behaviour.

The first layer should quickly say who is asking, why the site wants to use optional technologies, and how the visitor can accept, refuse, or choose by purpose.

Put accept, reject, and preferences on the first layer

For a typical EU/EEA consent request, use three direct controls:

Control What it should do
Accept all Enable all clearly described optional purposes
Reject all Keep all optional purposes disabled
Manage preferences Open purpose-level choices without changing them first

Acceptance and refusal should require comparable effort. If “Accept all” takes one click, “Reject all” should not require opening settings, scrolling through several categories, and confirming twice.

The buttons need not look identical, but the visual hierarchy must not make refusal difficult to find or read. Check:

  • similar size and readable type;
  • no low-contrast reject link;
  • no large, saturated accept button beside a faint text-only refusal;
  • direct labels rather than vague options such as “Continue” or “Maybe later”;
  • a logical keyboard focus order.

France's data protection authority, CNIL, says in its current enforcement material that refusing cookies should be as easy as accepting them and describes ordering organizations to provide a refusal mechanism as easy as the acceptance mechanism (CNIL, “Refusing cookies should be as easy as accepting them”). A visible first-layer reject option is therefore a sensible default for an EU/EEA-oriented site, even though national wording and case-specific requirements can differ.

Keep the first layer short, not empty

Do not put the full cookie policy in a popup. State that the site uses optional technologies, identify the main purposes, show the three choices, name the business if necessary, and link to details.

Avoid a wall of text, but do not reduce the explanation to “We value your privacy.” That phrase says nothing about what will happen.

Match the site without disguising the choice

Use the site's typeface, spacing, and restrained brand colours so the banner feels trustworthy. Keep it visually distinct from the page, however. A visitor should not mistake a consent control for navigation, a newsletter form, or a checkout button.

Two banner anatomy patterns

Illustrative

We use optional analytics cookies to understand site use. Choose what works for you.

Accept allReject allManage
Cookie policy
  • Balanced controls
  • Plain wording
  • Readable contrast
  • Policy access
Illustrative

Help us improve your experience with cookies.

Accept and continueManage settings
Privacy details
  • One prominent path
  • Vague consequence
  • Refusal is de-emphasized
  • Details are less direct
Fictional interface anatomy for discussing choice design. This illustration is not a legal-compliance assessment of any banner.

Consent copy should describe actions, purposes, and consequences in ordinary language. Legal terms can appear in the policy, but the decision itself should not require legal training.

Use concrete labels

Prefer:

We use optional analytics cookies to understand how people use this website. We will only set them if you choose “Accept all” or enable Analytics in preferences.

Avoid:

We and our partners leverage technologies to optimize your experience and deliver personalized content.

The second version hides which technologies, partners, and purposes are involved.

Button labels should also state the result:

  • Accept all
  • Reject all
  • Manage preferences
  • Save choices

Avoid “OK,” “Got it,” or “Continue” when clicking would record consent. Acknowledging that a notice exists is not the same as agreeing to optional processing.

Do not use guilt or urgency

Copy such as “No, I prefer a worse experience” pressures the visitor. Avoid guilt-laden reject labels, “you will miss out” warnings, countdowns, repeated same-visit prompts, and extra confirmation steps applied only to refusal.

You may explain an honest consequence where one exists. Keep that explanation neutral, specific, and separate from the choice label.

Explain categories and vendors clearly

Categories make a complex list easier to understand, but vague categories can conceal more than they reveal. Describe each purpose in terms of what happens.

Common category Plain-language description Default before consent
Strictly necessary Keeps requested features working, such as login, security, or a shopping basket On; explain why it cannot be switched off
Preferences Remembers optional settings that are not essential to the requested service Off unless a valid exception applies
Analytics Measures visits and interactions so the site owner can understand site use Off unless a documented local exemption applies
Marketing Supports advertising, campaign measurement, or tracking across services Off

“Strictly necessary” is a narrow test, not a synonym for useful. The exception in ePrivacy Directive Article 5(3) applies where storage or access is strictly necessary to provide an information-society service explicitly requested by the user. Analytics may be important to the business without being necessary to show the requested page. Some national authorities recognize tightly conditioned audience-measurement exceptions, so assess the actual configuration and applicable national rule rather than the category name alone.

In the preference layer:

  • identify each purpose;
  • show optional toggles off by default;
  • explain what enabling a category does;
  • name relevant third parties or provide an easy route to the vendor list;
  • disclose durations and access to details in the cookie policy;
  • separate purposes where a visitor could reasonably want one but not another;
  • provide Save choices and Reject all controls that remain easy to reach.

Do not bundle unrelated purposes into a single “partners” switch. The EDPB's Guidelines 05/2020, section 3.2 discusses the GDPR's requirement for purpose-specific, granular consent.

The most common implementation failure is a banner that asks politely while analytics and advertising tags have already run. Consent must affect website behaviour, not merely store a banner response.

Before consent, inventory more than cookies. Check analytics and advertising requests, pixels, embeds, social widgets, browser storage, tag-manager rules, and scripts added by plugins, themes, or chat tools.

Some tools can load in a restricted state; others must be held back. Follow current vendor documentation, and do not assume that changing a tag's label changes what it sends.

Test the four important states

Use a fresh browser profile or clear site data before each test.

  1. Before any choice: optional technologies should remain inactive where prior consent is required.
  2. After Reject all: they should remain inactive.
  3. After selective consent: only the chosen categories should activate.
  4. After withdrawal: technologies should stop on future activity, and the stored preference should update.

Also test direct landing pages, not only the home page. A campaign page, blog post, or embedded checkout may use a different template.

Our guide to blocking cookies before consent explains the implementation principle. For a hands-on browser check, follow how to audit website cookies and how to test a cookie consent banner.

Check your current starting point: run the free cookie scanner to identify cookies found during a scan. A scanner is useful evidence, but it cannot decide every legal exemption or guarantee that every possible user journey has been tested.

Dark patterns turn the banner into a steering mechanism. The EDPB's cookie-banner taskforce report addresses recurring banner practices examined by European supervisory authorities. CNIL also describes misleading banner designs—including interfaces that make refusal less visible—in its 2025 formal-notice announcement on cookie-banner dark patterns. In a cookie banner, the following patterns deserve immediate attention.

Unequal choices

Examples include:

  • a bright “Accept all” button and a barely visible refusal;
  • acceptance on the first layer but rejection several screens away;
  • a close icon that secretly means consent;
  • extra confirmation steps that apply only to refusal.

The test is not whether a determined privacy professional can eventually find the option. Ask whether an ordinary visitor can understand and choose it without needless friction.

Preselected optional categories

Optional checkboxes or toggles must not start in the “on” position when consent is the basis. In its Planet49 judgment, Case C-673/17, the Court of Justice of the European Union held that consent was not validly constituted by a pre-checked checkbox that the user had to deselect. The visitor must take an affirmative action.

Do not interpret closing the banner or inactivity as consent. The EDPB's Guidelines 05/2020, section 3.1.5 specifically explain that scrolling or swiping through a page does not satisfy the clear-and-affirmative-action requirement.

A cookie wall blocks access unless the visitor accepts optional tracking. In Guidelines 05/2020, example 6, the EDPB gives the example of a website that makes content access conditional on accepting cookies and says this does not present a genuine choice.

Paid-or-consent models and narrowly framed service designs can raise more complex questions. They are not a shortcut for a small-business site. Get specialist advice before conditioning access on optional tracking.

Endless prompting

Repeatedly showing the banner after refusal can wear people down. Remember the choice for an appropriate period, subject to applicable local guidance and meaningful changes to purposes or vendors. Do not ask again on every page or visit merely because the answer was no.

Mobile is not a smaller desktop. A banner that looks modest on a laptop can hide the entire page, push controls below the viewport, or create an impossible scroll area on a phone.

Test at 320 CSS pixels wide and on representative real devices. Check:

  • all decision controls are visible or clearly reachable;
  • text can enlarge without overlapping buttons;
  • preference-panel scrolling remains understandable;
  • there is no horizontal overflow;
  • controls have enough space to avoid accidental taps;
  • zoom, landscape orientation, and the on-screen keyboard do not break the layout;
  • the banner does not cover essential controls.

WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum) uses a 24 by 24 CSS pixel baseline and lists exceptions. Larger controls and spacing are often more comfortable, especially for primary banner actions. Do not quote a single preferred banner height as a universal rule; translated copy, browser chrome, font size, and device dimensions all change the usable space.

If the preference panel has many purposes or vendors, use progressive disclosure. Show understandable categories first, then let interested visitors inspect details. Keep “Reject all” and “Save choices” easy to reach rather than burying them after a long vendor list.

Make the banner accessible

An accessible consent experience works with a keyboard, screen reader, zoom, high-contrast settings, and different input methods. One automated contrast test is not enough.

Keyboard and focus

  • Every control must work without a mouse.
  • Use native button, link, checkbox, and heading elements where possible.
  • Show visible focus in an order aligned with the visual layout.
  • Move focus into an opened dialog and return it to its trigger on close.
  • If the preference panel is truly modal, use appropriate dialog semantics and modal focus behaviour.
  • Support Escape only if closing the interface does not record consent or leave the user without a practical way to choose.

Do not automatically treat every banner as a modal. A non-modal banner should not trap focus. A modal preference dialog generally should keep keyboard interaction within the dialog until it closes.

Names, roles, and states

A screen reader should announce what each control is and whether a category is enabled. Do not build a toggle from an unlabelled <div>. Pair every form control with a programmatic label, and expose validation or status messages when choices are saved.

Keep headings descriptive. “Cookie preferences” gives users more context than “Your experience.”

Colour, reflow, and motion

WCAG 2.2 Success Criterion 1.4.3, Contrast (Minimum) sets a 4.5:1 minimum ratio for normal text and 3:1 for large text, subject to its stated exceptions. Success Criterion 1.4.11, Non-text Contrast sets a 3:1 requirement for the visual information needed to identify user-interface components and states, again subject to stated exceptions. Check actual foreground and background combinations rather than assuming a brand colour passes.

Test at 200% zoom and with text spacing increased. Respect reduced-motion preferences, and avoid animated entrances that distract from the page. Never use colour alone to show whether a category is on or off.

Showing an English banner to a visitor on a French- or German-language page weakens comprehension. Localize according to the language of the page or an explicit language choice, not an unsupported guess about nationality.

A good localization process covers the first layer, preferences, policy, and settings link. Keep purpose names consistent, use direct local-language labels, check longer text on mobile, and retest each regional configuration. Use a human reviewer for important languages.

Legal concepts do not always map word for word. Ask a qualified local reviewer when terminology could change the meaning. Also check regional rules rather than assuming that translation alone adapts the banner. The country-by-country cookie consent guide is a useful planning starting point.

Remember choices and support withdrawal

Once someone chooses, store the preference so the banner does not return on every page. The storage used to remember a consent choice can itself be necessary for honouring that choice, but keep it limited to that function.

When GDPR consent is the basis, Article 7(1) requires the controller to be able to demonstrate that the person consented. Depending on the implementation, a proportionate record may include:

  • the date and time;
  • the choice or purpose-level settings;
  • the banner or policy version;
  • the region or ruleset applied, where relevant;
  • a suitably limited identifier rather than unnecessary personal data.

Do not collect extra personal data just to prove that you practise data minimisation.

Place a persistent Cookie settings link in the footer or another predictable location. GDPR Article 7(3) says withdrawal must be as easy as giving consent. Opening preferences must not silently reset all toggles to “on,” and saving a withdrawal must update tag behaviour as well as the consent record.

Ask again when the purposes or relevant parties change enough that the earlier choice is no longer informed. A fixed re-prompt period is not universal; national guidance can differ. Document the rule you use and avoid prompting refusers more often than accepters.

Test without manipulating visitors

A/B testing can improve readability and completion, but it can also industrialize a dark pattern. Set ethical guardrails before launching an experiment.

Useful measures

Track measures that apply to all choices: completion and time to choose, preference-panel use, abandoned flows, keyboard and mobile completion, support questions, and script-blocking failures.

An acceptance rate alone cannot tell you whether the banner works well. A sudden increase may reflect clearer information, but it may also reflect a less visible reject button or an accidental default.

Safe tests and unsafe tests

Reasonable experiment Manipulative experiment
Shorter plain-language explanation versus a longer one Hiding Reject all to increase acceptance
Bottom banner versus centred dialog, with the same choices Making only Accept all look clickable
Clear category examples Preselecting optional categories
Revised mobile spacing Adding friction only to refusal
Different policy-link wording Treating banner closure as consent

Keep controls, defaults, and choice effort equivalent across variants. Segment results by device and language because a layout improvement in English desktop traffic may fail on a translated mobile interface. Keep a record of the variant shown so you can interpret the resulting consent record.

There is no trustworthy universal acceptance benchmark. Audience intent, geography, traffic source, purposes, and design all affect the result. Compare your own versions under controlled conditions.

Use this checklist before publishing and after any major website change.

Choice and copy

  • The banner identifies the main purposes in plain language.
  • Accept all, Reject all, and Manage preferences are available on the first layer where prior consent is required.
  • Refusal takes no more effort than acceptance.
  • Optional categories are off by default.
  • Closing, scrolling, or continuing to browse is not treated as consent.
  • The cookie policy and relevant vendor details are easy to reach.

Technical behaviour

  • Non-essential technologies stay inactive before consent where required.
  • Reject all leaves optional technologies inactive.
  • Selective consent activates only selected purposes.
  • Withdrawal updates both stored preferences and future tag behaviour.
  • Direct landing pages, embeds, plugins, and tag-manager rules have been tested.
  • The test is repeated after adding or updating third-party tools.

Usability and accessibility

  • The banner works at 320 CSS pixels wide and with zoom.
  • All controls work by keyboard and have visible focus.
  • Controls have accessible names, roles, and states.
  • Text and controls meet applicable contrast requirements.
  • The banner does not create horizontal overflow or hide essential actions.
  • Translations fit and preserve the intended meaning.

Preference lifecycle

  • A persistent Cookie settings link is available.
  • The site remembers acceptance and refusal appropriately.
  • Consent records identify the choice and relevant version.
  • Material purpose or vendor changes trigger review and, where needed, a new request.
  • The re-prompt approach accounts for applicable local guidance.

If you are unsure what the site currently stores, start with a free cookie scan, then verify the result manually across all four consent states. If you are comparing consent-management options for your site, review ConsentEase pricing. No scanner or consent platform can replace an accurate inventory, correct configuration, and appropriate legal advice for your circumstances.

Sources