How should a Shopify store test accessibility on a mobile device?

Most accessibility testing happens on a desktop browser, but most shoppers are on phones. A mobile accessibility pass checks touch targets, zoom, focus, and the checkout flow where mobile shoppers actually convert.

Most testing happens where most shoppers are not

Accessibility testing usually happens on a desktop: a big monitor, a full keyboard, a mouse nearby. That is a fine setup for catching a large class of issues. It is also, increasingly, not where the shopping happens. Mobile traffic dominates most Shopify stores, and the mobile experience is a different product with different barriers. A store that tests only on desktop is auditing the minority experience.

Mobile accessibility testing does not require a device lab or exotic tooling. It requires a phone, a plan, and attention to the handful of mobile-specific barriers that desktop testing never encounters.

Touch targets: the mobile barrier nobody measures

The single most common mobile accessibility failure is undersized touch targets. Links and buttons crammed into dense grids, close buttons the size of a pinhead, quantity steppers that demand surgical precision. Anyone can struggle with these; for shoppers with motor impairments, tremors, or low vision, they are hard stops.

The practical bar is 44 by 44 pixels at minimum, with spacing between adjacent targets. Walk the store's key flows on a real phone and tap everything with your thumb, not a stylus. The product card actions, the filter chips, the menu toggles, the checkout buttons. If you have to aim, it fails. This check takes twenty minutes and finds issues no automated scan will catch, because scanners see the DOM, not the rendered size.

Zoom and text resize must survive the layout

Many mobile themes disable pinch zoom to make the site feel app-like. That single line of code locks out every shopper who needs magnification. Re-enable zoom, then test the store at 200 percent text size. The layout should reflow, not break: no text clipped inside fixed-height buttons, no overlapping columns, no horizontal scrolling traps.

Pay special attention to the components themes love to fix in place: sticky add-to-cart bars, cookie banners, announcement bars. Fixed elements are where zoomed layouts go to die, stacking on top of the content they were meant to accompany. Scroll every key page at maximum zoom and confirm the content stays reachable.

Focus order on mobile drawers and menus

Mobile navigation lives in drawers, modals, and slide-outs, and these are where focus management fails most visibly. Open the mobile menu with a keyboard or switch device and tab through it. Focus should enter the drawer when it opens, stay trapped inside while it is open, and return to the trigger when it closes.

The classic failures: focus stays behind the overlay on the page content, the close button is unreachable by keyboard, or the drawer announces nothing when it opens and the screen reader user has no idea it appeared. Test every overlay component the same way: menu, search, cart drawer, filters, size guides, quick view. They share code patterns, so one broken pattern usually means five broken components.

Test the checkout one-handed

The checkout is where mobile accessibility converts directly to revenue. Run a complete test purchase on a phone using only one thumb and no mouse-like precision. Every form field needs a visible label, error messages must be announced and associated with their fields, and the order summary must be reachable without horizontal gymnastics.

Watch for the mobile checkout specifics: payment method selectors that are actually radio groups in disguise, address autocomplete dropdowns that swallow keyboard focus, and express payment buttons that appear and disappear based on device detection. Each of these is a known trap. Each is testable in one pass.

Run a screen reader on the phone itself

Desktop screen reader testing does not cover mobile. VoiceOver on iOS and TalkBack on Android behave differently from their desktop cousins: different gestures, different rotor and navigation models, different quirks with web views. A component that announces perfectly in a desktop browser can be silent or scrambled on a phone.

You do not need to become an expert in both. Learn the basics of one, test the money path (home, product, cart, checkout) on it, and note anything that announces oddly. The goal is not certification. It is catching the egregious failures: unlabeled buttons, silent dynamic updates, focus that jumps to nowhere.

Cover devices without owning a lab

Test on at least one iPhone and one Android device, at two viewport sizes: a standard phone and a small one. The small viewport is where layouts break, and the Android device is where TalkBack quirks surface. Borrow devices, use a cloud device farm for a quarterly pass, or rotate through the team's personal phones.

The cadence matters more than the coverage. A monthly mobile pass on two devices catches regressions while they are cheap. An annual lab session with twenty devices produces a report nobody reads. Pick the rhythm you will actually keep, and make the mobile pass part of the same routine as the desktop one.