Best practices

Accessible cookie banner: GDPR consent must be refuseable

An inaccessible cookie banner is not just an accessibility flaw: it violates the GDPR by making consent impossible for all. Between the European Accessibility Act and written consent obligations, your banner must work with keyboard navigation, zoom, and minimum contrast. Discover how to assess it in a few minutes and the seven key points.

The short answer

An inaccessible cookie banner creates a dual non-compliance: GDPR invalidates any consent that the user cannot express (impossible to refuse via keyboard, insufficient contrast, button without a label), and the EAA requires accessibility for all interface elements. The seven minimum checks: visible focus on opening, full keyboard navigation, 4.5:1 contrast ratios, accessible names on buttons, refusal as easy as acceptance, no focus traps, readability at 200 percent zoom.

Why an inaccessible cookie banner breaks GDPR

The GDPR requires explicit and free consent. However, consent is only free if refusal is as easy as acceptance, and it is only accessible if everyone can express it: keyboard, screen reader, visual impairment, motor tremors. If the 'Refuse' button is missing from the keyboard flow, hidden under 50 pixels of clickable content, named with an empty label (empty or missing aria-label) or with a 2:1 contrast on a white background, users with disabilities cannot technically refuse it: the consent your site collects is therefore not legally valid.

Since its 2021 guidelines, confirmed in 2023, the CNIL considers that any obstacle to expressing a choice (consent or refusal) makes that choice non-compliant. Accessibility is no longer optional: it is a technical prerequisite of the GDPR itself.

The additional compliance layer: the European Accessibility Act

The EAA, which comes into force on 28 June 2025, requires all websites and web applications in Europe to be accessible in accordance with WCAG 2.1 Level AA. This also covers cookie banners, which are the first elements rendered on the page: this is therefore the first EAA compliance that your site displays to the visitor. If this first layer fails, the CNIL and accessibility authorities will have an immediate signal of negligence.

The combination is relentless: an inaccessible banner creates a dual non-compliance burden on two fronts (GDPR and EAA). The defects identified first (contrast, keyboard navigation, labelling) will be reported both as consent violations and as EAA violations.

The seven points to check on your cookie banner

1. Visible focus on opening

When the banner appears, keyboard focus must be present and visible on an element of the banner (most often the first button or a close button). Too many sites display the banner but leave the focus on the background: the keyboard user does not know where to act.

2. Complete keyboard navigation

Tabulation (Tab) must go through all the banner’s buttons in a logical order (left to right, or top to bottom), and Enter must activate the button in focus. Input fields and internal links in the banner must also be accessible. Enter (or Space on buttons) must work.

3. Sufficient colour contrast

Text on background: minimum 4.5:1 for normal text, 3:1 for large text (18pt and bold). Borders and graphic elements: 3:1. A white banner with light grey text often fails this test. Semi-transparent buttons on a white background also fail.

4. Clearly named buttons

Each button must have a visible label AND an accessible name (aria-label attribute if the label is an icon, or the visible text of the button). A button with just an ‘X’ icon to close must have aria-label="Close" or an equivalent alternative. Screen readers must read ‘Accept all cookies’, not ‘Button’.

5. Refusal as accessible as acceptance

GDPR requires it. The ‘Refuse’ button must not be in a smaller font, behind an indirect link, or hidden behind a precision click. If ‘Accept’ is keyboard-accessible, ‘Refuse’ must also be, and clearly visible. No difference in weight or colour should create a false hierarchy.

6. No focus traps

Focus trap: when you press Tab at the end of the banner, the focus must not loop back to the beginning indefinitely, nor lock you out of the banner while it is still visible. The focus must be able to exit after taking an action (accept, refuse, close).

7. Readability at 200 per cent zoom

At 200 per cent zoom in the browser, the banner’s text must remain readable and the buttons accessible to the pointer. No invisible overflow, no text overlapping. A visually impaired user who zooms must not lose the ability to refuse.

How to test your banner in one minute

With the keyboard: open your website, close the mouse. Press Tab: the focus should appear on the banner. Continue tabbing, navigate through the buttons, press Enter. Try to refuse, then accept. If you cannot reach 'Refuse' with the keyboard, your banner fails.

For contrast: take a screenshot of the banner, paste it into an online contrast tool (WebAIM Contrast Checker, Accessible Colors), check that the text and buttons reach a minimum of 4.5:1. If the result is red, correct it.

With zoom: press Ctrl++ three times (200 per cent zoom). The banner must remain complete, readable, and all buttons must be clickable without horizontal scrolling.

With a screen reader: if you use a browser with NVDA (Windows, free) or VoiceOver (Mac), activate it and listen to what it reads. Buttons must be explicitly named ('Accept all cookies' and not 'Button'). Sections must have a logical structure.

Going beyond compliance: manual testing and governance

These seven points cover automatable issues (contrast, labelling, keyboard navigation, focus). However, full accessibility of the banner also requires manual testing: a developer or auditor must verify that the focus logic meets expectations (no hidden traps), that customisation fields (if present) are keyboard-navigable, and that the banner does not hide other critical elements when displayed.

Also consider governance: most CMPs (consent management platforms on the market) have accessibility flaws by default. Before choosing one, check its documentation on the EAA and GDPR, test its banner in pre-production using the seven points above, and if possible, request corrections before going live. Inclaria allows you to scan your site in seconds; the cookie banner is often the first element in an accessibility audit, classified as blocking because it conditions access to everything else.

Update: test the banner every three to six months. Any change in CMP, browser update, or design modification can create new non-compliance issues.

Key points to remember

• An inaccessible cookie banner invalidates GDPR consent and violates the EAA.
• The seven minimum checks cover focus, keyboard, contrast, names, equal acceptance/refusal, traps, and zoom.
• Manual testing complements automated testing: actual keyboard navigability, focus logic, and CMP governance consistency.
• A compliant banner is the first signal of overall site compliance.