Cookie Consent Banners: The Most-Failed Accessibility Element on the Web

If you measured accessibility violations per square pixel, the cookie consent banner would win every time. It is usually the first interactive element a visitor meets, it sits on top of everything else, and it is almost always built by a third-party vendor who optimised for legal compliance, not for the people who actually have to use it.

We test a lot of cookie banners. The pattern is the same on small business sites and on Fortune 500 sites: the banner blocks access to the page until you accept, but the “accept” button cannot be reached by keyboard, the banner steals focus from the navigation, or the entire dialog is invisible to screen readers. Visitors with disabilities are forced to either guess and click somewhere blind, leave the site entirely, or accept settings they did not understand.

This guide is for non-developers, marketing leads, and small business owners who manage a site that uses a consent banner from CookieYes, OneTrust, Cookiebot, Iubenda, Termly, Complianz, or a custom WordPress plugin. We will explain why the European Accessibility Act now puts cookie banners squarely in scope, the five failures we see most often, and what to ask your vendor or developer to fix.

Until 2025, most accessibility audits treated cookie banners as a separate compliance problem. Privacy law required them; accessibility law tolerated them. That convenient separation ended on June 28, 2025, when the European Accessibility Act began applying to websites that sell to consumers in the EU. The Act covers “the website” as a whole, and since the banner appears on every page and blocks interaction with the underlying content, it is part of the website experience that must meet WCAG 2.1 AA.

The U.S. picture is similar. ADA Title III lawsuits in 2025 increasingly cited cookie banners as the inaccessible element that prevented the visitor from reaching the rest of the site. Courts have not been sympathetic to the argument that the banner is the vendor’s responsibility. If you display it, you own it.

That puts site owners in an awkward spot. Most cookie banners are dropped in via a single line of script from a SaaS vendor, and the markup is generated dynamically at page load. You cannot just open the HTML and fix an aria-label. But you can audit the banner, escalate clearly to your vendor, and in many cases switch to a configuration setting that fixes the issue immediately.

The five failures we find on almost every banner

1. Keyboard focus is never moved into the banner

When the banner appears, focus stays on whatever was focused before — usually the page body or the URL bar. A sighted user notices the banner because it is visually obvious. A keyboard user, especially one using a screen reader, has no idea anything has appeared. They tab forward through navigation and form fields, never realising that an entire modal dialog is sitting on top of the page intercepting clicks.

The fix is to programmatically move focus into the banner the moment it appears, ideally to the first interactive element (a heading announcing the banner, or the first button). When the banner closes, focus must return to where the user came from.

To test: load the page, press Tab once. If your first tab stop is somewhere in the page navigation rather than inside the banner, the banner is failing.

2. The banner is not announced as a dialog

Even if focus moves correctly, screen readers will only announce the banner properly if it is marked up as a dialog with role="dialog" (or role="alertdialog" for a blocking choice), an accessible name via aria-labelledby, and a description via aria-describedby. Without these, NVDA or VoiceOver will read the buttons one at a time without giving the user any sense that they are inside a separate, blocking interface.

The result: the screen reader user hears “Accept button. Reject button. Manage preferences button,” with no context, no heading, and no idea what they are accepting.

To test: use VoiceOver (Mac, Cmd+F5) or NVDA (Windows, free) and load the page. The screen reader should announce something like “Cookie consent dialog. We use cookies to improve your experience…” within a second of the page loading.

3. Focus is not trapped inside the banner

If the banner is a true blocking dialog, focus must stay inside it until the user makes a choice. Many vendor banners let you tab right out of the banner and into the underlying page, where you can interact with links and forms that are visually obscured. Worse, on some implementations the banner remains visible but is no longer in your tab order, so once you tab past it you cannot get back without a mouse.

This violates WCAG 2.4.3 Focus Order and WCAG 2.1.2 No Keyboard Trap (the inverse trap, where you cannot stay where you should). It also makes the banner pointless — if the user can interact with the page underneath, the banner is not actually blocking analytics scripts from running on the user’s first click.

4. Buttons have unclear or invisible labels

The most common failure is a “Manage preferences” gear icon with no accessible name, or a small “X” close button that screen readers announce as just “button.” The CookieYes free tier in 2024 shipped with a close icon that had no aria-label at all; we still find sites running that version.

