Cart Drawer Focus: Where Focus Goes When the Drawer Opens and Closes
The slide in cart drawer is now the default on a large share of stores, and it is a focus trap in both senses when it is built carelessly. A shopper adds an item, the drawer opens visually, but keyboard focus stays on the add button behind it. They press Tab and walk through the page underneath a drawer they can see but cannot reach. Or the drawer is built to grab focus, traps it correctly, and then, on close, drops it at the top of the document, so a keyboard user starts the page again from the first link. Neither failure throws an error. Both lose sales.
WCAG 2.1 Success Criterion 2.4.3, Focus Order, requires that focusable elements receive focus in an order that preserves meaning and operability. A drawer that is visually in front but last in the focus order breaks that order in the plainest way. Criterion 2.4.7, Focus Visible, matters here too: inside a drawer with a dark overlay behind it, a faint default outline is easily lost, and a user who cannot see where focus is cannot use the drawer at all.
Opening: move focus in, and say why
When the drawer opens, move focus to the drawer's heading or its close button, and give the drawer a proper dialog role with an accessible name, so a screen reader announces something like shopping cart, dialog, instead of silence followed by a stray button. The announcement matters because the drawer opened in response to an action, adding an item, and a screen reader user needs the confirmation that the add worked. That confirmation is also a status message under Criterion 4.1.3: the item, its quantity, and the new subtotal should be available without hunting.
Trap focus inside while the drawer is open. Tab should cycle from the last control back to the first, and Escape should close the drawer, because that is the convention every desktop user already knows from operating system dialogs. A drawer that Escape cannot close, sitting on top of a page that Tab is still walking through, fails in two directions at once.
Closing: focus goes back to where it came from
On close, return focus to the element that opened the drawer, usually the add to cart button or the cart icon if the drawer was opened from the header. This is the step implementations skip, because visually nothing looks wrong: the drawer slides away and the mouse user carries on. For the keyboard user, focus returning to the document body means the next Tab press lands on the first link in the header, minutes of navigation away from the product they were looking at.
The same return rule applies when the drawer closes because the shopper emptied the cart or checked out. An emptied cart drawer that closes itself and strands focus leaves the user with a page that gives them no starting point. Put focus on the cart status message or back on the cart button, and announce that the cart is empty in text.
Test it the way it will be used
Add an item with the keyboard only. Confirm focus lands inside the drawer and the add is announced. Tab through every control and out the other side: you should cycle, not escape into the page. Close with Escape and confirm focus is back on the button you started from. It takes two minutes, it needs no tooling beyond a keyboard, and it catches every failure described here, because all of them are focus behaviour, and focus behaviour is exactly what visual testing never sees.
Related reading: Promo Code Entry in the Cart: Where Accessible Carts Still Fail, When a Cart Error Wipes the Form: An Accessibility Failure, Not a Nuisance, Cart Accessibility for Voice Control Users: Names Are the Interface.
Frequently asked questions
Where should focus go when a cart drawer opens?
Inside the drawer, to its heading or close button, with the drawer exposed as a named dialog so a screen reader announces it. Focus staying on the page behind the drawer breaks the focus order.
Should a cart drawer trap keyboard focus?
Yes, while it is open and covering the page. Tab should cycle within the drawer, and Escape should close it. A drawer that lets focus wander into the obscured page underneath is unusable by keyboard.
Where should focus go when the cart drawer closes?
Back to the control that opened it, usually the add to cart button or the cart icon. Dropping focus at the top of the document forces keyboard users to navigate the whole page again.
Which WCAG criteria cover cart drawers?
Focus order is 2.4.3, visible focus is 2.4.7, the dialog's name and role fall under 4.1.2, and announcing the added item and subtotal is a status message under 4.1.3.