Cart drawers and focus: what a keyboard user actually hits on your store

Open your cart drawer and press Tab repeatedly. On a well built drawer, focus cycles through the drawer's own controls: close, quantity steppers, remove links, checkout. On a typical drawer, focus escapes after a few tabs and starts touring the page behind the overlay, through navigation and product links the user cannot see highlighted because the drawer covers them. The user is now operating an invisible page. That is a focus order failure, and it is the single most common drawer fault in store audits.

The fix is a focus trap while the drawer is open, standard practice in every mature component library, plus a visible focus indicator inside the drawer itself. Many themes style focus outlines away on the page and forget the drawer keeps the same reset, so even a trapped focus can be invisible. Test for the outline, not just the order.

The tab tour nobody designed

The drawer's icon buttons are the second fault line. A close button rendered as an X character or an SVG with no label announces as just button, or as nothing useful, in a screen reader. Quantity steppers labelled only with plus and minus symbols have the same problem: plus what, by how much, for which item. Each control needs an accessible name that includes the product: increase quantity, blue mug, is a name a user can act on. Plus is not.

Remove links fail the same way in long carts. Four identical remove links in a four item cart are indistinguishable in a screen reader's link list. The product name belongs in the accessible name even when the visible text stays short.

Buttons with no names

Closing the drawer should put focus back on the add to cart or view cart control that opened it. Sending focus to the top of the page instead forces a keyboard user to tab through the entire header and navigation to get back to where they were, dozens of keystrokes for a two second detour. Focus return is a small behaviour with an outsized cost when it is wrong, and it is the check most theme demos never show.

The return trip matters as much

Keep reading: Accessible Quantity Steppers in the Cart: The Buttons Nobody Labels, Accessible Gift Card Messages in the Cart: Balances People Can Actually Hear.

Frequently asked questions

Which WCAG criteria cover cart drawer focus?

Focus order (2.4.3), focus visible (2.4.7), and name role value (4.1.2) in WCAG 2.1 do most of the work, with no keyboard trap (2.1.2) covering the reverse failure. Level AA conformance, the usual legal benchmark for stores, includes all of them.

How can I test my cart drawer without a screen reader?

Use only the keyboard. Open the drawer, tab through it twice watching where the focus outline goes, press Escape, and note where focus lands. If focus leaves the drawer, vanishes, or returns to the top of the page, you have found faults a screen reader user hits daily.

Why do icon buttons need text I cannot see?

Because a screen reader announces a button by its accessible name, not its appearance. An X icon with no label is announced as button, which tells the user nothing. Visually hidden text or an aria label gives the control a name without changing how it looks.

Does a focus trap risk trapping keyboard users?

A correct trap cycles focus inside the open drawer and releases it the moment the drawer closes, with Escape always available. That is the opposite of the keyboard trap WCAG forbids, which is focus that cannot leave a component at all.