When the Cart Drawer Closes, Focus Has to Go Somewhere

Open the cart drawer with a keyboard, add nothing, close it with Escape, and watch where you land. On a surprising number of otherwise polished stores, you land nowhere visible. Focus has reset to the body, the next Tab press starts again from the first link on the page, and the shopper gets to re navigate the header for the privilege of continuing to shop.

The drawer opened correctly. Focus moved in, items were reachable, quantities could be changed. Then the close action threw away the user's position, quietly, on the single most used component in the store.

The standard is about order, not decoration

WCAG 2.1 Success Criterion 2.4.3 requires that focusable elements receive focus in an order that preserves meaning and operability. A focus reset on drawer close breaks that order in a way a shopper feels immediately and an automated scan rarely flags, because the scan checks that elements are focusable, not where focus goes after a component closes.

Criterion 2.4.7 Focus Visible compounds the problem. After a reset, there is often no visible focus indicator at all until the user tabs several times. The shopper does not know whether the keyboard stopped working, the drawer broke something, or the page reloaded. All three guesses erode trust in the checkout that follows.

Return focus to the opener, every close path

The rule is consistent across close methods. Escape key, close button, clicking the overlay, and completing an action inside the drawer should all return focus to the element that opened the drawer, or to a logical successor if that element no longer exists. If the shopper opened the drawer from a cart icon in the header, that icon is where they should land.

Edge cases deserve decisions, not accidents. If the drawer was opened automatically after adding an item, focus return should go to a sensible place in that flow, often the added confirmation or back to the add button context. Whatever the choice, it should be deliberate, documented, and the same for keyboard, switch and screen reader users.

Trap while open, release on close

While the drawer is open, focus should be contained within it, so Tab cycles through drawer controls instead of wandering into the page behind. On close, that trap must release cleanly. A drawer that traps well and releases badly is a common pattern, because the trap gets tested in development and the release path, especially Escape, gets tested by nobody.

Screen readers add a second layer. The drawer should be announced as a dialog, with an accessible name, and on close the return of focus should reorient the user. Test with an actual screen reader, not just keyboard sighted testing, because a focus position that looks right visually can still leave a screen reader user in a virtual cursor position that makes no sense.

A five minute test you can run today

Keyboard only: tab to the cart control, open, tab through the drawer, close with Escape, and press Tab once. If you are not back near the cart control, the test has failed. Repeat closing with the close button and by activating the overlay with Enter or Space where it is operable. Three close paths, three chances to lose the user.

Log the result as a cart defect, not a general accessibility note. Focus loss on the cart drawer affects the highest intent component on the site, and it should be prioritised like a broken checkout button, because for keyboard users that is functionally what it is.

Frequently asked questions

Where should focus go when a cart drawer closes?

Back to the control that opened it, most often the cart button or icon in the header, so the shopper resumes from where they left off. If that control no longer exists, focus should move to a logical successor. It should never silently reset to the top of the document.

Does losing focus on close fail WCAG?

It undermines WCAG 2.1 Success Criterion 2.4.3 Focus Order, because the navigation sequence no longer preserves operability, and it can also affect 2.4.7 Focus Visible when no focus indicator is shown after the reset. Automated scans rarely catch it, which is why manual keyboard testing matters for drawers and dialogs.

Should a cart drawer trap focus while open?

Yes. While the modal drawer is open, Tab should cycle within it, and the underlying page should be inert to keyboard navigation. On close, the trap must release and focus must return to the opener. Both halves need testing, including the Escape key path.

How do I test cart drawer focus quickly?

Use only a keyboard. Open the drawer, tab through it, and close it three ways: Escape, the close button, and any overlay action. After each close, check that focus is visibly back at the opener. Then repeat with a screen reader to confirm the dialog is announced and the return makes sense non visually.