A second variant: the buttons have accessible names, but they are vague. “Accept” and “Decline” alone do not tell the user what they are accepting or declining. WCAG 2.4.4 Link Purpose and WCAG 2.5.3 Label in Name both require that the visible label and the accessible name match and that the button’s purpose is clear in context.

The fix is straightforward: every button needs a clear, contextual accessible name. “Accept all cookies,” “Reject non-essential cookies,” “Customise cookie preferences,” “Close cookie banner.”

5. Colour contrast in the banner fails WCAG AA

This one is almost universal. Cookie banners use brand colours, and the brand colour is often a pale grey, a soft brand pink, or a low-contrast pastel that fails the 4.5:1 contrast ratio for normal text. The “Manage preferences” link is often even worse, set in the same pale grey to look subtle next to a bright “Accept” button — a pattern regulators have started calling out as a dark pattern, since it nudges the user toward consent.

To test: use the WebAIM Contrast Checker or the browser’s accessibility inspector to measure the contrast of every text element in the banner against its background. Anything below 4.5:1 fails for normal text and below 3:1 fails for large text.

How to audit your own banner in ten minutes

You do not need a developer for this. Open your site in an incognito window so the banner reappears, then run through this list:

  1. Tab test. Press Tab once after the page loads. Did focus jump into the banner? Now Tab through every button. Is the visual focus indicator visible at every step? Tab past the last button — does focus loop back into the banner, or does it escape into the page underneath?
  2. Screen reader test. Turn on VoiceOver or NVDA, reload the page, and listen. Within a second or two, the screen reader should announce the dialog and read the banner text. Each button should announce a clear, descriptive name.
  3. Mouse-free escape test. Try to dismiss the banner using only the keyboard. The Escape key should close it (if there is a close affordance), and Enter should activate the focused button.
  4. Contrast test. Use the WebAIM Contrast Checker on the banner text and the smallest link inside the preferences modal. Anything below 4.5:1 is a failure.
  5. Underneath test. Try to scroll the page behind the banner and click on links underneath while the banner is open. If you can interact with the page, the banner is not actually blocking analytics, which means it is not doing its legal job either.

If any test fails, document the specific issue and send it to your cookie consent vendor’s support team. Most vendors have an accessibility roadmap, but they prioritise issues that paying customers report.

What to ask your vendor

Three questions cut through marketing copy and tell you whether a cookie consent vendor is serious about accessibility:

  1. Do you publish a current VPAT or Accessibility Conformance Report against WCAG 2.2 AA? OneTrust, Cookiebot, and Usercentrics all publish VPATs. CookieYes and Termly do not, as of April 2026.
  2. Does the banner support keyboard focus management and dialog semantics out of the box, or do I need to configure them? The right answer is “out of the box.” If the vendor tells you to add custom CSS or JavaScript to make the banner accessible, you have a vendor problem.
  3. What is your process when a customer reports an accessibility bug in the banner? A vendor that takes accessibility seriously has a public security and accessibility disclosure process. A vendor that does not will route you to general support and quietly never fix it.

If your current vendor scores poorly on all three, switching is easier than you think. Cookiebot (Cybot), Usercentrics, and Iubenda’s premium tier all ship accessible-by-default banners. Migration is mostly a matter of updating one script tag and re-categorising your existing cookies in the new dashboard.

A pragmatic path forward

The honest reality is that almost every site reading this article has at least one failing item in the audit above. That does not mean you are about to be sued tomorrow, and it does not mean you should panic-rebuild your consent flow. It means you should:

  1. Run the ten-minute audit and write down every issue.
  2. Send the issues to your vendor with a clear deadline (30 days is reasonable).
  3. While you wait, fix what you can control — for example, adjust the banner’s brand colour to one that meets contrast, or switch from “decline” wording to “reject non-essential cookies” if your vendor exposes a custom-text setting.
  4. If your vendor will not fix what they own, switch vendors. The cost of switching is far lower than the cost of an EAA enforcement action or an ADA demand letter.

Cookie banners are one of the few accessibility problems where you do not need to redesign anything. The fixes are mostly configuration changes and vendor escalations. The hard part is knowing what to look for, which is exactly what this guide gives you.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.