But can a blind user navigate it with a screen reader? Can someone with motor impairments tab through the options without a mouse? Does the contrast ratio hold up for users with low vision?

If you cannot confidently answer yes to all three, your cookie banner has a compliance gap — and as of June 28, 2025, that gap carries legal weight.

Key takeaways:

• The European Accessibility Act (EAA), which came into force on June 28, 2025, makes WCAG 2.2 Level AA the enforceable standard for digital services in the EU — including cookie banners.
• A non-accessible banner can invalidate consent entirely under GDPR, because users who cannot operate the interface cannot meaningfully give or withdraw it.
• Penalties for EAA non-compliance range from €2,000 to €500,000 across EU member states, with Germany imposing fines up to €500,000 per violation.

Why Accessibility Is a Consent Issue, Not Just a UX Issue

Most discussions of cookie banner compliance focus on the privacy law requirements: was consent freely given, specific, informed, and unambiguous? What gets missed is that all four conditions depend on the user actually being able to interact with the banner. A cookie banner alone has the potential to negatively affect the WCAG conformance of an entire web project — and because banners are implemented on every subpage of a website, a single faulty component can harm accessibility and conformance throughout.

This is the crux of the accessibility-consent intersection. If a screen reader user cannot reach the Reject All button because it is not in the DOM's tab order, they have not been given a genuine choice. If color contrast is too low for a user with low vision to read the consent categories, the information has not been meaningfully disclosed. GDPR's requirement for freely given, unambiguous consent cannot be satisfied by a banner that excludes a meaningful share of your audience from operating it.

According to studies by Thales, 70% of consumers say they would immediately stop doing business with a company that uses their data without permission. Users with disabilities represent a substantial and growing portion of that audience. Around one in six people globally live with a disability, and with population aging accelerating, the demand for accessible digital interfaces will only grow.

The legal landscape reinforced this reality decisively in 2025. The European Accessibility Act came into force on June 28, 2025, establishing mandatory accessibility standards for key digital products and services across the EU — including e-commerce, banking, telecoms, transport, and media. Cookie banners, as the first point of user interaction on most websites, fall squarely within scope. Fines for non-compliance with the EAA generally range between €2,000 and €500,000 across the EU, with a maximum fine of €1,000,000 in serious cases.

The WCAG 2.2 Framework Applied to Cookie Banners

WCAG organises its requirements under four principles: Perceivable, Operable, Understandable, and Robust — commonly abbreviated as POUR. Each principle produces concrete, testable requirements when applied to cookie consent interfaces. WCAG 2.2, published in October 2023, expanded on the 2.1 guidelines with particular emphasis on keyboard users, focus visibility, and cognitive accessibility. Level AA is the realistic compliance target and the level referenced by the EAA.

Perceivable means users can see or hear all the information your banner presents. For cookie consent, this primarily means text contrast and visual clarity. WCAG 2.2 requires a minimum 4.5:1 color contrast ratio for text and controls. That applies to button labels, category descriptions, toggle states, and any explanatory text. Using color alone to communicate meaning — for example, a green Accept and red Reject with no text labels — fails WCAG regardless of contrast ratio. Toggles need clear "ON" and "OFF" labels alongside color, making the toggle states easy to understand for everyone.

Operable covers how users interact with the banner. This is where most cookie banners fail. Every element in the cookie banner must work with a keyboard — users should be able to tab through options, make a choice, and close it — because some users rely on a keyboard instead of a mouse. When the banner appears, focus must move to it and trap there until closed. WCAG 2.2 added the "Focus Not Obscured" criterion (success criterion 2.4.11), which means the banner itself must not block the user's ability to see where their keyboard focus is at any moment. To comply with WCAG 2.2 success criterion 2.4.11, cookie banners must not be made "sticky" to the top of the page using position: fixed or any other method, as this risks covering or obscuring content which has focus applied.

