Open your site right now in a private browser window. Not tomorrow, not after you finish reading. Right now, in a new tab.
Load the homepage. The moment that cookie banner appears, put your mouse down and don't touch it again. Press Tab once. Then again. Then again.
Watch where the little focus outline goes. Can you reach the Accept button? Can you reach Reject or Manage Preferences? And here is the question almost nobody asks: can you press Tab (or Shift+Tab) one more time after that and have focus leave the banner completely, landing back on your site's navigation or main content? If any of those answers is no, you likely just found a keyboard trap on your own website, and you found it in under sixty seconds.
The Stat: WCAG's 2.1.2 No Keyboard Trap requires that if keyboard focus can move into a component, it must also be able to move back out using only the keyboard. (Source: W3C WCAG 2.1.2)
Why This Tiny Test Catches Such a Big Problem
A keyboard trap is exactly what it sounds like. Focus wanders into a component and can't wander back out using only the keyboard. For someone using a mouse, this is invisible. They click Accept, the banner disappears, life goes on.
For someone who navigates entirely by keyboard, because of a motor disability, a repetitive strain injury, low vision paired with a screen reader, or simply a broken trackpad, that banner can become the only thing they can interact with on your entire site. Every Tab press cycles them back through the same two or three buttons. Shift+Tab does the same thing in reverse. The homepage they came to read, the product they wanted to buy, the article they clicked a link to find, all of it sits one focus-move away and permanently out of reach.
This is precisely the failure that WCAG 2.1.2 No Keyboard Trap exists to prevent. It's a Level A success criterion, which means it sits in the baseline tier of WCAG conformance, the tier that's assumed as a minimum in most accessibility policies and legal standards referencing WCAG. A cookie banner that traps focus isn't a minor polish issue. It's a baseline failure sitting on top of every single page of your site, because cookie banners typically render on every page, every session, before anyone can do anything else.
We've written before about how this bug tends to happen in the first place, in our piece on the cookie consent banner that's secretly a keyboard trap. That article digs into the why: how consent management platforms build modal-style banners, how developers wire up focus handling for mouse clicks and forget Tab order entirely, and how a banner can look perfectly normal while quietly cutting off keyboard navigation. This article skips the why. It's the test itself, the one you can run on your own site before you finish your coffee.
The 60-Second Test, Step by Step
Here's the full version of the test from the top of this article, expanded so you don't miss anything.
Step 1: Open a private or incognito window. This matters because your regular browser probably already remembers your consent choice, so the banner won't even show up. A fresh, unauthenticated session forces it to render exactly the way a new visitor experiences it.
Step 2: Load your homepage and don't touch your mouse. The second the banner appears, start pressing Tab. Watch the visible focus outline (the box or underline that shows which element is currently focused) as it moves from element to element.
Step 3: Count what you can reach. Can you land on Accept? Can you land on Reject, Decline, or Manage Preferences, if your banner offers those? Can you open and close a preferences panel using only Enter, Space, and Tab? Then, critically, can you press Tab one more time (or Shift+Tab from the first focusable element) and land somewhere outside the banner, such as your main navigation or the first heading on the page?
If focus keeps cycling through the same handful of elements no matter how many times you press Tab, and it never lands anywhere outside the banner, you've reproduced a keyboard trap. Try Shift+Tab too, in case the trap only exists in one direction. Some banners let you tab forward endlessly but never let you tab backward past the first button, which is still a fail under 2.1.2 because the criterion requires exit in the direction the user is trying to go.
What Counts as a Fail
To keep this concrete, here's what actually disqualifies a banner:
- Pressing Tab repeatedly never moves focus past the banner's own buttons and links.
- Shift+Tab from the first focusable element in the banner loops back to the last one instead of exiting.
- The Escape key closes the banner visually but focus doesn't move anywhere, leaving it stuck on a now-hidden element.
- A "Manage Preferences" panel opens but has its own internal trap, so you can get in but can't get back out to the main banner buttons.
- Accepting or rejecting cookies removes the banner from the page but focus isn't sent anywhere, so the next Tab press starts back at the very top of the page instead of continuing naturally.
That last one is a subtler variant. It's not technically a "trap" in the strictest sense, since focus does eventually reach the rest of the page, but it forces a keyboard user to tab through your entire header and navigation again, every single time, which is a real friction cost even if it isn't a hard 2.1.2 failure.
If It Failed, Here's Where to Look
Most keyboard traps in cookie banners trace back to one of two implementation choices.
The first is a focus trap library, often borrowed from a modal dialog pattern, applied to a banner that isn't actually a modal dialog. True modal dialogs are supposed to trap focus while they're open, that's correct behavior for a modal. The mistake is applying that same trap logic to a persistent banner without ever releasing it when the banner closes, or without giving it a genuine dismiss action that keyboard users can reach.
The second is a custom Tab key handler that intercepts keyboard events to control focus order manually, gets the last transition wrong, and sends focus back to itself instead of out to the page. This is common when a consent tool is a third-party embed and the site's own developers never tested it with a keyboard, only ever clicking through it with a mouse during setup.
WebAIM's guide to keyboard accessibility is a solid reference for how focus order and visible focus indicators are supposed to behave in general, and it's worth keeping open in a tab while you debug. If your consent tool is third-party, check whether the vendor has a documented fix or a configuration flag for focus management before you patch around it yourself, since an update on their end could undo a workaround on yours.
Once you've run the test and know where you stand, our free tools page has a quick way to check this and a handful of other common patterns across more of your site than just the homepage banner, without needing to manually Tab through every page by hand.
Run It Again After You Fix It
The test at the top of this article isn't a one-time thing. Run it again after any redesign, after any consent management platform update, and after any vendor pushes a new banner version to your site, because a passing test today doesn't guarantee a passing test after the next deploy.
If you want a second set of eyes on it, or you're not sure whether what you found counts as a genuine 2.1.2 failure or just an odd focus order, our team is easy to reach at experts@wcag.world. You can also head straight to our free tools to run a broader check today.