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.