Understandable means the language and behaviour of the banner are clear and predictable. Plain English over legal jargon. Button labels that describe the action rather than hide it. "Reject All" is understandable; "I understand" used as a substitute for rejection is not — it reframes refusal as agreement and has been targeted by regulators as a dark pattern. Compliance requires that rejection must demand the same user effort as acceptance, buttons should use neutral colors and typography, and where toggles are used, clear On/Off labels are mandatory — not reliance on color alone. Austria's high court ruled in 2025 that colored "Accept" buttons alongside grey "Reject" links violate GDPR parity requirements.

Robust means your banner works reliably across browsers, devices, and assistive technologies. This is where ARIA — Accessible Rich Internet Applications — markup becomes essential. Screen readers depend on ARIA roles and properties to announce what interactive elements do. A <div> styled to look like a button is not a button to a screen reader unless it carries the correct role="button" attribute, is focusable via tabindex, and responds to both Enter and Space key presses. The banner's role as a dialog should be declared with role="dialog" and an aria-labelledby attribute pointing to the banner's heading. Purpose-selection checkboxes or toggles need associated <label> elements so screen readers can announce what each control represents.

Understanding how cookie consent works in practice makes it easier to see why robust markup matters: every interactive element is a decision point for the user, and if assistive technology cannot interpret it, that decision point is effectively invisible.

Where GDPR, CCPA, and Accessibility Overlap

Privacy regulations and accessibility standards converge on one principle: the user must be able to exercise genuine, informed control. The requirements stack in ways that affect every design and engineering decision.

Under GDPR, setting non-essential cookies before obtaining explicit consent violates prior consent requirements and can result in immediate enforcement action — this includes analytics, marketing, and preference cookies. The implication for accessibility: if a user with a disability cannot operate the banner due to keyboard traps or unannounced interactive elements, they cannot give that prior consent. Any cookies that fire before they navigate successfully are already a GDPR violation.

GDPR requires granular choices — users must be able to accept analytics while rejecting marketing cookies. Bundled "accept all or reject all" choices without category-level control violate the regulation. For accessibility, this means the preference centre — where users make granular choices — must meet the same WCAG standards as the first-layer banner. Accessible first-layer banners paired with inaccessible preference centres are still non-compliant.

The CCPA operates on a different model. Under CCPA, you can set cookies right away, but users must be able to opt out of data sales or sharing — so instead of a "click to accept" banner, most CCPA-compliant banners focus on transparency and control, offering opt-out mechanisms. Accessibility is equally critical here: if the "Do Not Sell or Share My Personal Information" link or opt-out mechanism is only operable with a mouse, California users with motor impairments cannot exercise a right the law expressly guarantees them. Fines under CCPA currently stand at $2,663 per unintentional violation and $7,988 per intentional violation involving minors' data.

Reviewing the full GDPR cookie consent requirements for 2026 alongside the accessibility obligations makes clear that the two frameworks are not competing — they are additive, and both must be satisfied simultaneously.

The Most Common Accessibility Failures in Cookie Banners

Despite increased awareness, specific failure patterns appear repeatedly across real-world implementations. A 2025 audit by WP Accessibility Day found that not a single major WordPress cookie consent solution met the legal requirements for accessibility without remediation — despite most claiming WCAG conformance.

The most damaging failure is keyboard inaccessibility. A banner that can only be dismissed by clicking an "X" icon — rather than pressing Escape or tabbing to and activating a clearly labelled close or reject button — traps keyboard-only users. They cannot dismiss the banner, they cannot continue to the page content, and they cannot exercise any consent choice. This is simultaneously a WCAG failure and a consent validity failure.

Focus management errors are the second most common class of problem. When a banner appears, focus must shift to it automatically. When it closes, focus must return to a logical point in the page — typically the element that triggered the banner or the top of the main content. Banners that appear visually but do not receive programmatic focus are invisible to users navigating by keyboard.

