# The Cookie Banner Keyboard Trap: Test Yours With Tab Alone Source: https://cookiecitadel.com/blog/2026-11-06-cookie-banner-keyboard-trap-test.html [Home](../index.md) / [Blog](index.md) / The Cookie Banner Keyboard Trap: Test Yours With Tab Alone Published 2026-11-06 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. ## The two failure modes Focus never reaches the banner at all. The banner renders visually on top of the page, but Tab order skips straight past it into the page underneath. A sighted mouse user sees Accept and Reject. A keyboard user tabs through invisible page content and never lands on either one. That is a failure of WCAG 2.1.1, Keyboard, which requires all functionality to be operable through a keyboard interface. Focus gets stuck inside the banner. 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 is no Escape key or working close button. That is the true keyboard trap, and it is exactly what WCAG 2.1.2, No Keyboard Trap, exists to prevent: once focus moves into a component, it must always be possible to move it back out using the keyboard alone. ## The two minute test Private window, so the banner actually appears. Press Tab once. Does visible focus land somewhere, ideally on the banner itself, or on a skip link. Keep pressing Tab. Does focus reach a Reject option before it reaches Accept, or is Accept the only easy option. That second question is a dark-pattern problem as well as an accessibility one, and it is worth flagging separately. Keep pressing Tab past the buttons. Does focus leave the banner and land on the page header, nav, or main content. If Escape does nothing and Tab loops back to the start of the banner, you have a trap. Then check the small things: the focused element must stay visible and not slide behind the banner itself, which is WCAG 2.2 criterion 2.4.11, Focus Not Obscured, the one bottom bars fail most. Buttons and switches need at least 24 by 24 CSS pixels, criterion 2.5.8, Target Size, also new in 2.2. ## What to fix, in order First, the tab order. It must follow the visual order, and Accept and Reject need equal weight in it, the same as on screen. Category switches built from divs or spans styled to look like switches are invisible to keyboards unless they carry role switch, tabindex 0, and aria-checked, plus key handling. Real button and input elements are better than styled divs, and this is the place to prefer them. Second, the dialog semantics. A modal banner needs role dialog and aria-modal true, and the page behind it should be marked inert so assistive technology and the keyboard cannot reach content the visitor cannot see. Without that, a screen reader's virtual cursor wanders into the obscured page behind the banner, and the consent choice becomes noise. Third, the state announcements: toggle changes need aria-live polite or a role status container, so a screen reader user hears that a preference was actually written. A toggle that flips silently has not communicated anything. Keep reading: [Consent Evidence Is a Timeline. Keep the Versions.](https://cookiecitadel.com/blog/2026-11-05-consent-version-history-evidence.md), [The Video Loads Before Anyone Presses Play. Use a Facade.](https://cookiecitadel.com/blog/2026-11-05-embedded-video-consent-facade.md), and [Single Page Apps Break Consent in a Specific Place: The Route Change](https://cookiecitadel.com/blog/2026-11-04-spa-route-change-consent-recheck.md) cover the nearby cases in this series. ## Frequently asked questions ### What is a cookie banner keyboard trap? A banner where keyboard focus enters but cannot leave, because the CMP script forces focus back into the banner on every Tab press and offers no working Escape key or close button. It violates WCAG 2.1.2, No Keyboard Trap. ### Which WCAG criteria do cookie banners fail most? 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.7 Focus Visible, 2.4.11 Focus Not Obscured, 2.5.8 Target Size, and 4.1.2 Name, Role, Value for screen reader semantics. The 2.4.11 and 2.5.8 criteria are new in WCAG 2.2. ### Does the European Accessibility Act apply to cookie banners? Yes, for services it covers, including e-commerce, banking, and transport. The EAA has applied since June 28, 2025, and works through EN 301 549, which follows WCAG 2.1 Level AA. Meeting WCAG 2.2 AA also meets 2.1 AA. ### Can an inaccessible banner invalidate consent? Yes. Under GDPR Article 7, consent must be freely given, specific, informed, and unambiguous. A visitor who cannot operate the banner cannot meaningfully give or withdraw consent, so the consent collected through it may not be valid.