An accessible cookie banner: keyboard, screen readers and WCAG 2.2

An accessible cookie banner is one that every visitor can understand and operate: with a keyboard alone, with a screen reader, at 200% zoom, on a small phone, with low vision or a tremor. Beyond being the right thing to do, it is part of consent being valid: a visitor who cannot reach the Reject button has not been offered a free choice. Since 28 June 2025 the European Accessibility Act (Directive (EU) 2019/882) applies to a range of online services, and the standard everyone measures against is WCAG 2.2, a W3C Recommendation since 5 October 2023 (the current edition is dated 12 December 2024). Here is the checklist, criterion by criterion.

Structure and semantics

• Use real buttons. Accept all, Reject all and Customize are <button> elements, not styled <div>s. This satisfies 4.1.2 Name, Role, Value (Level A) for free: the role is button, the name is the text, and the state is exposed.
• Give the dialog a name. The banner container has role="dialog" (or alertdialog), aria-labelledby pointing at its heading and aria-describedby pointing at the explanatory text, following the WAI-ARIA Authoring Practices pattern for dialogs.
• Mark the language. The banner text is in the visitor's language, and the container carries a matching lang attribute when it differs from the page, so the screen reader switches voice (3.1.1 and 3.1.2).
• Toggles are switches. In the preferences centre, each category toggle has role="switch" with aria-checked, a visible label, and a description of what the category does. The necessary category is shown as always on and disabled, not hidden.

Keyboard

• Everything reachable. Every control works with Tab, Shift+Tab, Enter and Space (2.1.1 Keyboard, Level A).
• No trap unless modal. A bar or floating box must not trap focus; a visitor can tab past it to the page (2.1.2 No Keyboard Trap, Level A). A centred modal that blocks the page may hold focus inside the dialog, following the modal dialog pattern, and must release it when the dialog closes.
• Logical order. Focus moves heading, text, Customize, Reject all, Accept all (or your chosen order), never jumping around (2.4.3 Focus Order, Level A).
• Visible focus. Each control shows a clear focus ring (2.4.7 Focus Visible, Level AA), and the focused control is not hidden behind the banner itself or another sticky element (2.4.11 Focus Not Obscured (Minimum), Level AA, new in 2.2). This matters when a bottom bar covers a focused link on the page.
• Escape. For a modal, Escape closes it without choosing, which is the same as not consenting yet; the page stays blocked until a choice is made only if you decided the banner is modal.
• No surprise on focus. Focusing a control must not trigger a change of context (3.2.1 On Focus, Level A): a toggle does not save and close when it receives focus.

Visual design

• Contrast. Text on both buttons meets 4.5:1 against its background (1.4.3 Contrast (Minimum), Level AA); button borders, focus rings and switch states meet 3:1 (1.4.11 Non-text Contrast, Level AA). A grey Reject label on a light grey button fails this and also matches the "deceptive button contrast" practice the EDPB taskforce described in 2023.
• Size. Targets are at least 24 by 24 CSS pixels, with spacing between them (2.5.8 Target Size (Minimum), Level AA, new in 2.2). Make them larger on touch screens.
• Zoom and reflow. The banner remains usable at 200% text size (1.4.4 Resize Text, Level AA) and at a 320 CSS pixel wide viewport without horizontal scrolling (1.4.10 Reflow, Level AA). A bottom bar that grows to cover the whole phone screen at 200% is a common failure; let it become a modal or let it scroll.
• Not colour alone. The active state of a switch is shown by position or an icon, not only by colour (1.4.1 Use of Color, Level A).
• Motion. No animation that cannot be paused; respect prefers-reduced-motion for the entrance.

Content

• Plain words, short. The first screen says what the banner is about, what the choices are and where to read more.
• Equal wording. Reject all and Accept all are parallel labels; nothing describes refusing as a loss.
• Links are links. "Cookie policy" and "Privacy policy" are real links with descriptive text.
• No time limit. The banner does not disappear or auto-accept after a delay (2.2.1 Timing Adjustable, Level A).

Reopening the preferences

A visitor who used a screen reader to refuse should be able to find the settings later: a "Cookie settings" link in the footer, reachable by keyboard, that opens the preferences centre. The EDPB taskforce asks for an easily accessible way to withdraw, such as a permanently visible icon or a link in a visible, standardised place.

Testing

1. Unplug the mouse. Tab through the banner and the preferences; operate every control; check the focus ring.
2. Turn on VoiceOver (macOS, iOS), NVDA (Windows) or TalkBack (Android); confirm the dialog is announced with its name, each button with its label, each switch with its state.
3. Zoom to 200% and resize the window to 320 pixels; check nothing is cut off.
4. Run a contrast checker on both buttons and the focus ring.
5. Run an automated checker (axe, Lighthouse) for the obvious errors, then fix the ones only a human finds.

How Cookiequiet handles it

Cookiequiet's banner renders in a shadow root with real buttons, a labelled dialog, keyboard operation, visible focus, switches with states in the preferences centre, Accept all and Reject all at the same size and weight, 24 languages picked from the visitor's browser with every string editable, and three layouts (bar, floating box, centred modal) so you can choose non-modal or modal behaviour. Your brand colours are yours to set; check their contrast with the checker above before shipping.