Screen reader invisibility typically results from using non-semantic HTML elements for interactive components. Divs styled as buttons, spans used as toggle controls, and images without alt text all produce elements that are visually functional but inaccessible to assistive technology. Cookie banner accessibility requires keyboard navigation, screen reader compatibility, focus indicators, a 4.5:1 color contrast minimum, and descriptive language.

Auto-dismissal and time limits violate both WCAG (which prohibits time-limited content without a mechanism to extend or pause) and GDPR (which requires affirmative action — a banner that disappears is not affirmative action).

Finally, inaccessible preference centres are common even when first-layer banners pass basic accessibility checks. Complex toggle interfaces, unlabelled checkboxes, and vendor lists without proper list semantics all break at the granular consent layer — which is precisely where the most complex user decisions happen. Reviewingcookie consent best practices can help identify where preference centres commonly introduce gaps that first-layer audits miss.

Building an Accessible Cookie Banner: The Technical Requirements

A WCAG 2.2 Level AA compliant cookie banner has a specific set of technical requirements that go beyond visual design.

The banner should be positioned early in the HTML source order so that keyboard and screen reader users encounter it before page content — but it should not use position: fixed in a way that obscures focus indicators on underlying content. The outer container should carry role="dialog", aria-modal="true", and aria-labelledby pointing to the banner's heading element. This tells screen readers that a modal dialog is present and announces its title when focus enters it.

Every interactive element — Accept All, Reject All, Cookie Settings, and any close button — must be a native <button> element or carry role="button" with explicit tabindex="0". Buttons must respond to both mouse click and keyboard Enter/Space activation. The tab sequence through the banner must be logical and must not escape to the underlying page until the user has made a choice or explicitly dismissed the banner using keyboard navigation.

For the preference centre, each cookie category toggle needs a visible <label> associated via  for/id or aria-labelledby. The current state must be announced by screen readers — meaning aria-checked on toggle controls and aria-expanded on expandable sections. Vendor lists within expanded categories should use proper list semantics (<ul> / <li>) so screen readers can communicate the number of items.

Color contrast at 4.5:1 applies to all text, including placeholder text, button labels, and helper text within the preference centre. WCAG 2.2 also added stronger visibility requirements — keyboard users must clearly see their position on the banner when navigating consent buttons, with more attention to cognitive accessibility through clearer labeling, predictable behavior, and reduced user confusion.

Touch targets on mobile must meet the WCAG 2.2 minimum of 24×24 CSS pixels, though 44×44 is the practical standard for comfortable mobile interaction. Mobile users spend 20% less time reading, and the most effective mobile banners use single-column layouts with vertically stacked buttons, with Reject All appearing above Accept All to remove the suggestion that acceptance is preferred.

Manual Implementation vs. Consent Management Platforms

Organisations that build and maintain cookie banners in-house carry the full burden of keeping pace with evolving requirements — WCAG criteria updates, new regulatory guidance on button parity, EAA enforcement patterns, and changes to GDPR enforcement positions. This is not a one-time build problem; it is an ongoing maintenance obligation.

Manual implementation offers precise control over every element, but the risk surface is significant. A single developer unfamiliar with ARIA semantics can introduce keyboard traps that affect every user on every page of your site. Changes to the visual design — a new brand colour, a UI refresh — can break contrast ratios without anyone noticing until an audit or complaint surfaces.

Quality consent management platforms undergo independent accessibility audits, ensuring consent interfaces meet WCAG 2.1 AA standards. Reputable CMPs maintain compliance as regulations and guidelines evolve, push accessibility updates to all deployers simultaneously, and reduce the burden of individual implementation from each team. The tradeoff is less precise visual control and dependence on a vendor's update cadence. Even among widely-used CMPs, independent testing in early 2025 found that not a single cookie consent solution examined met the legal requirements for website accessibility under laws such as the EAA, ADA, or Section 508 — all had accessibility and WCAG failures despite making broad conformance claims. This means vendor selection requires scrutiny: look for platforms that publish accessibility conformance reports and offer documented ARIA implementation details, rather than relying on marketing claims alone.

