Is your Shopify mobile menu accessible?
An accessible Shopify mobile menu uses a real button with an announced open and closed state, moves focus into the menu when it opens and back to the button when it closes, traps nothing and releases focus cleanly, supports keyboard operation for every submenu, and never depends on a hover or a swipe that assistive technology cannot perform.
The hamburger button nobody can name
The single most common mobile menu failure is a toggle that is not a button. Themes build the hamburger as a div with a click handler, or an icon with no accessible name at all. A screen reader user hears "clickable" or nothing, with no indication that opening it reveals the entire site navigation. The fix is a real button element with an accessible name like "Menu" and an expanded state that flips when the menu opens and closes. That one change makes the control discoverable and its state announced, which is half the battle.
The other half is what happens after the menu opens. The state change must be announced, either through the button's expanded attribute or a live region, so the user knows navigation is now available. We see menus where the drawer slides open visually while the screen reader user sits on a page that appears unchanged. If the state change is not announced, the menu does not exist for them.
Focus that goes nowhere
When the menu opens, focus should move to the first menu item or the menu container. When it closes, focus should return to the menu button. Almost no Shopify theme does both out of the box. The usual failure is worse: focus stays behind the overlay on the page content, so keyboard users tab through invisible content while the open menu sits in front of them, or closing the menu dumps focus at the top of the document and the user has to re-navigate the entire page.
Focus trapping deserves care here. While the menu is open, tabbing should cycle within the menu rather than leaking to the background page. But the trap must release cleanly: Escape closes the menu and returns focus to the button, and the close control itself must be reachable by keyboard. A trap with no working exit is a WCAG failure and a rage-quit for real users.
Submenus built for a mouse
Mobile menus almost always include expandable submenus for collections and product categories, and these are where hover-dependent designs fall apart. A chevron that expands on hover works for a mouse and fails for everyone else. Each submenu toggle must be its own keyboard-operable button with an expanded state, and the arrow keys should move between items when the submenu is open. Enter and Space activate, Escape collapses back up one level.
Test this with nothing but a keyboard and you will find the failures fast. If you cannot reach every link in the navigation without a mouse, neither can a keyboard user, and neither can most screen reader users, who navigate menus in forms mode. On Shopify themes we audit, submenu keyboard support is the single most frequently broken menu behavior.
The invisible overlay problems
Two more failures hide behind the visual design. First, background content must be inert while the menu is open. If a screen reader user can still navigate the page behind the overlay, they will get lost in content that is visually hidden, and their checkout CTA may be reachable but unclickable, which is worse than unreachable. Second, touch targets: menu links and submenu toggles need to be large enough to activate reliably, and the close control cannot be a tiny X in the corner that nobody with a motor impairment can hit.
Then there is the search field many themes bury inside the mobile menu. If the search input lacks a label, has no submit mechanism for keyboard users, or announces results in a container that steals focus mid-typing, it inherits every failure of the menu plus its own. Treat embedded search as its own component and test it separately.
How to test your mobile menu
Test in this order. First, keyboard only: open the menu, reach every link, expand every submenu, close with Escape, and confirm focus returns to the button. Second, with a screen reader: confirm the button is announced as a menu toggle with its state, confirm the state change is announced, and confirm focus movement is announced. Third, on a real phone with zoom at 200 percent: confirm nothing overlaps, the close control stays reachable, and no link requires horizontal scrolling.
The mobile menu is the front door of your store for most shoppers, and for shoppers using assistive technology it is often the only door. When it fails, they do not see a broken menu; they see a store with no navigation at all. Audit it like the money page it is.