Your visitors already told their browser how they want to see things

Someone with a vestibular disorder has turned on "reduce motion." Someone with low vision runs Windows in High Contrast Mode. Someone else bumped their browser text size up 40 percent. These aren't edge cases you have to guess at. The browser exposes every one of them to CSS, and most cookie banners ignore all of them, animating in, hard-coding their own colours, and clipping text the moment it grows. Honouring these signals is some of the cheapest accessibility work you'll ever do, because the user already did the hard part.

This guide covers four signals worth respecting. For the broader ruleset, start with Cookie Banner Accessibility.

Motion: honour prefers-reduced-motion

A banner that slides, bounces, or fades in looks polished until it reaches someone for whom motion triggers nausea or dizziness. The prefers-reduced-motion media query tells you when a visitor has asked their system to cut animation, and WCAG's Animation from Interactions criterion is satisfied by respecting it. The fix is a few lines: when reduced motion is requested, drop the transition and just show the banner.

The banner should still appear promptly either way. An animation that delays the reject button by 400 milliseconds is a small dark pattern of its own, and it also drags on interaction latency (see Core Web Vitals).

Forced colours: don't fight High Contrast Mode

When a user turns on Windows High Contrast Mode (or a similar forced-colours setting), the browser overrides page colours with a small palette the user chose. The forced-colors: active media query tells you it's on. The instinct to reassert your brand colours with !important is exactly wrong here. Work with the mode instead:

Keep borders. Forced colours strips background colours, so a filled button with no border can vanish into the page. Give buttons and the banner a border so they stay distinct when the fill disappears.
Don't carry meaning in a background image or gradient. If a coloured background is the only thing marking your primary action, that signal is gone in forced-colours mode. Back it with text and a shape.
Use system colour keywords where you adapt. CSS system colours like ButtonText and Canvas map to the user's chosen palette, so your banner reads as part of their environment rather than fighting it.

/* Respect reduced motion */
@media (prefers-reduced-motion: reduce) {
  .cb-banner { animation: none; transition: none; }
}

/* Survive forced-colours / High Contrast Mode */
@media (forced-colors: active) {
  .cb-banner,
  .cb-banner button {
    border: 1px solid ButtonText;   /* keeps the shape visible */
  }
}

/* Adapt contrast for dark mode */
@media (prefers-color-scheme: dark) {
  .cb-banner { background: #14181f; color: #e8ebef; }
}

Dark mode: the contrast that passes in light and fails in dark

A banner tuned for a white background can quietly fail on a dark one. Grey helper text at 4.6:1 on white might drop to 2.8:1 on your dark surface, under the 4.5:1 WCAG asks for normal text. The prefers-color-scheme query lets you ship a dark palette, but shipping it isn't the same as checking it. Re-measure contrast in both themes: body text and links at 4.5:1, large text and UI component borders and focus indicators at 3:1. The button that reads clearly in light mode is the one most likely to disappear in dark mode, so test the reject control specifically.

Text spacing and zoom: leave room to breathe

Some readers override spacing to make text legible. WCAG's Text Spacing criterion sets the bar your layout has to survive: line height at least 1.5 times the font size, spacing after paragraphs at least 2 times, letter spacing 0.12 times, word spacing 0.16 times, all applied with no loss of content. A banner with text crammed into a fixed-height bar will clip when those values go up. The same fragility shows at 200 percent zoom and in the 400 percent reflow case. Build the banner so its height follows its content, and none of this bites.

Don't Gate Consent Behind an Animation or a Hover

Two patterns lock out the people this guide is about. First, don't make the reject button unavailable until an entrance animation finishes, a reduced-motion or slow-device user is left waiting or clicking into nothing. Second, don't hide the "manage preferences" control behind a hover state, hover doesn't exist for touch, keyboard, or many assistive setups. Every consent action should be present and operable the instant the banner is in the DOM.

System accessibility checklist for banners

Disable entrance animation under prefers-reduced-motion
Show the banner immediately instead of sliding or fading it in.
Keep borders on the banner and its buttons
Filled shapes vanish in forced-colours mode without a border.
Don't carry meaning in background colour or images alone
Back the primary action with text and a shape too.
Ship and re-measure a dark palette with prefers-color-scheme
4.5:1 for text, 3:1 for borders and focus, checked in both themes.
Let banner height follow content, not a fixed value
Survives text-spacing overrides, 200% zoom, and 400% reflow.
Never gate a consent action behind an animation or hover
Accept, reject, and preferences must work the moment the banner loads.

Where CookieBeam Fits

CookieBeam banners are fully configurable, so you can set colours and sizes that meet the contrast and target thresholds in both light and dark rather than accept a fixed template. The layout sizes to its content, so text-spacing overrides and zoom don't clip your copy, and consent actions are present in the DOM without depending on hover or an animation to finish.

Related guides

Read alongside Cookie Banner Accessibility and The European Accessibility Act and Your Cookie Banner. For the standards, see the W3C on Animation from Interactions and Text Spacing, and MDN on the forced-colors media feature.