Cookie banners that lock no one out

Why the banner matters so much

The banner sits in front of everything else. If it cannot be dismissed, the whole site is blocked. Common causes: the “buttons” are not real buttons, focus lands behind the banner where no one can see it, or the banner covers all content when text is enlarged.

Whether your banner meets data protection rules is a separate question; regulators often expect refusing to be as easy as accepting. Please check that with your privacy adviser. From an accessibility point of view the advice points the same way: two equal, clearly visible buttons help everyone.

Real buttons, not clickable boxes

Every action needs an element that works with the keyboard (2.1.1 Keyboard) and exposes its role and name to assistive technology (4.1.2 Name, Role, Value). A <button> does both out of the box.

<div class="btn" onclick="accept()">
  OK
</div>

<button type="button" id="cc-accept">
  Accept all
</button>
<button type="button" id="cc-reject">
  Necessary only
</button>

The button can be focused, reacts to Enter and Space and is announced as a button. Its label says what happens.

Mark it up as a named dialog

If the banner behaves like a dialog, mark it up as one: role="dialog" with a name via aria-labelledby. Add aria-modal="true" only if the rest of the page really is blocked while it is open. Our modal dialog pattern shows the full behaviour.

<div class="cookie-layer">
  <p>We use cookies …</p>
</div>

<div role="dialog" aria-labelledby="cc-h"
     aria-describedby="cc-p">
  <h2 id="cc-h">Cookie settings</h2>
  <p id="cc-p">We use cookies …</p>
</div>

Focus: in, visible and out again

• Reachable: move focus into the dialog when it opens, or place a non-modal banner early in the source so the first Tab reaches it (2.4.3 Focus Order).
• Visible: each button shows a clear focus indicator (2.4.7 Focus Visible).
• Not hidden: a banner fixed to the bottom of the screen must not fully cover the focused element (2.4.11 Focus Not Obscured (Minimum)).
• No trap: focus must never get stuck where it cannot leave (2.1.2 No Keyboard Trap). After a choice, return it somewhere sensible, such as the top of the page.

Readable, even when enlarged

• Text and both buttons have enough contrast (1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast).
• At 200 % text size and 320 px width everything stays readable and usable without horizontal scrolling (1.4.4 Resize Text, 1.4.10 Reflow). A banner that then fills the screen must scroll itself.
• The banner uses the page language, or its language is marked up (3.1.2 Language of Parts).
• Keep the text short and let the buttons say what they do.

Let people change their mind

People need a way back: a “Cookie settings” link in the same place on every page, for example in the footer (3.2.3 Consistent Navigation). A small floating icon without a name will not do; if you use one, give it an accessible name (4.1.2 Name, Role, Value) and a target of at least 24 by 24 CSS pixels (2.5.8 Target Size (Minimum)).

Checklist

Related WCAG criteria

• 2.1.1 Keyboard
• 2.1.2 No Keyboard Trap
• 2.4.3 Focus Order
• 2.4.7 Focus Visible
• 2.4.11 Focus Not Obscured (Minimum)
• 4.1.2 Name, Role, Value
• 1.4.3 Contrast (Minimum)
• 1.4.10 Reflow

Tools and patterns for this

• Modal dialogFocus moves in on open, Escape closes, focus returns.
• Keyboard testSee and practise focus
• Contrast checkerWith the nearest passing shade
• Getting there without a mouseMany people use the web without a mouse: with a keyboard, switches, voice control or a screen reader. Here is what has to work for them and how to manage focus properly in modern web apps.

Frequently asked questions

Sources

• W3C: WCAG 2.2
• W3C ARIA Authoring Practices: Dialog (Modal) Pattern
• W3C: Understanding 2.4.11 Focus Not Obscured (Minimum)