Making Your Shopify Cart Drawer Keyboard Accessible

The slide-out cart is where keyboard users get stuck most. The exact fixes: focus management, escape to close, and a logical tab order.

The slide-out cart drawer is one of the most common components on Shopify storefronts, and one of the least accessible. It behaves like a modal dialog, sliding over the page and demanding attention, but most implementations skip the keyboard behaviors that make modals usable. Keyboard users open the drawer and then cannot reach its contents, cannot close it, or lose their place on the page entirely. The fixes are well understood and take less than a day to implement. Here is exactly what to do.

Move focus into the drawer when it opens

The single most common failure: the drawer opens visually, but keyboard focus stays behind on the page. A keyboard user tabs forward and lands on page content hidden behind the overlay, with no idea the cart is open. The fix is one line of intent: when the drawer opens, move focus to the first focusable element inside it, usually the close button or the drawer heading. Test it by opening the drawer and pressing Tab. If the next stop is inside the drawer, the fix worked. If it is somewhere on the darkened page behind, it did not.

Keep focus inside while it is open

Once focus is in the drawer, it should stay there until the drawer closes. Without a focus trap, tabbing past the last element in the drawer sends focus wandering across the obscured page, which is disorienting for sighted keyboard users and chaotic for screen reader users. Implement a trap: when focus would leave the last element, cycle it back to the first, and vice versa. Small utility functions for this are widely available, and the logic is only a few lines. This is also where many custom drawers fail automated checks, so fixing it clears both the manual and the automated findings.

Escape closes it, and focus goes home

Every drawer needs a keyboard path out. The Escape key should close the drawer, and so should the visible close button, which must itself be a real button with an accessible name, not a clickable div. When the drawer closes, return focus to the element that opened it, typically the add-to-cart button or the cart icon. This last step is the one teams forget: without it, the keyboard user closes the drawer and lands at the top of the page, forced to tab all the way back to where they were. Returning focus is what makes the interaction feel complete.

Announce the drawer to screen readers

Keyboard support and screen reader support overlap but are not the same. Give the drawer the dialog role and an accessible name, usually via aria-labelledby pointing at its heading, so screen reader users hear "Shopping cart dialog" instead of stumbling into unexplained content. When the drawer opens, the announcement plus the focus move tells the user exactly what happened. When it closes, the focus return tells them it is over. Also check the cart count badge: if it updates visually when items are added, make sure the update is announced politely rather than interrupting the shopper mid-task.

The two-minute test

You can verify all of this without a screen reader. Open the drawer with the keyboard, then Tab through every element and confirm you never leave the drawer. Press Escape and confirm it closes and focus returns to the trigger. Turn on your operating system's screen reader for sixty seconds and confirm the drawer announces itself. Run this test on every theme update that touches the cart templates. Two minutes per release is the cheapest accessibility insurance a Shopify store can buy.

Frequently asked questions

What is the most common cart drawer accessibility failure?

Focus not moving into the drawer when it opens. The drawer appears visually, but keyboard focus stays on the page behind it, so keyboard users cannot reach the cart contents at all. It is also the easiest to fix: move focus to the drawer's first focusable element on open.

Do we need a JavaScript library for the focus trap?

No. A focus trap is a small amount of custom code: listen for Tab key presses, and when focus is on the last element, move it to the first, and vice versa. Many themes already include utility code you can reuse. The important thing is testing it, not the implementation source.

Should we use a cart drawer or a cart page?

From an accessibility standpoint, a full cart page is simpler: it is just a page, with none of the focus management a drawer requires. But drawers convert better for many stores, so the practical answer is usually to keep the drawer and implement it correctly. An accessible drawer beats an inaccessible one; a cart page beats both on simplicity.

How do we test this without assistive technology expertise?

The keyboard-only pass covers most of it: Tab through the drawer, confirm focus stays inside, press Escape, confirm focus returns. For screen reader behavior, both major operating systems include a free screen reader, and sixty seconds of listening confirms whether the drawer announces itself properly. You do not need expertise to catch the big failures.