Mini cart keyboard traps: the focus test that catches them

Add a product to the cart, and a drawer slides in from the right. A mouse user clicks the X and moves on. A keyboard user presses Tab and the focus goes somewhere behind the drawer, into the page underneath, where it cannot be seen and cannot be reached. Pressing Tab again moves it further into the hidden page. The only way out is to reload, or to guess where the close button is. That is a keyboard trap, and it fails WCAG 2.2 Success Criterion 2.1.2, No Keyboard Trap, which is Level A.

The trap happens because the drawer is a visual layer, not a focus layer. The developer showed the drawer and forgot to move focus into it, trap focus inside it while it is open, and return focus to the trigger when it closes. Three steps, all documented, all skipped. The result is a cart that works for the people who can see it and fails for the people who cannot, which is the definition of an accessibility failure that also loses sales.

The test takes ninety seconds

Put the mouse away. Add a product, and press Tab. Focus should land inside the drawer, on the close button or the first control. Keep pressing Tab. Focus should cycle through the drawer's controls and come back to the start, never leaving the drawer while it is open. Press Escape. The drawer should close and focus should return to the button that opened it. If focus goes anywhere else at any point, the drawer is broken, and the fix is a focus trap, not a redesign.

Test the quantity steppers inside the drawer while you are there. Each stepper needs an accessible name that includes the product, per 4.1.2 Name Role Value, and a target size of at least 24 by 24 CSS pixels under 2.5.8. A drawer full of tiny unnamed plus and minus buttons is a second failure stacked on the first, and it is the one screen reader users hit immediately after the trap is fixed.

Why drawers trap focus in the first place

Drawers trap focus because they are built as an afterthought on top of a page that already works. The page's tab order is fine. The drawer is a new layer with its own controls, and nobody updated the tab order to include it. The fix is to treat the drawer as a modal dialog: give it role dialog, move focus in on open, trap focus while open, return focus on close. That is the same pattern as every accessible modal, and it is the pattern the drawer should have used from the start.

There is a temptation to fix this with an overlay widget that promises instant compliance. That promise is the problem, not the solution. An overlay cannot fix a focus order it does not control, and it adds its own controls to a page that already has too many. The honest fix is in the code, and it is a small one.

What good looks like

A good mini cart opens, takes focus, lets the shopper adjust quantities and remove items by keyboard alone, and closes with Escape, returning focus to the add to cart button. The whole interaction takes seconds for a keyboard user and seconds for a mouse user, which is the point: the same cart, the same speed, for everyone. Run the ninety second test on your own cart this week. If focus escapes, fix the trap before you fix anything else, because a shopper who cannot leave the cart cannot check out.

Keep reading: Accessible shipping radio groups in the cart, Accessible cart drawer focus traps and keyboard testing.

Frequently asked questions

What is a keyboard trap in a mini cart?

Focus enters the cart drawer and cannot leave by keyboard alone, or it leaves into the hidden page behind the drawer. WCAG 2.1.2 requires that focus can always be moved away from a component using only the keyboard.

How do I test a mini cart for keyboard traps?

Put the mouse away, add a product, and press Tab. Focus should enter the drawer, cycle through its controls, and never go behind it. Press Escape: the drawer should close and focus should return to the button that opened it.

What does the fix look like in code?

Treat the drawer as a modal dialog: role dialog, move focus in on open, trap focus inside while open, return focus to the trigger on close. That is the standard modal pattern, applied to the drawer.

Do overlay widgets fix keyboard traps?

No. An overlay cannot fix a focus order it does not control, and it adds its own controls to the page. The fix belongs in the drawer code, and it is a small change, not a product purchase.