Cookie banner screen reader and keyboard accessibility in code

A cookie banner works with a screen reader when it is announced as a named dialog the moment it appears, every button and switch says what it does and its state, keyboard focus moves into it and comes back afterwards, and a polite status message confirms the saved choice. This guide shows the HTML attributes, JavaScript patterns and CSS that get a banner there, measured against WCAG 2.1 Level AA, the level the EU's accessibility standard follows, and the WCAG 2.2 criteria worth meeting on top.

Why cookie banner accessibility is a legal question

A cookie consent banner is often the first interactive element on a page. If it cannot be operated by keyboard, parsed by a screen reader or read by someone with low vision, the site is blocked from the first moment.

The overview of the WCAG criteria and the EAA for cookie banners covers the rules. This guide covers the code: the attributes, scripts and styles that meet them.

The EAA covers the products and services it lists, such as e-commerce, banking services, e-books and passenger transport services, and the national laws that transpose it set the penalties. Microenterprises that provide services, those with fewer than 10 staff and an annual turnover or balance sheet of no more than EUR 2 million, are exempt. Germany's transposition, the BFSG, sets fines of up to EUR 100,000 for the more serious breaches in section 37. Presumption of conformity runs through EN 301 549, whose web requirements follow WCAG 2.1 AA.

There is also a GDPR angle. If a visitor with a visual impairment cannot use a cookie banner, the consent it collects is hard to defend under Article 7 GDPR. Consent must be freely given and informed, and an inaccessible banner undermines both.

Keyboard navigation: focus, tab order and Escape

Keyboard operability is the most critical accessibility requirement for a cookie banner. Every interactive element, from buttons and switches to links, must be reachable with Tab and Shift+Tab and work with Enter or Space.

When a banner should hold focus

If the banner blocks the page behind it, typically with an overlay, focus should move into the dialog and stay there until the visitor makes a choice. The native <dialog> element with showModal() does this, makes the rest of the page inert and handles Escape. Without the native element, make the rest of the page inert and cycle focus yourself: query the focusable elements, and on Tab from the last one move to the first (and the reverse for Shift+Tab).

