The Cookie Banner Button With No Name: An Accessibility Failure Hiding in Plain Sight
Open your own site in a private window right now, and try to accept or reject your own cookie banner using nothing but the Tab key. If you cannot find the buttons, or if Tab keeps cycling through the same three links forever, your consent platform just failed the very first interaction a real visitor has with your site. This is one of the fastest, most satisfying bugs to fix in all of web accessibility, and it is usually a few lines of focus-management JavaScript that some vendor shipped once and nobody has looked at since.
The stakes changed on June 28, 2025, when the European Accessibility Act started applying. A banner on a covered service has to meet WCAG 2.1 Level AA, and WCAG 2.2, the current version, adds criteria that banners fail constantly. An inaccessible banner is no longer just a bad experience. Under the EAA it is a compliance failure, and under GDPR Article 7 it can mean the consent was never validly given, because a visitor who cannot operate the interface cannot meaningfully choose.
A cookie banner button needs an accessible name, a visible focus state, and a keyboard path to every choice, including reject. A button with no accessible name is announced by screen readers as just button, and a banner that traps keyboard focus or hides reject behind a mouse-only control collects consent from some visitors and excludes others.
The failure you cannot see with a mouse
Open your site with a keyboard only. Tab to the banner. The first thing to check is whether you can reach the reject option at all. Many banners let the mouse click reject in settings while the keyboard path dead-ends at accept. That is a keyboard trap, and it is the same failure as a door with no handle on one side: the choice exists for some visitors and not for others.
The second check is the accessible name. A button that shows an X or an icon with no text needs an aria-label or equivalent, or a screen reader announces it as button and the visitor has no idea what it does. A close icon that dismisses the banner without recording a choice is worse, because the visitor thinks they refused and the site records nothing, or records an implied consent that was never given. WCAG success criterion 4.1.2 requires every interface component to have a name that assistive technology can read, and a cookie banner is not exempt because it is a popup.
Why this is a consent problem, not just an accessibility problem
Consent has to be freely given and unambiguous. A visitor who cannot reach the reject button has not freely chosen accept, they have been funnelled into it. A visitor whose screen reader announces button, button, button has not been informed about what they are agreeing to. The consent collected from those visitors is weak, and a regulator who tests the banner with a keyboard will find it in minutes.
The enforcement angle is real. Accessibility lawsuits in the US run heavily on exactly this class of failure: a control that cannot be operated or named. The cookie banner is often the first thing a visitor meets, and it is the first thing a tester checks. A site that fixed its checkout for keyboard users and left the banner broken has fixed the shop and left the front door jammed.
Fixing it without a redesign
Give every banner control a text label or an aria-label: Accept all, Reject all, Manage preferences, Close. Make sure the reject control is a real button, not a link styled to look unimportant, and that it sits on the first layer beside accept. Test the focus order: tab should move through the banner in a sensible order, focus should be visible, and focus should never get stuck inside the banner or skip past it.
Then test with a screen reader, even a free one, for five minutes. Listen to what the banner announces. If you hear button three times with no names, the fix is a few attributes, not a project. Log the test with the date. A banner that passes a keyboard and screen reader test is a consent flow that works for everyone, and that is the only kind worth keeping.
Keep reading: When Your CMP Vendor Changes Subprocessors, Your Consent Records Move Too, The Cookie Banner Keyboard Trap: Test Yours With Tab Alone, and Consent Evidence Is a Timeline. Keep the Versions. cover the nearby cases in this series.
Frequently asked questions
What is an accessible name on a button?
The text a screen reader announces for a control, from its visible label or an aria-label. A button with no accessible name is announced as just button, and the visitor cannot tell what it does.
Does the reject button need to work by keyboard?
Yes. Every choice in the banner, including reject, has to be reachable and operable by keyboard alone. A reject option that only works with a mouse excludes keyboard users from refusing.
Is a cookie banner covered by WCAG?
Yes. WCAG applies to all web content, and the banner is web content. Success criterion 4.1.2 requires components to expose their name, role and value to assistive technology.
What is a keyboard trap in a banner?
A banner where keyboard focus enters but cannot leave, or cannot reach a control. The visitor tabs in and cannot tab out, or cannot reach reject. Either way the banner is broken for keyboard users.