Accessibility Became Enforceable on 28 June 2025
The European Accessibility Act (Directive (EU) 2019/882) started applying on 28 June 2025. It requires a range of consumer services to be accessible to people with disabilities: e-commerce, consumer banking, telecoms, transport ticketing, e-books, and audiovisual media services offered to EU consumers. Enforcement wasn't theoretical. Within days of the deadline, French disability groups sent formal legal notices to major grocery retailers over inaccessible e-commerce sites.
Your cookie banner sits between the visitor and the service. A modal that traps keyboard focus, or whose reject button a screen reader never announces, is a barrier to using the whole site. That puts the banner inside the EAA's scope, and it compounds a problem we've written about before in cookie banner accessibility.
The Standard: EN 301 549 and WCAG
The EAA itself doesn't spell out pixel values. It points to a harmonised technical standard, EN 301 549, whose current version (v3.2.1) maps web accessibility to WCAG 2.1 Level AA. So the legal floor today is WCAG 2.1 AA, not the newer 2.2.
That said, don't build to the floor. WCAG 2.2 became a W3C Recommendation and adds nine success criteria, several of which hit banners directly. A new EN 301 549 v4.1.1 is expected in 2026 to fold WCAG 2.2 into the harmonised standard. Meeting 2.2 now means you won't be re-testing your banner when that lands.
2.1 AA Is the Floor; 2.2 Is the Direction
Today's EAA benchmark is WCAG 2.1 AA via EN 301 549 v3.2.1. WCAG 2.2 is where the harmonised standard is heading with the expected v4.1.1 update. Building to 2.2's target-size and focus criteria now is cheap insurance against re-work later.
Where Consent Banners Fail WCAG
Banners break the same handful of criteria over and over:
- Keyboard operability (WCAG 2.1.1). A visitor who never touches a mouse must be able to Tab to every control, including reject, and activate it with Enter or Space.
- Focus management. When a modal banner opens, focus should move into it; when it closes, focus should return sensibly. A banner you can't reach by keyboard, or that dumps you back at the top of the page, fails.
- Focus not obscured (WCAG 2.2, 2.4.11). A sticky banner that hides the element currently receiving focus is a new, specific failure under 2.2.
- Contrast (1.4.3 and 1.4.11). Grey-on-white "reject" links routinely miss the ratios below.
- Target size (WCAG 2.2, 2.5.8). Tiny close icons and toggle switches under 24 by 24 CSS pixels fail unless they're spaced far enough apart.
- Screen-reader semantics. Buttons need real roles and labels, so "Reject all" is announced as a button, not read as ambiguous text.
A ten-minute accessibility test for your banner
Keyboard-only pass
Put the mouse away. Load the page, and using only Tab, Shift+Tab, Enter, and Space, confirm you can reach and activate both accept and reject, and open the preferences panel. If you can't reach reject without a mouse, stop, that's your first fix.
Screen-reader pass
Turn on VoiceOver (Mac), NVDA (Windows), or TalkBack (Android). Confirm the banner is announced when it appears, that each control's role and label are read out, and that focus is inside the banner, not stranded behind it.
Contrast check
Sample the text and buttons with a contrast tool. Normal text needs at least 4.5:1 against its background; large text and UI component boundaries and focus indicators need at least 3:1.
Target size check
Measure the close icon and any toggles. Aim for a 24 by 24 CSS-pixel hit area, or clear spacing between small targets.
Zoom and reflow
Zoom to 200% and confirm nothing is cut off, then check the banner still works in a narrow viewport (the 400% reflow case). Buttons shouldn't overlap or disappear.
An Inaccessible Banner Is Also a Consent Problem
This isn't only an accessibility obligation. If a keyboard or screen-reader user physically can't operate the reject control, their consent isn't freely given, and consent that isn't freely given isn't valid. So a banner that fails WCAG can fail your GDPR consent basis at the same time. Two regimes, one fix.
Contrast and Target Size, in Numbers
Keep these thresholds on a sticky note when you design the banner. Text: 4.5:1 minimum contrast for normal text, 3:1 for large text. User-interface components and their focus indicators: 3:1 against adjacent colours. Interactive targets: 24 by 24 CSS pixels, or smaller with enough spacing, per the W3C's Target Size (Minimum) guidance. Design the accept and reject buttons to the same visual weight while you're at it; a faint reject next to a bold accept is a dark pattern as well as a contrast risk.
Accessible consent banner checklist
Every control is reachable and operable by keyboard
Including reject and preferences, using Tab plus Enter or Space.
Focus moves into the banner on open and returns on close
And focused elements are never hidden behind sticky UI.
Text meets 4.5:1 contrast, UI components and focus meet 3:1
Check the reject link specifically, it's the usual offender.
Interactive targets are 24x24 CSS px or well spaced
Close icons and toggles are the common failures.
Controls expose correct roles and labels to screen readers
Buttons announce as buttons with a clear name.
The banner survives 200% zoom and 400% reflow
Nothing overlaps, disappears, or becomes unreachable.
You Own the Outcome, So Test the Live Banner
Whatever consent tool you run, the accessibility of the banner your visitors actually see is yours to verify. CookieBeam banners are fully configurable, so you can set colours and sizes that meet the contrast and target-size thresholds rather than fighting a fixed template, and they support keyboard operation and screen-reader semantics out of the box. After any style change, run the ten-minute test above against the live banner, that's the step that catches a regression before an auditor does.