The Consent Banner After the EAA: What June 28 Changed for CMPs
Your cookie banner was a privacy control. Since June 28, 2025, it is also an accessibility surface, and the two obligations now collide in the same few hundred pixels. The European Accessibility Act started applying on that date, and for the services it covers, e-commerce, banking, telecoms, transport, and media among them, the banner has to meet WCAG 2.1 Level AA through the harmonised standard EN 301 549. A banner that a keyboard user cannot operate, or a screen reader user cannot understand, is now a compliance failure under accessibility law, not just a bad experience.
The collision is the interesting part. GDPR Article 7 requires consent to be freely given, specific, informed, and unambiguous. A visitor who cannot operate the banner cannot meaningfully give or withdraw consent, so the consent collected through an inaccessible banner may not be valid at all. One broken banner, two violations, and the same fix answers both.
What the EAA actually requires of a banner
The EAA works through EN 301 549, whose web requirements follow WCAG 2.1 Level AA. WCAG 2.2, published in October 2023, includes everything in 2.1 and adds new criteria, and the W3C recommends using the latest version. Meeting 2.2 AA therefore also meets 2.1 AA, so the practical target is 2.2 AA, not 2.1. The criteria that banners fail most are a short list: 2.1.1 Keyboard, every interactive element operable by keyboard alone; 2.1.2 No Keyboard Trap, focus must always be able to leave; 2.4.7 Focus Visible; 2.4.11 Focus Not Obscured, new in 2.2, the focused element must not be hidden behind the banner; 2.5.8 Target Size, new in 2.2, buttons and switches need at least 24 by 24 CSS pixels; and 4.1.2 Name, Role, Value, the screen reader semantics.
The bottom bar is the pattern that fails 2.4.11 most. A bar fixed to the bottom of the screen can cover the link a keyboard user has just tabbed to on the page behind it. If your banner uses a modal pattern with an overlay, mark the page behind it inert so assistive technology and the keyboard cannot reach content the visitor cannot see. Without that, a screen reader's virtual cursor wanders into the obscured page, and the consent choice becomes noise.
The test that takes two minutes
Open the site in a private window so the banner actually appears, and use nothing but the Tab key. Press Tab once: does visible focus land on the banner, or on a skip link. Keep pressing Tab: does focus reach a Reject option before it reaches Accept, or is Accept the only easy option. Keep pressing past the buttons: does focus leave the banner and land on the page header or main content. If Escape does nothing and Tab loops back to the start of the banner, you have a trap, and it is a failure of 2.1.2.
Then check the small things that sink the rest of the criteria. Category switches built from divs or spans styled to look like switches are invisible to keyboards unless they carry role switch, tabindex 0, and aria-checked, plus key handling. Real button and input elements are better than styled divs, and this is the place to prefer them. Color contrast at 4.5 to 1 applies to all text in the banner, including placeholder text and button labels. Toggle changes need an aria-live polite container or a role status element, so a screen reader user hears that a preference was actually written.
Who fixes it, you or the vendor
The banner comes from a consent management platform, dropped in as a third-party script, and the accessibility failures usually live in the vendor's code, not yours. That does not move the obligation. Under the EAA the service provider is responsible for the service, and under GDPR the controller is responsible for the consent. File the failures with the vendor as defects, with the criterion numbers attached, and get a fix date in writing. A vendor that cannot give one is telling you its roadmap does not include the law that started applying in June 2025.
While you wait, do the part that is yours. Check the contrast of your banner text against its background, check that the reject option has equal weight in the tab order, and check that the banner does not obscure focused content on the page behind it. Those three are configuration, not code, and they are the difference between a banner that fails every criterion and one that fails the vendor's half only.
Keep reading: White Label Cookie Consent: What It Is and How to Choose a Platform, Checkout Sets Cookies Before Consent. That Is Where the Banner Fails., and Consent Banners on Mobile: The Bottom Sheet Problem Nobody Tests cover the nearby cases in this series.
Frequently asked questions
When did the European Accessibility Act start applying?
June 28, 2025. It covers products and services including e-commerce, banking, telecoms, transport, and media, and works through EN 301 549, which follows WCAG 2.1 Level AA.
Which WCAG version should a cookie banner target?
WCAG 2.2 Level AA. It includes everything in 2.1 and adds criteria banners often fail, including Focus Not Obscured and Target Size. Meeting 2.2 AA also meets 2.1 AA.
Can an inaccessible banner invalidate consent?
Yes. Under GDPR Article 7, consent must be freely given, specific, informed, and unambiguous. A visitor who cannot operate the banner cannot meaningfully give or withdraw consent, so the consent may not be valid.
What is the most common accessibility failure in cookie banners?
Keyboard access. Either focus never reaches the banner at all, or it gets stuck inside it with no way out. Both are failures under WCAG 2.1.1 and 2.1.2, and both are testable in two minutes with the Tab key.