The Cart Drawer Trap: The Close Button Keyboard Users Cannot Reach

A shopper adds an item to the cart, the drawer slides in from the side, and the keyboard user is stuck. The drawer is open on screen, but focus never moved into it, the close button has no accessible name, and the only way out is to tab through the entire page behind it. The drawer is a trap, and it is the most common one in ecommerce.

The drawer opens, the keyboard stays behind

A cart drawer is a modal. When it opens, focus should move into it, stay inside it while it is open, and return to the trigger when it closes. That is the pattern, and it is documented in the WAI-ARIA practices guide. Most drawers do none of it. Focus stays on the add-to-cart button behind the drawer, the shopper tabs forward into the page behind the overlay, and the drawer is invisible to the keyboard while being visible on screen.

The result is a shopper who can see the cart and cannot use it. They tab through the header, the navigation, the footer, and the whole page behind the drawer before they reach the close button, if they reach it at all. Some give up and leave. Some press Escape, which closes nothing, because the drawer never listened for it. The sale is lost before the shopper ever sees the checkout.

The close button with no name is the same failure one step further in: a button that exists visually and means nothing to a screen reader. The drawer trap and the nameless button are the same bug at different depths, and they ship together more often than not.

The close button that has no name

Open your cart drawer and inspect the close button. If it is an X made of text or an SVG with no accessible name, a screen reader announces it as button, with nothing after it. The shopper has no idea what it does. WCAG 4.1.2 requires every user interface component to have a name, and a close button with no name fails it outright. The fix is one attribute: aria-label set to Close cart.

The name is the easy part. The hard part is the focus trap. When the drawer opens, move focus to the close button or the drawer heading. While the drawer is open, keep Tab cycling inside it: from the last element back to the first, never out into the page behind. When the drawer closes, return focus to the element that opened it. That is the whole pattern, and it is about twenty lines of code.

Test it the way the focus-after-removal test works: open the drawer, remove an item, and check where focus goes. If it vanishes to the top of the page, the drawer is broken. If it lands on the next item or the close button, the pattern holds. The guest checkout keyboard flow is the same discipline carried one step further, into the checkout itself.

The pattern that works, and the test that catches it

The working pattern has four parts: focus moves in on open, Tab cycles inside while open, Escape closes it, focus returns to the trigger on close. Any drawer missing one of the four is broken, and the missing piece is usually the trap. Developers implement the open and the close and skip the trap, because the trap is invisible to mouse users.

The test takes two minutes. Open the drawer with the keyboard, press Tab until you reach the end, and press Tab once more. If focus leaves the drawer, the trap is missing. Press Escape. If the drawer stays open, the Escape handler is missing. Close it and check where focus lands. If it is not on the element that opened the drawer, the return is missing. Four checks, two minutes, and you will find the bug in most stores you test.

Frequently asked questions

What is a focus trap, and why does a cart drawer need one?

A focus trap keeps Tab cycling inside the drawer while it is open, so keyboard users cannot tab out into the page behind it. Without it, the shopper tabs through the whole page behind the overlay before reaching the close button, and many give up and leave.

Why does my cart close button fail accessibility testing?

It probably has no accessible name. An X made of text or an SVG with no label is announced as button with nothing after it. Add aria-label set to Close cart, and the button passes WCAG 4.1.2.

Should Escape close a cart drawer?

Yes. Escape is the expected way to dismiss a modal, and the WAI-ARIA practices guide lists it as part of the dialog pattern. A drawer that ignores Escape traps keyboard users who have no other way out.

Where should focus go when the drawer closes?

Back to the element that opened it, usually the add-to-cart button or the cart icon. If focus lands at the top of the page instead, the shopper has lost their place and has to navigate back to where they were.