A bar or corner card that leaves the page usable is different. The WAI-ARIA Authoring Practices modal dialog pattern describes a dialog that blocks the content behind it, and marking a non-blocking banner aria-modal="true" can mislead some screen readers about what they can reach. Either make such a banner modal on purpose, with an overlay, or leave the page reachable and make sure the banner never hides the element that has focus (WCAG 2.2's 2.4.11, Focus Not Obscured).

The Escape key should close the banner only if a default consent state exists. If the banner requires an explicit choice, Escape should do nothing.

Focus restoration

After the banner closes, focus must return to the element that had it before the banner appeared. Store a reference to document.activeElement before opening the dialog, then call .focus() on it after closing. Without that, keyboard users are left at the top of the document or, worse, on an element that is no longer visible.

ARIA roles and attributes

A banner that acts as a dialog needs role="dialog" and a name from aria-labelledby pointing at its heading, so screen readers announce what it is on open. Add aria-modal="true" when it blocks the page, and aria-describedby pointing at the explanatory text.

For cookie category switches, role="switch" with aria-checked is clearer than role="checkbox": screen readers announce "Analytics cookies, switch, off" rather than "Analytics cookies, checkbox, not checked."

After a visitor saves preferences, write a confirmation into an aria-live="polite" region. Create that region empty when the page loads, not at the moment you write to it, or some screen readers miss the first message. Write the text a moment after focus moves, so the announcement of the newly focused element does not cut it off.

Cookie banner screen reader accessibility, step by step

A screen reader user should hear a predictable sequence. On load: the dialog role, its name and its description. On a switch: the category name and its new state. On a button: its label. After saving: the polite confirmation, such as "Cookie preferences saved". If any step is silent or reads a bare "button", the banner fails that visitor.

Test this sequence in VoiceOver on macOS and iOS, NVDA on Windows and TalkBack on Android. VoiceOver may not announce the dialog's name unless focus is set to the dialog container or its first child, so move focus deliberately when the banner opens.

Dark mode and colour contrast

WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, controls and focus indicators. These ratios must hold in both light and dark colour schemes.

CSS custom properties approach

Define colour tokens as CSS custom properties on the banner container, then override them inside a prefers-color-scheme: dark media query. This keeps the logic in one place and avoids specificity conflicts with the host page's styles.

Every colour value, from backgrounds and borders to text and button fills, should reference a custom property. Check contrast for every combination: body text on background, button text on button fill, link text on background, and the switch track against its background. Chrome DevTools and the WebAIM Contrast Checker flag failures. In Windows contrast themes (forced-colors: active) fills and shadows disappear, so give every surface a border that uses a system colour such as CanvasText.

The cookie banner design best practices article covers design questions beyond contrast.

Font sizing and zoom support

Use rem units for font sizes, padding and margins within the banner. Pixel values still scale with browser zoom, which is what WCAG 1.4.4 (Resize Text) tests at 200%, but rem also follows a visitor's default font size setting and keeps spacing in proportion for 1.4.12 (Text Spacing).

WCAG 2.1 AA also requires content to reflow without horizontal scrolling at a width of 320 CSS pixels, the equivalent of 400% zoom on a 1280-pixel screen (1.4.10, Reflow). The banner should reflow rather than overflow, scroll internally when the window is short, and clip nothing.

Reduced motion

The prefers-reduced-motion media query detects whether a visitor has asked their operating system to reduce motion. For people with vestibular disorders, slide-in animations and bouncing attention-grabbers can cause nausea, dizziness or disorientation.

Set transition: none and animation: none when prefers-reduced-motion: reduce matches, so the banner appears and disappears without movement. This meets WCAG 2.3.3 (Animation from Interactions), a Level AAA criterion: it is good practice rather than an AA requirement, and it costs a few lines of CSS. For how animations affect banner performance and Core Web Vitals, see the dedicated article.

What WCAG 2.2 adds for banners

WCAG 2.2, published in October 2023, is the current W3C recommendation, and content that meets it also meets 2.1. Two of its new AA criteria matter for banners:

• 2.4.11 Focus Not Obscured (Minimum): a bar fixed to the bottom of the screen must not cover the element that has keyboard focus.
• 2.5.8 Target Size (Minimum): buttons and switches need a target of at least 24 by 24 CSS pixels, or enough spacing around them.

Shadow DOM considerations

Many consent tools render banners inside a Shadow DOM to isolate styles from the host page. This encapsulation prevents CSS conflicts but introduces accessibility complications.

Focus management quirks

A closed shadow root stops outside JavaScript from querying elements inside it, and document.activeElement reports only the host element. Inside the banner's own code, read shadowRoot.activeElement to know what has focus. Setting delegatesFocus: true on the shadow root forwards focus from the host to the first focusable element inside.

Assistive technology support

Screen readers read the shadow tree as part of the accessibility tree, so role="dialog" and aria-labelledby work as expected. The exception is cross-root references: an aria-labelledby pointing at an ID outside the shadow root fails silently. Keep the labelling element inside the same shadow root as the dialog.

Put the prefers-reduced-motion, prefers-color-scheme and forced-colors media queries directly inside the shadow root's stylesheet rather than relying on styles inherited from the document.

Testing checklist

Run through these checks before shipping a cookie banner.

Automated tools catch only part of the problems, so manual testing is the larger share of the work. If dark patterns in cookie banners create legal risk through deceptive design, inaccessible banners create a similar risk through exclusion.

How the Kukie.io banner handles accessibility

The Kukie.io consent banner is designed against WCAG 2.2 Level AA. Every surface is a named and described dialog that you can operate with the keyboard, and focus returns where it was after a choice. A status region created at load announces "Cookie preferences saved". Animations stop under reduced motion, and a border appears in forced-colours mode. While a surface with an overlay is open, the page behind it is made inert.

The colours are yours: the Banner Editor warns about low contrast but keeps what you set, so contrast depends on your choices. Conformance is a property of a whole page, so the banner is one part of your site's result, not a guarantee for it. The banner setup documentation covers installation, and the design customisation guide covers colours, layout and the overlay. More of what Kukie.io does is on the features page.

Questions about accessible cookie banners

Put an accessible banner on your site

If you would rather not build and test all of this yourself, the Kukie.io banner gives you the dialog semantics, keyboard handling and announcements described here, with your own colours and text.

Start free