Most cookie consent banners fail basic accessibility checks — including tools whose vendors advertise them as “WCAG/ADA compliant.” Independent keyboard and screen-reader testing published in 2025 found conformance failures in every popular consent tool it examined, CookieYes and Complianz included. And because the banner loads on every page before anything else, one broken consent tool can put an accessibility barrier in front of your entire site.
The good news: the failures are consistent and well documented, most have configuration-level fixes, and you can test your own banner in about five minutes. Here’s what breaks, what the testing actually found, and what to do about it.
Why your cookie banner is the first thing a tester hits
When someone tests your site with a screen reader or keyboard — a customer, an auditor, or a plaintiff’s expert building a case — the consent banner is the first interactive component they meet. It appears on every page, often as a modal that sits on top of the content. If they can’t perceive it, operate it, or get past it, nothing behind it matters.
That’s not a theoretical risk. According to UsableNet’s year-end tracking, more than 5,000 digital accessibility lawsuits were filed in US federal and state courts in 2025, and nearly 70% targeted e-commerce sites — exactly the sites most likely to run a consent tool for privacy compliance. We break down what those filings mean for small businesses in our analysis of the lawsuit numbers.
There’s an irony worth naming: businesses install these banners to comply with one set of laws (GDPR, CCPA, and state privacy acts) and can end up violating another (the ADA) in the process. A consent tool that a blind user can’t operate isn’t just an accessibility failure — it also means that user never got a real chance to give or refuse consent.
What WCAG requires of a cookie banner
A consent banner is interactive content, so the same WCAG 2.1 AA rules apply to it as to the rest of your site. In practice, six criteria do most of the work. Accessibility auditor Marcus Herrmann catalogued the recurring failure patterns in Smashing Magazine’s “The Potentially Dangerous Non-Accessibility of Cookie Notices” in 2023, and they map to this checklist:
- Everything works with a keyboard. SC 2.1.1 Keyboard requires that “all functionality of the content is operable through a keyboard interface” (W3C) — every accept, reject, settings, and toggle control.
- Focus can get in and back out. SC 2.1.2 No Keyboard Trap — and the reverse problem matters too: while a modal banner is open, focus shouldn’t leak into the blocked page behind it.
- You can see where the keyboard is. SC 2.4.7 Focus Visible — each button and toggle needs a visible focus indicator.
- Text and controls have enough contrast. SC 1.4.3 requires 4.5:1 for normal text; SC 1.4.11 covers the buttons and toggles themselves. Banner color schemes are usually set in the vendor dashboard, which is where this one breaks.
- Buttons are real buttons. Herrmann’s audits kept finding divs and spans “posing as links or buttons” that lack button semantics and keyboard focusability — a failure of SC 4.1.2 Name, Role, Value that leaves screen readers announcing nothing useful.
- It survives zoom. At 400% zoom, the banner has to reflow instead of cropping its own buttons off-screen (SC 1.4.10 Reflow).
Do the popular consent tools pass testing?
As of the most recent published testing, none of the widely used tools passed cleanly. Two sources did the real work here. Equalize Digital CEO Amber Hinds audited the top WordPress consent plugins in “WordPress Cookie Banner Accessibility Lies” (updated October 2025), concluding: “I have not found one that is genuinely WCAG-conformant without the need for at least some remediation.” Then in an October 22, 2025 live session, blind engineer Alex Stine tested the same tools with a screen reader. Separately, the UK public-sector resource Make Things Accessible ran a case study across 11 consent tools in 2023, including OneTrust’s CookiePro.
| Tool | What the vendor says | What independent testing found |
|---|---|---|
| Complianz (1M+ installs) | Claims WCAG 2.1 AA and ADA compliance | Nested interactive elements, no focus trap, focus lost on accept, reflow failures at 400% zoom |
| CookieYes (1M+ installs) | WCAG/ADA compliance claim, added Sept 2025 | Focus never moves to the banner, region role instead of dialog, missing focus trap |
| GDPR Cookie Compliance / Moove (300K installs) | Claims WCAG and ADA accessibility | Buried at page bottom — the tester put the odds of finding it at about 10% — checkboxes hidden with display:none, unusable by keyboard |
| Usercentrics / Cookiebot | ”WCAG 2.1 Certified” badge | Essential consent control hidden from screen readers with aria-hidden, focus loss on saving settings |
| OneTrust CookiePro | Says it’s “committed to getting as close as possible” to accessible | Focus visibility failures, contrast problems, aria-labels that contradict visible text (2023 case study) |
Two honest counterpoints, because this isn’t a hit piece. In Stine’s screen-reader session, Real Cookie Banner came out best — proper fieldsets, useful descriptions, the fewest issues overall — and he judged Complianz usable in practice (“there’s no issue here that would prevent someone from using this cookie banner”), even while flatly rejecting its WCAG-conformance claim. And in the Make Things Accessible study, exactly one banner passed WCAG 2.2 AA outright: the UK government’s own, which no commercial vendor sells. Vendors also ship updates constantly, so any specific finding may already be fixed — or newly broken — in the version you’re running. That’s the argument for testing your installation rather than trusting a table, including this one.
Can you trust a “WCAG certified” badge?
No — start with the fact that WCAG certification doesn’t exist. The W3C publishes the guidelines but certifies nothing, which is why Hinds calls vendor badges misleading at minimum: “There’s no such thing as WCAG certification.” A claim of conformance is only as good as the testing behind it, and per the table above, the testing keeps disagreeing with the claims.
Even the most enterprise-grade vendor hedges when it matters. OneTrust’s own European Accessibility Act guidance (April 2025) confirms consent banners fall within the EAA’s scope — a law that started applying in June 2025 and reaches many US companies selling into the EU, as we cover in our EAA guide for US businesses — while conceding: “It may not be feasible to make every interface 100% accessible without affecting usability.” That’s the vendor’s fine print. Your site, though, is what gets named in the demand letter.
How to test your cookie banner in five minutes
You don’t need a developer to find most of these failures. This is a focused version of our 10-minute keyboard test, aimed at the banner:
- Open your site in a private/incognito window so the banner actually appears, and don’t touch the mouse.
- Press Tab. Does focus reach the banner quickly — ideally first? If you Tab through the entire page before the banner shows up, a screen-reader user may never know it’s there.
- Look at every stop. Can you always see which button or toggle is focused? An invisible focus ring fails SC 2.4.7.
- Operate it. Reject, accept, open the settings panel, flip a toggle, save — all with Enter, Space, and arrow keys. Anything you can only do by clicking fails SC 2.1.1. Confirm you can also Tab back out afterward.
- Zoom to 400% (Ctrl/Cmd and +) and check nothing crops off-screen. Then run the banner’s text and button colors through a contrast checker — normal text needs 4.5:1.
Write down anything that fails, with the page and the element. That list is exactly what your developer — or we — need to fix it.
How to fix what fails
Roughly in order of effort:
Fix the configuration first. Contrast is usually a dashboard setting: you or your designer picked the banner colors, so pick ones that pass. Several tools also have accessibility-relevant options — Complianz, for example, tested far better with the right settings enabled. Check your tool’s accessibility documentation and turn on everything it offers.
Move the banner up in the code. Stine’s advice: at minimum, “make the cookie banner available as the first item in the HTML,” so assistive-technology users discover it immediately instead of after tabbing through the whole page. Ask your developer where the consent script injects its markup.
Demand real semantics. The banner should be a proper dialog with a focus trap while open, built from native button elements with descriptive names — not styled divs. If your tool can’t be configured into that shape, that’s a code-level fix or a reason to switch tools.
Retest after every update. Consent vendors ship frequently, and a passing banner can regress silently. Fold the five-minute check above into your update routine — especially on WordPress, where most of these plugins live alongside other common accessibility pitfalls.
The banner is the front door
An inaccessible cookie banner is a sitewide barrier wearing a compliance costume — installed to satisfy one law while failing another, on every page, first. It’s also usually one of the fastest wins in a remediation project, because the fixes are known and the component is small.
But it’s rarely the only barrier. The same testing mindset that just failed your banner will fail your menus, forms, and checkout too, and that’s what manual remediation is for. Want to see where your site stands, banner included? Start with a free scan.