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. Go on, we'll wait. If you can't find the buttons, or if Tab just keeps cycling through the same three links forever, congratulations: your consent management 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. It's usually not a design problem or a content problem — it's a few lines of focus-management JavaScript that some consent vendor shipped once and nobody has looked at since. Ten minutes with a keyboard and a coffee, and you can know for certain whether your banner is doing this to people.
The Stat: WCAG 2.1.2 No Keyboard Trap (Level A) requires that once keyboard focus moves into a component, it must always be possible to move focus away again using only the keyboard — unless the user has been told a non-standard way to exit. (Source: W3C Web Accessibility Initiative)
Why this bug happens in the first place
Almost nobody hand-codes a cookie banner anymore. It comes bundled from a consent management platform (CMP), dropped in as a third-party script, and rendered on top of your actual page. That's convenient for legal compliance, but it creates a very specific accessibility risk: the banner's markup and focus behavior are entirely outside your control, and most CMPs were built to satisfy a legal checkbox, not a keyboard user.
Two failure modes show up over and over:
- Focus never reaches the banner at all. The banner renders visually on top of the page, but Tab order skips right past it into the page underneath. A sighted mouse user sees "Accept" and "Reject" buttons; a keyboard user tabs straight through invisible page content and never lands on either one.
- Focus gets stuck inside the banner. This is the true keyboard trap, and the one worth testing for first. Tab moves between the banner's links and buttons, but never advances into the page — because the CMP script intercepts focus and forcibly returns it to the banner every time it tries to leave, and there's no Escape key or close button that works either.
Both of these are keyboard failures under WCAG 2.1.1 Keyboard, which requires that all functionality be operable through a keyboard interface, without requiring specific timing for individual keystrokes. The second one is specifically the failure that WCAG 2.1.2 No Keyboard Trap exists to prevent: once focus moves into a component, the user must always be able to move it back out using the keyboard alone.
The two-minute test you can run right now
You don't need any tools for this. You need a keyboard and about two minutes.
- Open the site in a private/incognito window so the banner actually appears.
- Press Tab once. Does visible focus land somewhere — ideally on the banner itself, or a "skip to content" link?
- Keep pressing Tab. Does focus reach a Reject/Decline option before it reaches Accept? (If Accept is the only easy option, that's a dark-pattern problem worth flagging too, separate from accessibility.)
- Keep pressing Tab past the buttons. Does focus leave the banner and land on the page's header, nav, or main content?
- If focus seems stuck, try Escape. Does it close the banner?
- If Escape does nothing and Tab loops back to the same two or three elements indefinitely, you have a keyboard trap.
If you got through all six checks without a hitch, genuinely — well done, that's rarer than it should be. If you hit a wall at any point, keep reading.
What "fixed" actually looks like
A correctly built consent banner behaves like a well-built modal dialog, because functionally that's what it is: content that interrupts the page and demands a decision before (in some designs) the rest of the page becomes usable. The ARIA Authoring Practices Guide's Dialog (Modal) Pattern lays out the exact behavior to aim for, and it maps cleanly onto a cookie banner:
| Behavior | Broken banner | Fixed banner |
|---|---|---|
| Initial focus | Lands on page content, ignoring the banner | Moves to the banner (or its first control) when it appears |
| Tab order | Skips the banner, or loops only inside it forever | Cycles through the banner's own controls, then releases to the page |
| Reject / Accept | Sometimes only one option is keyboard-reachable | Both are reachable in a predictable order |
| Escape key | Does nothing | Closes the banner (or is intentionally disabled with a clear on-screen reason) |
| After dismissal | Focus is lost or reset to the top of the page | Focus returns to where the user was, or moves logically into the page |
Most of the time, this isn't something your team writes from scratch — it's a configuration or a support ticket to your CMP vendor, because the trap usually lives in their script, not your template. But you can't file that ticket with any credibility until you've done the two-minute test above and can describe exactly where focus gets stuck.
Quick fixes, roughly in order of effort
- File it as a bug, not a preference. "Keyboard users can't close the banner" is a WCAG 2.1.2 failure, which is Level A — the baseline, not a stretch goal. That framing gets it prioritized correctly.
- Check for a vendor setting first. Many CMPs have gone through their own accessibility remediation and expose a "focus trap" or "modal" toggle you may not have enabled. Ask their support team directly whether their banner passes 2.1.1 and 2.1.2 by default.
- If it's custom-built, fix the focus handlers. The trap is almost always a
focusorkeydownlistener that forcibly redirects focus back into the container on every Tab press instead of only doing so at the two natural boundaries (looping from the last control back to the first, and vice versa — which is correct trapping behavior for an open modal, as long as Escape or a close action releases it). - Wire up Escape. Even a simple banner benefits from an Escape handler that dismisses it and returns focus to the page.
- Re-run the two-minute test. Don't ship the fix on faith — tab through it again yourself.
One more thing worth checking while you're in there: whether the trap re-appears on every page load. Some CMP scripts re-inject the banner (and re-trigger the trap) on every route change in a single-page app, even after a user already made a choice, because the consent cookie check runs before the framework has finished rendering the rest of the page. If your keyboard test passes on the homepage but the banner comes back — trap and all — the moment someone navigates to a second page, that's the same bug showing up on a timer rather than a one-time landing-page problem, and it deserves the same priority.
This is a genuinely small fix with a genuinely large payoff: it's the one interaction that happens on effectively every page, for every visitor, before anything else on your site gets a chance to matter.
If you'd like a second set of eyes on it, and on whatever else might be lurking behind that banner, you can get keyboard traps like this one flagged automatically with a free scan of your site.