Fylde-Digital-Logo-Final
Contact us
back to all

UK websites: 3 cookie banner templates that follow GOV.UK and WCAG

A compliant, user-friendly cookie banner gives visitors equal-weight Accept and Reject buttons on first view, offers granular opt-in for anything beyond strictly necessary cookies, and stays reachable afterwards through a persistent preference control. GOV.UK’s cookie banner component, the EDPB’s taskforce report, and WCAG 2.2’s focus guidance all point the same direction: refusal has to be as easy as agreement.

TL;DR:

  • Effective cookie banners must present equal, clearly visible Accept and Reject options on first view, with granular preferences accessible later through a persistent control.
  • Banner designs that push content rather than overlay or fixate, like GOV.UK’s push-down or unobtrusive bottom bars, improve accessibility and user experience without obscuring focus.
  • Every compliant banner requires clear purpose statements, visible equal actions, detailed preferences, and a link to the full policy, with proper focus management for accessibility.
  • Most regulatory violations stem from design choices that make refusal harder than acceptance, such as pre-ticked boxes, concealed reject options, or emphasis on Accept.
  • Testing consent flows with keyboard and mobile accessibility checks is essential to ensure compliance, usability, and trustworthiness before deployment.

Table of Contents

Most cookie banners fail for the same reason: someone bolted on a plugin, ticked a box marked “GDPR done”, and moved on. The banners that actually work share a few deliberate design decisions, and looking at how each one solves a specific problem is more useful than any generic checklist.

GOV.UK’s push-down banner. Rather than floating over content, the GOV.UK pattern pushes the page down when it appears, sitting near the top of the body rather than fixed to the viewport. It avoids position:fixed specifically so it never obscures a keyboard focus target, which is exactly what WCAG 2.2’s focus-not-obscured criterion demands. The copy is a single short sentence, followed by two buttons of identical size and styling: “Accept analytics cookies” and “Reject analytics cookies”. No visual hierarchy favours one choice. This works because compliance and usability point in the same direction: a banner that cannot hide anything important is also a banner that never frustrates a keyboard user.

The unobtrusive bottom bar. A thin bar anchored to the bottom of the screen, a height suitable for comfortable thumb interaction on mobile, with a one-line explanation and two text-link-style buttons. Nielsen Norman Group’s research on cookie permissions found that smaller, non-blocking bars that push content rather than cover it score better on perceived intrusiveness than modal overlays. The trade-off is that a bar this minimal can under-communicate what “necessary” versus “non-essential” actually means, so the one line of copy has to work hard. The best versions link straight to a full cookie policy for anyone who wants detail, rather than trying to cram categories into the bar itself.

The branded pop-in with equal buttons. Some sites want the banner to read as part of their identity rather than a bolted-on legal notice. Done well, this means a small, centred or corner-anchored card using the site’s own typography and colour palette, with “Accept all” and “Reject non-essential” rendered in the same button style, same size, same contrast ratio. The temptation here is to make Accept a bold primary-colour button and Reject a grey ghost link. That single styling choice is the most common compliance failure on the web, because it nudges the decision rather than presenting it neutrally. A well-designed branded banner resists that temptation entirely.

The floating persistent tab. Once initial consent is captured, a small tab or icon (often a cookie icon or a small gear) stays fixed in a corner, giving visitors a permanent route back to their preferences. This is not optional decoration. Anyone who accepted cookies in January and changes their mind in March needs a way to withdraw consent without hunting through a privacy policy for a mailto link. GOV.UK’s guidance and the UK’s PECR-based rules both treat an always-accessible withdrawal path as a requirement, not a nice-to-have.

What ties all four together is restraint. None of them try to explain every cookie category in the first view. They state the essential point in plain language, offer a genuinely equal choice, and leave detail for a second layer. That two-layer structure, quick decision up front and full control on demand, is the single pattern worth copying regardless of which format you choose.

What banner format suits your site?

Four formats cover almost every legitimate use case, and each carries its own accessibility risk if built carelessly.

  1. Push-down bar. Sits at the top of the page and shifts content downward rather than covering it. Pros: never obscures focus, reads well on both desktop and mobile, low development cost. Cons: can feel like an afterthought if copy is too long; on mobile, a tall push-down bar eats valuable above-the-fold space. Accessibility risk: minimal if built without fixed positioning, but test that the shift doesn’t cause a layout jump that disorients screen magnifier users.

  2. Fixed header or footer bar. Anchored permanently to the top or bottom of the viewport using position:fixed. Pros: always visible, simple to implement. Cons: this is the format most likely to breach WCAG 2.2’s focus-not-obscured rule, because a fixed bar can sit directly over an element a keyboard user has just tabbed to. Mobile risk is worse still, since a fixed footer bar competes with the browser’s own address bar for limited screen space.

  3. Modal overlay. A dialogue box that dims and blocks the rest of the page until a choice is made. Pros: impossible to miss, forces a decision before any tracking script runs. Cons: NN/g’s research on cookie permissions links blocking modals to higher perceived intrusiveness than push-down bars. Accessibility risk is significant unless focus is trapped correctly inside the dialogue and returned to the triggering element on close; a modal without proper role="dialog" and focus management is one of the most common screen-reader failures in cookie tooling.

  4. Floating tab or corner widget. Used for the persistent “manage preferences” control rather than the first-visit prompt. Pros: unobtrusive, always available. Cons: easy to make too small to tap reliably on mobile, and easy to forget to label for assistive technology. Accessibility risk: a tab rendered as an icon with no text alternative is invisible to a screen reader.

