Your cookie banner renders on every page, interrupts every first visit, and is often built by a third party you never audited. That makes it the single highest-traffic component on the site — and one of the most common WCAG failures: unreachable by keyboard, invisible to screen readers, low-contrast by design. Under the European Accessibility Act, an inaccessible consent banner is not just bad UX. It is a compliance problem sitting on top of your compliance tool.
There is a special irony in the compliance stack: the component you added to satisfy one European law can put you in breach of another. Consent banners are interactive dialogs shown to 100% of first-time visitors — and interactive dialogs are exactly where accessibility failures concentrate.
The four ways banners fail WCAG
1. Keyboard users can’t reach it — or can’t escape it (SC 2.1.1, 2.1.2)
Try it on your own site: load a fresh incognito session and press Tab. Can you reach the banner’s buttons without a mouse? Can you get past the banner to the page content? Many CMP configurations fail one or both — and a keyboard trap on every page of the site is a sitewide WCAG failure with a single root cause.
2. Screen readers don’t announce it (SC 4.1.2, 1.3.1)
A banner that is not marked up as a dialog, with no accessible name and no focus management, simply does not exist for a screen reader user — until they stumble into it. Meanwhile the overlay blocks the page. The visitor can neither consent nor refuse: they are locked out by the consent mechanism itself.
3. The “decline” path is low-contrast by design (SC 1.4.3)
The grey-on-grey reject link is usually discussed as a dark pattern problem — regulators have opinions about that already. But it is also frequently a plain contrast failure: text below the 4.5:1 minimum ratio. Low contrast text is the single most common accessibility failure on the web, found on 83.9% of the top million homepages (WebAIM Million, February 2026). Your banner’s decline button is often part of that statistic.
4. Focus goes nowhere after the choice (SC 2.4.3)
Visitor accepts, banner disappears — and keyboard focus is dropped at the top of the document, or worse, left on a node that no longer exists. Focus order is one of those criteria nobody notices until you navigate without a mouse, which is precisely why it survives every redesign.
Why this stopped being theoretical
The European Accessibility Act has applied to B2C digital services since June 2025, benchmarked (via EN 301 549) against WCAG level AA. Enforcement started in 2026 — a French court gave Carrefour six months to fix its site under daily penalties, and German shops are collecting Abmahnungen. A banner that fails keyboard access fails it on every page — for an enforcement lawyer, that is the easiest exhibit imaginable.
We wrote up what a proper WCAG audit covers — automated versus human review, and what a useful report looks like — on WCAG Inspector, the accessibility audit tool we are building alongside CookieInspector.
The five-minute self-test
- Open your site in a private window.
- Press Tab until focus reaches the banner. If it never does, you found finding #1.
- Operate every banner control with Enter/Space only.
- Check the decline control’s contrast in DevTools (4.5:1 minimum for normal text).
- After choosing, keep tabbing: does focus land somewhere sensible in the page?
If any step fails, your consent layer is generating WCAG violations at the scale of your entire traffic.
Audit both halves of the stack: scan what loads before consent with CookieInspector, and join the WCAG Inspector early-access waitlist to catch what your banner — and the rest of the site — does to the visitors who can’t use a mouse.