Why Cookie Banner Accessibility Matters Now
The European Accessibility Act (EAA) came into force on 28 June 2025. For any website offering products or services in the EU with at least 10 employees and two million euro in annual turnover, accessibility is no longer optional. Cookie consent banners fall squarely within its scope.
An inaccessible cookie banner creates a dual legal problem. Under the EAA, it breaches accessibility requirements that carry fines of up to one million euro in serious cases. Under GDPR, consent collected through an unusable interface may not qualify as freely given, specific, informed, and unambiguous - the four conditions set out in Article 4(11). A visually impaired visitor who cannot perceive the reject button has not been given a genuine choice.
WCAG 2.2 Level AA is the standard referenced by the EAA. It builds on earlier versions with new success criteria that directly affect interactive overlays like cookie banners.
WCAG 2.2 Success Criteria That Apply to Cookie Banners
Not every WCAG criterion is equally relevant to a consent banner. The table below highlights the ones that matter most.
| Success Criterion | Level | What It Means for Your Banner |
|---|---|---|
| 1.4.3 Contrast (Minimum) | AA | Text and background must have at least a 4.5:1 contrast ratio |
| 1.4.11 Non-text Contrast | AA | Toggle switches, checkboxes, and button borders need 3:1 contrast against their background |
| 2.1.1 Keyboard | A | Every interactive element must be operable via keyboard alone |
| 2.1.2 No Keyboard Trap | A | Keyboard focus must not get stuck inside the banner |
| 2.4.7 Focus Visible | AA | A visible outline or indicator must appear on the focused element |
| 2.4.11 Focus Not Obscured (Minimum) | AA | The focused element must not be fully hidden by the banner overlay |
| 4.1.2 Name, Role, Value | A | Screen readers must receive correct roles and states for all controls |
Criterion 2.4.11, Focus Not Obscured, is new in WCAG 2.2 and particularly relevant. A modal cookie banner that covers the full viewport can obscure focused elements on the page behind it. If your banner uses a modal pattern, the underlying page content should be marked as inert so assistive technologies do not attempt to interact with hidden elements.
Keyboard Navigation: The Most Common Failure
Keyboard accessibility is the single most frequent issue with cookie banners. If a visitor using a keyboard cannot tab through the banner, reach the reject button, or activate category toggles, your consent mechanism is broken for that user.
Your banner should follow a logical tab order: the first focusable element should be the most prominent action (typically the accept button), followed by the reject button, then any preference or settings link. Each element must respond to Enter or Space key presses exactly as it would to a click.
A common mistake is building cookie category toggles from <div> or <span> elements styled to look like switches. These are invisible to keyboard users unless you add role="switch", tabindex="0", and aria-checked attributes. Native <input type="checkbox"> elements are keyboard-accessible by default and require less custom work.
Screen Reader Compatibility and ARIA Roles
A screen reader user hears your banner read aloud. If the HTML structure is unclear, the experience becomes a wall of unlabelled buttons and mystery toggles.
Mark the banner container with role="dialog" and aria-label="Cookie consent" (or your equivalent). This tells assistive technology that a dialog has appeared and gives it a name. When the banner opens, move focus to it programmatically so screen reader users are not left navigating the hidden page beneath.
Each button needs a clear accessible name. "Accept all cookies" is better than "OK". "Reject non-essential cookies" is better than a bare "X" icon. If your banner design uses icons without visible text, provide aria-label attributes.
Category toggles should announce their state. A toggle for _ga and other analytics cookies should read something like "Analytics cookies, off" or "Analytics cookies, on" depending on the current state. The aria-checked attribute on a role="switch" element handles this automatically.
Colour Contrast and Visual Design
Contrast failures are easy to introduce and easy to fix. WCAG 1.4.3 requires a minimum 4.5:1 contrast ratio between text and its background for normal-sized text, dropping to 3:1 for text 18pt or larger (or 14pt bold).
Light grey text on a white background - a surprisingly popular choice for the "reject" option - typically fails this threshold. Similarly, pastel-coloured toggle switches against a light banner background often fall below the 3:1 non-text contrast requirement of criterion 1.4.11.
Button parity matters for accessibility too. If the "Accept" button is a bright, high-contrast colour and the "Reject" button is a barely visible text link, you have not only a dark pattern concern but also a measurable contrast problem. Both actions should have equal visual weight and meet the same contrast standards.
Focus Indicators: Meeting the New 2.4.11 Standard
WCAG 2.2 introduced criterion 2.4.11 (Focus Not Obscured) at Level AA and the stricter 2.4.13 (Focus Appearance) at Level AAA. For AA compliance, the focused element must not be entirely hidden behind other content. For AAA, the focus indicator itself must meet minimum size and contrast specifications.
In practice, your banner buttons should display a clearly visible outline when focused via keyboard. The focus indicator needs at least a 3:1 contrast ratio between its focused and unfocused states. A 2px solid outline in a contrasting colour around the button is the simplest reliable approach.
Avoid outline: none in your CSS. This single declaration removes the browser's default focus indicator and is the root cause of most focus visibility failures. If you must customise the focus style, replace it with something equally or more visible - never remove it entirely.
Modal Behaviour and Focus Management
Most cookie banners function as modals: they appear on top of the page and expect user interaction before proceeding. Modal behaviour brings specific accessibility requirements.
When the banner opens, focus should move to the dialog. The inert attribute on the rest of the page prevents keyboard users from tabbing into hidden content. When the banner closes after a consent choice, focus should return to the element that was focused before the banner appeared, or to a logical starting point on the page.
Pressing Escape is a convention for closing dialogs. Whether your cookie banner should close on Escape depends on your GDPR consent model. If dismissing the banner without a choice defaults to rejecting non-essential cookies, closing on Escape can work. If dismissal means no consent signal is recorded, you may need to keep the banner open until an explicit choice is made.
Testing Your Banner for Accessibility
Automated tools catch some issues but miss many. A thorough accessibility check combines automated scanning with manual testing.
Start with automated checks. Browser extensions like axe DevTools or the Chrome DevTools Lighthouse audit will flag contrast failures, missing ARIA attributes, and elements without accessible names. These tools typically catch around 30-40% of accessibility issues.
Manual keyboard testing is essential. Unplug your mouse and attempt to complete every action your banner offers using only the keyboard. If any step is impossible without a mouse, the banner fails.
Screen reader testing rounds out the process. Test with VoiceOver on macOS, NVDA on Windows, or TalkBack on Android. Listen for whether button labels make sense, whether toggle states are announced, and whether the banner is identified as a dialog. If your site targets visitors across the EU, also verify that your multilingual banner remains accessible in every language.
Common Accessibility Mistakes in Cookie Banners
These issues appear repeatedly in accessibility audits of consent banners:
- Custom toggle switches built from
<div>elements with no keyboard support or ARIA roles - Reject button styled as a low-contrast text link while Accept is a prominent button
outline: noneapplied globally, removing all focus indicators- Banner does not trap focus, allowing keyboard users to tab into obscured page content
- No
role="dialog"on the banner container, so screen readers do not announce it as a dialog - Close button labelled only with an "X" character and no
aria-label - Tiny tap targets on mobile - buttons smaller than 44 x 44 CSS pixels
Each of these is fixable with standard HTML and ARIA patterns. The effort involved is modest compared to the legal exposure of an inaccessible banner.
EAA Enforcement and Penalties
EU member states set their own penalty structures under the European Accessibility Act. Fines generally range from two thousand to five hundred thousand euro, with a ceiling of one million euro for serious or repeated violations. Market surveillance authorities in each member state are responsible for enforcement.
The EAA applies to businesses with at least 10 employees and an annual turnover or balance sheet total exceeding two million euro. Microenterprises are exempt, though GDPR consent requirements still apply regardless of size.
Accessibility complaints can feed into regulatory reviews of your cookie consent mechanism. A data protection authority investigating a consent complaint may consider whether the banner was genuinely accessible to all users when assessing validity of collected consent.
Frequently Asked Questions
Does the European Accessibility Act apply to cookie banners?
Yes. The EAA, effective from 28 June 2025, applies to websites and e-commerce services covered by its scope. Cookie consent banners are interactive components of those services and must meet WCAG 2.2 Level AA standards.
What WCAG contrast ratio do cookie banner buttons need?
Text on buttons must meet a 4.5:1 contrast ratio against the button background (WCAG 1.4.3). The button itself needs a 3:1 contrast ratio against the surrounding banner background (WCAG 1.4.11 Non-text Contrast).
How do I make cookie consent toggles accessible to keyboard users?
Use native <input type="checkbox"> elements or add role="switch", tabindex="0", and aria-checked attributes to custom elements. Ensure they respond to both Enter and Space key presses.
Should a cookie banner close when the user presses Escape?
It depends on your consent model. If dismissing the banner defaults to rejecting non-essential cookies, Escape can work. If dismissal records no consent signal, the banner should remain open until the user makes an explicit choice.
Can an inaccessible cookie banner invalidate GDPR consent?
Potentially, yes. GDPR Article 4(11) requires consent to be freely given. If a user with a disability cannot perceive or operate the reject button, they have not been given a genuine choice, which may render the collected consent invalid.
What is the minimum fine for EAA non-compliance?
Penalties vary by EU member state but generally range from two thousand to five hundred thousand euro. Serious or repeated violations can attract fines up to one million euro.
Take Control of Your Cookie Compliance
If you are not sure whether your cookie banner meets WCAG 2.2 standards, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie - so your visitors get a clear choice, and you stay on the right side of the law.