For teams that need a practical path to accessible, compliant consent without rebuilding from the ground up, evaluating cookie banner design requirements for 2026 alongside CMP platform capabilities is a logical starting point.

Accessibility Audit Checklist

Before publishing or auditing a cookie banner, work through the following:

Perceivable: Text contrast meets 4.5:1 minimum on all button labels, category descriptions, and helper text. Toggle states are communicated through text labels as well as color. No information is conveyed by color alone.

Operable: Banner receives focus automatically on appearance. All interactive elements are reachable by Tab key in logical order. Focus is trapped within the banner while it is open. Banner does not cover focusable elements on the underlying page. Buttons respond to keyboard Enter and Space. Escape key dismisses or offers to dismiss the banner. Focus returns to a logical element on the page after dismissal.

Understandable: Accept and Reject buttons are labeled with their actual function. Language is plain English at an appropriate reading level. Preference categories are described in terms users understand rather than technical or legal terminology. No auto-dismissal or time limits.

Robust: Banner container uses role="dialog" and aria-labelledby. All buttons are native <button> elements or carry role="button" with tabindex. Toggles carry aria-checked. Expandable sections carry aria-expanded. Vendor lists use list semantics. Banner is tested with at least two screen readers (NVDA+Chrome and VoiceOver+Safari are the standard pair). Banner functions correctly across Chrome, Firefox, Safari, and Edge.

FAQ

What is a WCAG-compliant cookie banner? A WCAG-compliant cookie banner meets the Web Content Accessibility Guidelines at Level AA — meaning it is perceivable, operable, understandable, and robust for users with a wide range of disabilities. In practice this means proper keyboard navigation, screen reader support via ARIA markup, sufficient color contrast, and focus management that keeps keyboard and assistive technology users oriented throughout the consent interaction.

Do I need an accessible cookie banner for GDPR? Yes, indirectly but definitively. GDPR requires that consent be freely given and that withdrawing consent is as easy as giving it. If disabled users cannot navigate the banner to exercise either choice, consent is invalid for them. The EAA, in force since June 2025, makes WCAG 2.2 Level AA the explicit legal standard for EU digital services, adding a direct accessibility obligation on top of the GDPR consent validity argument.

How do I make my cookie banner screen-reader friendly? Use semantic HTML: native <button> elements for all interactive controls, proper <label> associations for checkboxes and toggles, and role="dialog" with aria-labelledby on the banner container. Ensure focus moves to the banner when it appears and is trapped there until the user makes a choice. Test with NVDA on Chrome and VoiceOver on Safari, as these cover the majority of screen reader users.

Are color contrast and keyboard navigation required? Yes, both are required at WCAG 2.2 Level AA. Color contrast must meet at least 4.5:1 for normal text. All interactive elements must be keyboard operable — reachable by Tab, activatable by Enter/Space, and dismissible by Escape. These are not optional enhancements; they are testable success criteria that determine conformance.

Can a consent management platform handle accessibility automatically? Partially. Good CMPs build accessible banner templates and maintain them as guidelines evolve. However, accessibility can break at the integration layer — custom color schemes that fail contrast ratios, or implementations that do not correctly trigger focus management. Vendor claims of WCAG conformance should be verified through independent testing, not accepted at face value.

Your cookie banner is probably the first interactive element a user encounters on your site. If it excludes disabled users from exercising a privacy right, you have a compliance failure on two fronts simultaneously — one under privacy law and one under accessibility law.

Automated consent management platforms can reduce the engineering burden, but they require validation rather than blind trust. The audit checklist above covers the minimum a compliant implementation must satisfy. If your current banner cannot pass it, the exposure is real — and with EAA enforcement now active, regulators have the tools and the mandate to act on it.

See how accessible consent management works in practice — or