For most sites, a push-down bar for first contact and a floating tab for ongoing control covers both compliance and usability without needing a modal at all.

Every compliant banner, regardless of format, needs the same core components. Skipping any one of these is the fastest way to fail both a regulator’s checklist and a usability test.

  • A concise purpose sentence explaining, in plain language, what the site does with non-essential cookies and why.
  • Accept and Reject actions visible on first view, styled with identical prominence: same size, same contrast, same position weight.
  • A Manage preferences link or button that opens granular category controls, not a single all-or-nothing toggle.
  • A visible link to the full cookie policy for detail beyond the summary.
  • Clear rules for what happens after a choice: how long the preference cookie lasts, and how a visitor can change it later.

The GOV.UK component guidance offers a useful implementation detail here: place the banner element early in the document body, so screen reader users encounter it before other page content rather than buried after navigation menus. It also recommends showing a brief confirmation message once a choice is made, using an aria-live region or role="alert" so assistive technology announces the confirmation without requiring the user to hunt for visual feedback.

On the accessibility markup itself, the banner region should carry an aria-label (something like “Cookie consent banner”) so it is identifiable in a screen reader’s landmark list. Focus should move logically: when the banner first appears, focus should not be silently trapped or lost, and once dismissed, focus should return sensibly to wherever the user was on the page. This is also where GOV.UK’s decision to avoid position:fixed earns its keep. A fixed element that sits on top of the page risks obscuring whatever the user just tabbed to, which is precisely what WCAG 2.2’s focus-not-obscured criterion exists to prevent.

Copy matters more than most teams assume. Guidance from LogRocket’s cookie UX write-up makes a simple point worth repeating: vague labels like “More options” instead of a direct “Reject” button erode trust and often breach the spirit of equal choice even when the underlying logic is compliant. Say what the button does. “Accept all cookies” and “Reject non-essential cookies” beat “OK” and “Settings” every time.

Non-essential cookies, anything beyond strictly necessary session or security cookies, must stay blocked until a visitor actively opts in. The UK’s PECR-based rules are explicit that granular category controls are required rather than a blunt yes/no switch, and that the banner has to appear before any non-essential cookie is set, not as an afterthought once the page has already loaded its trackers.

Pro Tip: Test your banner with developer tools to confirm no non-essential cookies or tracking scripts run before user consent is given, to ensure proper consent gating.

If you are rebuilding a site’s front end anyway, it is worth reading through what makes a website convert better, since banner placement decisions and page layout decisions tend to collide on the same real estate above the fold.

Does your banner pass keyboard and mobile checks?

A cookie banner that looks fine on a desktop monitor with a mouse can be genuinely unusable for a keyboard-only visitor or someone navigating with a screen reader, and the failures are rarely obvious until you test properly.

WCAG 2.2’s focus-not-obscured requirement is the one most cookie banners fail without realising it. The rule states that when an element receives keyboard focus, it must not be entirely hidden by another element, such as a sticky banner sitting on top of it. Tab order matters just as much: a visitor pressing Tab from the page’s start should reach the banner’s buttons in a logical sequence, not have focus jump unpredictably past or around the consent controls.

Mobile brings its own set of rules. Buttons need to sit comfortably within thumb reach, which in practice means a minimum touch target of around 44 by 44 pixels with clear spacing between Accept and Reject so a slightly inaccurate tap doesn’t select the wrong option. Text needs to be legible without zooming, typically 16 pixels or larger for body copy. Category toggles inside a preferences panel should never rely on colour alone to signal on or off. NN/g’s cookie permissions research specifically flags that non-blocking layouts which push content down, rather than covering it, perform better on mobile because they don’t fight the browser’s own address bar for space.

Three simple tests catch most problems before launch:

  • A keyboard-only walkthrough: unplug the mouse, tab through the banner, and confirm every action is reachable and clearly focused.
  • A quick spot check with NVDA or VoiceOver to hear whether the banner announces itself, its purpose, and its buttons sensibly.
  • A real-device mobile trial, not just a browser’s responsive mode, since actual touch behaviour and viewport quirks differ from a resized desktop window.

