Cookie banner accessibility testing: A practical checklist

A cookie banner is the front door of your website: If keyboard or screen reader users cannot interact with it, the entire site remains blocked. Under the European Accessibility Act (EAA) and statutory regulations like Germany's BFSG, an inaccessible consent dialog is an immediate barrier for the whole online experience.

To test cookie banner accessibility, go through each choice the banner offers. Open the settings, reject optional cookies and check where keyboard focus goes afterwards. Repeat the journey after accepting cookies.

A banner can work on arrival and fail when someone opens its settings. In the example below, the settings dialog has no title. A scan before opening it misses the error.

Cookie banner accessibility testing: Where to start

Start with a fresh browser profile that has no saved consent. Record the page, browser, viewport size and version of your consent tool. If you clear cookies instead, check whether the tool also stores its state in local storage.

A consent management platform, or CMP, saves cookie choices and displays the buttons and settings for making them. Test it with your own text and theme, inside your website.

List the paths visitors can take. Include the initial choice, settings and changing the choice later. Test rejection and acceptance from separate fresh starting points. A saved decision can otherwise change what happens in the next attempt.

For the wider testing plan, our guide to testing an accessible website explains how automated and manual checks fit together.

Does the banner block the page?

A modal dialog prevents interaction with the page behind it. A non-modal banner leaves the rest of the page available.

The W3C modal dialog pattern describes moving focus into the dialog, keeping Tab navigation inside and closing it with Escape. Focus normally returns to the control that opened it. An automatically displayed banner has no such trigger, so it needs a sensible place for the user to continue.

A non-modal banner should not confine focus. Check whether it completely covers a focused link instead. WCAG 2.4.11 addresses this problem. Partial overlap is permitted by that criterion, though keeping the whole control visible is more usable.

Walk through the journey without a mouse

Every offered choice should be reachable and usable with a keyboard. WCAG 2.1.1 requires keyboard operation.

1. Reload the page. Press Tab and record where focus begins. With a modal banner, focus should not continue through the blocked background page.

2. Move forwards and backwards. Use Tab and Shift+Tab. You should be able to tell which control is focused throughout. A visible focus indicator is covered by WCAG 2.4.7.

3. Reject optional cookies. Activate the appropriate button. Check that you can continue using the page afterwards. Separately record whether the choice was saved.

4. Start fresh and accept cookies. Check that you can continue using the page after accepting.

5. Open settings. Reach each category, change an optional choice and save it. Test expandable sections if your tool provides them.

6. Close settings. Test the visible close button and, for a modal dialog, Escape. Closing should not silently accept optional cookies. Inspect the stored choice separately.

7. Reopen settings later. Find the permanent access point, such as a footer link or a floating badge at the edge of the viewport. If your CMP uses a floating button, verify that it has an accessible name (aria-label="Cookie settings"), does not obscure focused controls behind it (WCAG 2.4.11), and meets minimum target size requirements (WCAG 2.5.8). After closing, check that focus returns sensibly to the trigger.

Repeat the journey with a screen reader. Listen for a useful dialog name and whether category controls communicate their state. WCAG 4.1.2 sets requirements for control names, roles and states. A clean automated result does not establish that the spoken journey is understandable.

These non-interactive teaching examples bring together several common problems. Labels are visible in the illustration; keyboard and focus problems are described below because they appear during interaction.

Bad example: What goes wrong

1. The dialog has no name. A screen reader cannot clearly announce which window has opened. A visible heading must also provide the dialog name.
2. The choices are unclear. “Option 1”, “Option 2” and “Continue” explain neither the cookies nor what the action saves.
3. Keyboard focus is invisible. Pressing Tab gives you no visible indication of the selected control.
4. Focus moves behind the window. The dialog blocks the page, yet Tab reaches obscured background links.
5. Settings cannot be reopened later. After closing the banner, there is no permanent way to change your choices.

The first two problems are visible above. The others appear when you interact with the banner and after closing it.

Good example: Make the choices easier to understand

• A useful dialog name. “Cookie settings” is visible and linked to the dialog so a screen reader can announce it.
• Clear text and actions. Categories explain their purpose. Reject, save and accept are clearly labelled.
• Visible keyboard focus. A marker shows which control you can activate with Enter or Space.
• Appropriate focus behaviour. In a modal dialog, Tab stays inside the window. Escape closes it; focus normally returns to its trigger.
• A way back later. A permanent “Cookie settings” link, perhaps in the footer, reopens the choices.

The focus behaviour follows the W3C modal dialog pattern. A banner that leaves the page usable should allow focus to move outside it. Focused controls should remain visible in both cases.

What was measured in the CookieConsent example

The teaching examples above illustrate more problems than the original measurement. With CookieConsent 3.1.0, the missing dialog name was found after opening settings and cleared after adding the title. A small analytics switch was enlarged and checked again. Escape returned focus to the trigger in both variants.

The naming check is an axe best-practice rule, not a WCAG success criterion. The additional problems in the teaching examples are explanations, not additional measured results.

Record each state so someone else can reproduce it

For every state, write down how you reached it and what you observed. A note that says “banner checked” provides little help when someone has to fix the problem later.

Use these fields for your own results:

• Starting state: Was this a fresh profile or a saved choice?

• Action: Which control did you activate, and with which key?

• Expectation: Which dialog should open, and where should focus move?

• Observation: What happened? Include the browser, viewport and a screenshot.

• Automated finding: Record the rule, selector and tested state. Keep manual observations separate.

• Fix and retest: What changed? Does the same journey work afterwards?

Cover at least the open banner, rejection, acceptance, settings and the page after dismissal. Add nested sections only if your tool actually includes them. Clearly mark checks that you have not performed yet.

Write down what you did and what went wrong. For example: “I open cookie settings with the keyboard. The window has no name for a screen reader to announce.” Add the browser and a screenshot.

Check narrow views and overlapping interfaces

A desktop result applies to the view you tested. Repeat the journey at a narrow viewport and with enlarged content. Long descriptions should not make the choice buttons or close control unreachable.

Also check interactions with other dialogs. If a login opens while the banner is visible, it should remain clear which dialog is active. Record that combination as a separate test case.

Check text contrast against WCAG 1.4.3. Pay attention to small close controls too. WCAG 2.5.8 specifies a 24 × 24 CSS pixel minimum and includes exceptions, including sufficient spacing. The visible icon size alone does not determine the result.

Where an automated audit helps

An automated scan can find missing names, structural errors and contrast problems. Open the banner or settings you want to inspect before scanning. In this example, axe detects the missing dialog title only after settings open.

The Playwright accessibility testing guide shows how to open a control before scanning it. Check focus behaviour manually or write separate tests for it.

The following describes how to prepare your own audit. A navable run on this demo has not been measured.

With navable Audit, you can include interactive states in your testing workflow. Describe rejection, acceptance and settings as separate paths. Check the results to confirm that the audit opened the intended view. Give developers confirmed errors with selectors and reproduction steps. After a change, repeat the same journey.

In the second case, the naming rule reports no error. You still need to check keyboard and screen reader behaviour.

Prepare this path for a Multi-State-Audit.