Cookie banner

Problem Context

• The site or service uses cookies, local storage, pixels, analytics, personalization, advertising, service-worker storage, or other technology that stores or accesses information on a user's device.
• Some storage is strictly necessary for security, sessions, basket state, load balancing, or the requested service, while other storage needs consent.
• Users may arrive on public pages, signed-in routes, embedded flows, mobile screens, JavaScript-disabled sessions, or shared devices where the most recent choice should govern.
• The organization needs evidence of what was offered, what purposes were accepted or rejected, and whether the runtime respected the stored preference.

Selection Rules

• Choose cookie banner when a user must be told about cookies or similar technologies and must be able to accept or reject non-essential storage before it is set.
• Do not show a banner only for strictly necessary cookies; instead explain those cookies on a cookies page or privacy route.
• Offer accept and reject actions for non-essential cookies at the same decision level when asking for consent.
• Use manage settings when users need purpose-level choices, but do not hide the only reject path behind multiple steps.
• Show a confirmation after a choice and save the preference by purpose, version, timestamp, and device scope for an appropriate period.
• Keep cookie settings reachable after the banner is hidden so users can withdraw or change consent.
• Use banner, notification banner, or site alert for operational or service messages that do not collect privacy consent.
• Use modal dialog only when a separate, high-consequence decision truly requires blocking interaction; do not make cookie consent a trap.
• Block optional cookies, tracking pixels, analytics, personalization, advertising, and similar storage until the relevant consent is present.
• Use a server-side or no-JavaScript route when optional storage can be set before client code runs.

Required States

• First visit with no saved preference.
• Essential-only service with no banner and a visible cookies page link.
• Accept non-essential cookies state.
• Reject non-essential cookies state.
• Manage purpose-level preferences state.
• Saved preference confirmation message.
• Returning visitor with banner hidden and stored choice applied.
• Changed cookie version or new purpose requiring renewed choice.
• Withdrawal or change-preference state from a stable cookies page link.
• No-JavaScript or server-side submission state.
• Runtime blocked state where optional scripts wait for consent.

Interaction Contract

• The banner appears before non-essential storage is set and remains until the user accepts, rejects, or saves preferences.
• Accept, reject, and manage controls are keyboard reachable, clearly labelled by purpose, and visually comparable enough that one choice is not pushed over another.
• Reject means non-essential purposes remain off, not merely that the banner is closed.
• Manage settings shows non-essential purposes off unless the user already saved consent for them.
• Saving a choice updates runtime consent state, records the preference, hides the prompt, and shows a short confirmation that can be closed.
• The cookies page or footer link lets users review, withdraw, or change choices without searching through unrelated privacy copy.
• The banner does not obscure focused content, trap focus, auto-accept on scroll, or make ordinary service access depend on accepting optional tracking.

Implementation Checklist

• Audit and classify each cookie or similar technology as strictly necessary or non-essential before writing banner copy.
• Map each non-essential purpose to a clear user-facing label such as analytics, personalization, advertising, or feedback measurement.
• Block optional tags, pixels, analytics, local storage, service-worker storage, and third-party scripts until the stored consent state permits them.
• Provide equal-level accept and reject actions, plus manage settings when purpose-level choices are needed.
• Persist preference version, purposes, timestamp, and expiry, and refresh consent when purposes or storage behavior change.
• Show a confirmation message after accept, reject, or save, then provide a hide control without losing the settings route.
• Link to a cookies page from the banner and footer, and let that page update the same consent store.
• Test first visit, return visit, reject, accept, manage settings, withdrawal, no JavaScript, shared devices, mobile wrapping, zoom, keyboard order, screen readers, and network proof that optional storage is blocked.

Common Generated-UI Mistakes

• Accept-only banners.
• Reject hidden behind settings while accept is shown as the only button.
• Preselected non-essential categories.
• Firing optional tracking before consent.
• Treating scroll, swipe, close, or continued browsing as consent.
• Using deceptive contrast so reject appears disabled or secondary beyond recognition.
• Blocking service access after a user refuses non-essential cookies.
• Saving one vague consent flag with no purpose, version, or withdrawal route.
• Using cookie banner for outage, marketing, validation, or account notices.

Critique Questions

• Which cookies or similar technologies are strictly necessary, and which need consent?
• Can users reject non-essential purposes with effort comparable to accepting them?
• Does the runtime actually block optional storage until consent exists?
• What preference version, purposes, timestamp, and expiry are saved?
• Where can users change or withdraw the choice after the banner is hidden?
• Does this message belong to cookie consent, or is it a banner, notification banner, site alert, modal dialog, privacy settings, or legal acceptance flow?