Statistic Callout: Large-sample experiments on consent banner design have found that layout and button wording can materially change how people respond, which is exactly why an accessible, neutral design matters as much as a legally correct one. A banner that technically offers a Reject option but hides it behind three taps and a scroll is not equal in practice, whatever the code says.

Getting a cookie banner from design file to live site involves more moving parts than most teams expect, and skipping any one step tends to surface as a compliance gap months later.

  1. Detect visitor jurisdiction if relevant. Not every market needs the same consent flow, so confirm which ruleset applies to the audience your banner is actually serving.
  2. Hold all non-essential cookies until consent is given. Tags for analytics, advertising, and social embeds must not fire before a category is accepted, which usually means gating at the tag manager or data-layer level.
  3. Build the equal-action interface. Accept and Reject buttons should be coded with identical semantic weight, not one as a styled button and the other as a plain link.
  4. Set the preference cookie with a defined expiry. Decide how long a consent choice persists (commonly around 6 to 12 months) and store the category selections, not just a single yes/no flag.
  5. Provide a reopening mechanism. A footer link or floating tab must let visitors reach their preferences again at any point, not only on their first visit.
  6. Document every cookie in the policy. Each cookie name, purpose, category, and retention period should be listed somewhere a visitor can actually find it.

Before going live, run through a short QA pass: confirm consent choices persist across page loads and browser sessions, verify in the network tab that blocked tags genuinely stay silent until consent is given, check the banner on at least two real mobile devices, and run a full cookie audit against what the policy claims. Keep a log of consent choices, timestamp, categories selected, and banner version, since this record is what you would need to produce if a regulator or a client ever asked for evidence of compliance.

For tag manager integration, the safest pattern blocks tag initialisation at the data-layer level until the relevant consent category is confirmed, and server-side gating gives stronger assurance that a third-party script genuinely cannot run early. This matters more than it sounds: a client-side-only block can still leak requests in edge cases like ad blockers interacting unpredictably with consent scripts, whereas gating before the tag manager even loads the script removes that risk entirely.

Pro Tip: Keep a dated screenshot or exported config of every banner version you ship. If a regulator or a client audit ever asks why consent was recorded a particular way in March, you want the exact banner that visitor saw, not your current one.

If your current site build makes any of this awkward to implement, that’s usually a sign the underlying template needs attention rather than the banner itself. Fylde Digital’s guide to improving website UX covers the kind of structural fixes that make consent tooling easier to bolt on properly.

Which dark patterns trigger regulatory complaints?

Four design choices show up again and again in enforcement cases, and all four are avoidable with fairly small changes.

  • Pre-ticked boxes. Presenting non-essential categories as already switched on assumes consent that was never actually given.
  • An unequal path to decline. Accept all sits as one click; Reject requires opening a settings panel, unticking several boxes, then confirming. This is precisely the asymmetry regulators are targeting.
  • Visual emphasis reserved for Accept. A bold, brightly coloured Accept button next to a grey, low-contrast Reject link nudges the decision through design rather than genuine choice.
  • Burying reject behind settings. No visible Reject action on first view at all, only “Manage preferences”, forcing an extra step that Accept never requires.

The EDPB’s cookie banner taskforce report collates enforcement examples from data protection authorities across the EU, and the throughline in nearly every case is the same complaint: refusal was made harder than acceptance.

Refusing consent must be as easy as giving it. Where a cookie banner makes the path to reject convoyed, hidden, or buried behind extra clicks compared with a single-click accept, that asymmetry itself is treated as evidence the design does not genuinely offer free choice.

Fixing any of these is rarely a rebuild. Give Reject the same button styling as Accept. Move it to the first view instead of a nested panel. Default every non-essential toggle to off rather than on. None of these changes cost meaningful development time, and all four close the exact gap regulators keep flagging.

Testing a cookie banner is legitimate. Testing it to manipulate outcomes is not, and the line between the two is narrower than it looks.

Track opt-in rates broken down by cookie category rather than a single blended consent number, since analytics consent and advertising consent often behave very differently. Watch bounce rate immediately after the banner appears, since a badly timed or oversized banner can push visitors away before they’ve seen anything else. Track downstream revenue impact where you can measure it, and keep an eye on long-term consent withdrawal rates, since a banner that captures high initial acceptance but sees heavy withdrawal a month later usually means the initial choice wasn’t well understood.

Ethical A/B testing keeps everything except one variable fixed. Test wording changes against wording changes, not wording against layout. Keep button size, colour, and position identical between variants unless position itself is the thing being tested. The Usenix study on consent banner design found that even small layout shifts can produce statistically significant swings in outcomes, which cuts both ways: it is a legitimate reason to test carefully, and a reason to be cautious about reading too much into a single experiment result.

  • Keep parity between test variants: same categories offered, same number of clicks to each outcome, only the element under test changes.
  • Interpret results with regulatory caution. A variant that boosts Accept clicks by making Reject marginally harder to find is not a win; it is a compliance risk with a positive-looking dashboard.
  • Log every experiment: which variant a visitor saw, what they chose, and when, so the test itself is defensible if a regulator ever asks why consent rates shifted during a given period.

If your testing programme touches broader site conversion work, Fylde Digital’s step-by-step UX guide is a useful companion, since consent experiments sit inside the same measurement discipline as any other conversion test.

Copy templates and layout sketches to adapt

Three short templates cover most legitimate use cases, and each can be adapted to a brand’s tone without losing compliance.

Minimal template. “We use cookies to run this site and, with your permission, to understand how it’s used.” Buttons: Accept all / Reject non-essential. A third link reads Manage preferences, pointing to a settings panel; a separate link reads Cookie policy, pointing to the full policy page.

Explanatory template. “This site uses necessary cookies to function, plus optional analytics and marketing cookies to help us improve it and show relevant content. You choose which optional categories to allow.” Buttons: Accept all cookies / Reject optional cookies, with Manage preferences opening category toggles for Analytics, Marketing, and Functional cookies individually.

Branded template. “[Brand name] uses cookies to keep things running smoothly and, if you’re happy, to learn what’s working well on our site.” Buttons styled in-brand but identical in weight: Accept all / Reject non-essential. A small Cookie settings link sits beside the main buttons rather than hidden below them.

For layout, a bottom bar works best kept to two lines of copy and a single row of buttons, avoiding a scroll requirement even on smaller phone screens. A pop-in should be centred rather than corner-anchored on mobile, since corner placement risks colliding with browser chrome. A floating tab needs a visible text label alongside any icon, since an icon-only tab is easy for a screen reader to skip entirely.

Layout Accessibility strength Main accessibility caveat
Push-down bar Never obscures keyboard focus; simple tab order Long copy can push page content too far down on small screens
Modal overlay Forces a decision before any tracking runs Requires correct focus trapping or screen readers lose their place entirely
Floating tab Always reachable for changing preferences later Icon-only versions are invisible without a text label

None of these layouts is inherently more compliant than another. What decides it is whether the implementation respects WCAG 2.2’s focus-not-obscured guidance and gives Reject the same weight as Accept, regardless of which shape the banner takes.

The industry treats cookie banners as a legal chore bolted onto a finished site, and that’s precisely why so many of them look and behave the way they do: last-minute, ugly, and adversarial towards the visitor. The better framing is that a cookie banner is the first genuine UX decision a visitor encounters on your site, before they’ve read a word of your actual content.

What’s underestimated is how much a badly designed banner damages trust before a visitor even reaches your homepage proper. A banner with a huge green Accept button and a grey, buried Reject link tells a visitor exactly how much you value their choice, and it isn’t much. That impression carries forward into how they read everything else on the page.

The gap between what most compliance tools promise and what actually holds up under scrutiny is real. A plugin that ticks the legal boxes on paper but fails a basic keyboard walkthrough is not compliant in any meaningful sense, whatever its marketing copy claims. Design and compliance aren’t two separate workstreams here; they’re the same job, done properly or not.

— tibor

How Fylde Digital builds compliant, on-brand banners

Getting a cookie banner right without wrecking your site’s look or your page speed usually means treating it as part of the build, not a plugin dropped in afterwards. Fylde Digital handles this as part of full web design work for small and medium-sized businesses, alongside accessibility fixes and tag management setup that make sure non-essential cookies stay blocked until a visitor genuinely opts in.

Fyldedigital

Unlike a generic plugin bolted onto an existing template, a custom-built banner can match your brand’s colours and tone while still giving Accept and Reject equal visual weight, exactly the balance regulators and usability research both point towards. If your current site was built years ago on a platform that makes any of this fiddly, that’s usually the real problem worth fixing first. Fylde Digital offers a free website review that checks your current cookie setup, accessibility gaps, and overall site health in one pass. Request your free review and find out exactly where your consent flow stands.

Where to check the rules yourself

Four sources are worth bookmarking if you’re building or auditing a cookie banner yourself.

  • The GOV.UK cookie banner component is the best reference for implementation details: exact HTML structure, ARIA labelling, and placement within the page.
  • The EDPB’s cookie banner taskforce report explains regulatory reasoning and collects real enforcement examples across EU data protection authorities.
  • WCAG 2.2’s understanding document sets out the exact accessibility rule around focus visibility that most fixed banners get wrong.
  • NN/g’s cookie permissions research covers the usability findings behind why smaller, non-blocking layouts consistently outperform intrusive modals.

Between the four, you have the legal requirement, the regulator’s own reasoning, the accessibility standard, and the usability evidence, which is everything needed to build a banner that holds up on every front at once.

Sources

Some More Cool Projects