Mobile accessibility for ecommerce: touch targets, gestures and responsive design

Mobile devices account for over 70% of ecommerce traffic in most markets. Yet mobile accessibility is often an afterthought in accessibility audits, which tend to focus on desktop keyboard navigation. This is a mistake: the populations most likely to use mobile devices as their primary internet access point, including low-income users and users in developing markets, are also disproportionately likely to rely on built-in accessibility features.

According to Apple, approximately 1 in 6 iPhone users has at least one accessibility feature enabled. Mobile screen reader usage (VoiceOver on iOS, TalkBack on Android) is significant: WebAIM's 2024 screen reader survey found that 27% of respondents primarily use a mobile screen reader. For ecommerce compliance, mobile is not optional. The same WCAG 2.1 AA requirements that apply to desktop apply to mobile.

WCAG 2.5 input modalities: what the criteria actually require

WCAG 2.1 added a new success criterion category: 2.5 Input Modalities. These criteria specifically address non-keyboard input methods, including touch, voice, switch access and pointer devices. For mobile ecommerce, the most important criteria are:

• 2.5.1 Pointer Gestures (Level A). Any functionality that uses a multipoint gesture (pinch, two-finger swipe) or path-based gesture (swipe in a specific direction) must have a single-pointer alternative. If your product image gallery requires a horizontal swipe gesture to advance, there must also be tap-accessible previous/next buttons.
• 2.5.3 Label in Name (Level A). For interactive components with visible text labels, the accessible name of the component must contain the visible text. A button that visually says "Add to Cart" must have an accessible name that includes "Add to Cart", not just "Button" or an icon description.
• 2.5.4 Motion Actuation (Level A). If functionality can be triggered by device motion (shaking the device to undo, tilting to scroll), an alternative must be available and users must be able to disable the motion trigger.
• 2.5.5 Target Size (Level AAA). Touch targets should be at least 44x44 CSS pixels. Note: this is Level AAA, so it is aspirational rather than strictly required for AA compliance. However, WCAG 2.2 introduced 2.5.8 Target Size (Minimum) at Level AA, requiring 24x24 CSS pixels with adequate spacing.
• 2.5.8 Target Size Minimum (Level AA, WCAG 2.2). Interactive targets must be at least 24x24 CSS pixels, or have sufficient spacing from adjacent targets such that a 24px circle centered on the target does not intersect another target or the page edge.

What is the minimum touch target size for ecommerce?

This is the most frequently asked mobile accessibility question. The answer depends on which version of WCAG you are targeting.

Under WCAG 2.1 AA: there is no strict minimum target size at Level AA. The 44x44px requirement is Level AAA (2.5.5). However, Apple's Human Interface Guidelines recommend 44x44pt and Google's Material Design recommends 48x48dp for all touch targets. Failure to meet these guidelines does not directly violate WCAG 2.1 AA but may indicate poor user experience that contributes to other failures.

Under WCAG 2.2 AA: 2.5.8 requires 24x24 CSS pixels minimum, with exceptions for inline text links, native UI controls the browser handles, and content where the target size is "essential" (such as handwriting input). EU EAA compliance requires WCAG 2.1 AA. US ADA compliance is more complex but courts have generally looked to WCAG 2.1 AA as the standard.

For practical ecommerce guidance: aim for 44x44px for all primary interactive elements (buttons, links, form controls). This exceeds both requirements and reduces user frustration on small screens. The most commonly undersized elements are:

• Quantity increment and decrement buttons next to the quantity input
• Remove item buttons in the cart (often rendered as small "X" icons)
• Color and size swatch buttons on product pages
• Filter option checkboxes in the filter panel
• Social sharing buttons in the product page footer
• Close buttons on modal dialogs and off-canvas menus

Gesture alternatives in ecommerce interfaces

WCAG 2.5.1 requires single-pointer alternatives for multipoint or path-based gestures. In ecommerce, the most common gesture-dependent features are:

Product image swipe galleries

Most ecommerce product pages use swipeable image galleries. The swipe gesture is a path-based gesture and requires an alternative. The alternative must be operable via a single tap: previous and next arrow buttons that are touch targets of sufficient size. These buttons are often present but hidden or styled so small they are effectively unusable on mobile.

Implementation note: the arrow buttons should remain visible (or become visible on focus) even when a swipe gesture is available. Do not hide them only for mobile viewports.

Price range sliders

Custom price range sliders in filter panels use a drag gesture. Drag is a path-based gesture. The alternative: number input fields (min price, max price) that accept typed values. These fields are often present on desktop but removed on mobile to save space. This is a WCAG failure on mobile: the alternative must be available on mobile too.

Drag-to-reorder

Some cart implementations allow drag-to-reorder of cart items. Drag requires an alternative: up/down move controls or a separate reorder mechanism. This is rare in ecommerce carts but appears in some subscription management flows.

Mobile screen readers: VoiceOver and TalkBack

VoiceOver is Apple's built-in screen reader for iOS. TalkBack is Google's screen reader for Android. They behave differently from desktop screen readers and from each other.

How VoiceOver (iOS) works on ecommerce stores

VoiceOver users navigate by swiping right (next item) and left (previous item) to move through focusable elements. They double-tap to activate a selected element. They use a two-finger scrub (Z gesture) to go back. The rotor (two-finger rotation) provides quick navigation by headings, links, form controls or other element types.

Critical behaviors to test on iOS VoiceOver: Can a user navigate from the homepage to a product page using only right/left swipes and double-taps? Can they select a variant and add the product to the cart? Can they navigate to checkout and complete the address form? The swipe navigation model is different from keyboard Tab navigation. Elements that are keyboard accessible are generally VoiceOver accessible, but the reverse is not always true.

How TalkBack (Android) works on ecommerce stores

TalkBack uses similar swipe navigation. Its behavior with web content differs from VoiceOver in some areas. Notably, TalkBack's handling of custom ARIA components (custom select dropdowns, custom radio buttons) can differ from VoiceOver's behavior. An element that works correctly on VoiceOver may not work on TalkBack.

Test on both if you can. If you can only test one, test VoiceOver first (iOS has a higher share of mobile accessibility users per WebAIM surveys) but document that you have not tested TalkBack.

Responsive design breakpoints and accessibility

Responsive design creates accessibility risks that desktop-only testing misses.

Navigation patterns that change between breakpoints

The most common pattern: a multi-level navigation menu on desktop becomes a hamburger menu with an off-canvas drawer on mobile. The desktop version may have been tested for keyboard accessibility; the mobile off-canvas version may not have been. The mobile drawer must also have correct focus management (focus moves into the drawer when it opens, focus is trapped within the drawer, focus returns to the hamburger button when the drawer closes).

Hidden content at different breakpoints

Content hidden with display: none at mobile breakpoints is correctly hidden from assistive technologies. Content hidden with visibility: hidden or opacity: 0 combined with pointer-events: none may still be accessible to screen readers depending on implementation. Audit your responsive CSS for content that should be hidden but is not properly hidden from assistive technologies.

Conversely, content added only for mobile (simplified layouts, mobile-specific CTAs) must also be accessible. A "Buy now" button that only exists on mobile must be keyboard accessible and have a proper accessible name.

Pinch-to-zoom requirements

WCAG 1.4.4 (Resize Text, Level AA) requires that text can be resized up to 200% without loss of content or functionality. For mobile browsers, this is closely related to the viewport meta tag configuration.

The failure: setting user-scalable=no or maximum-scale=1 in your viewport meta tag. This disables pinch-to-zoom on iOS Safari and most Android browsers, preventing users from enlarging text and content. Users with low vision rely on pinch-to-zoom to read content.

The fix: remove user-scalable=no and maximum-scale=1 from your viewport meta tag. The correct viewport declaration is:

<meta name="viewport" content="width=device-width, initial-scale=1">

Note: iOS 10 and later ignore user-scalable=no in Safari. But it remains a WCAG failure regardless of whether browsers enforce it, and some Android browsers and WebViews still respect it.

Orientation lock issues

WCAG 1.3.4 (Orientation, Level AA, added in WCAG 2.1) requires that content does not restrict viewing to a single screen orientation (portrait or landscape) unless the orientation is essential.

Some ecommerce implementations lock mobile layouts to portrait orientation via CSS or JavaScript (screen.orientation.lock('portrait')). Users with devices mounted in a fixed orientation (some wheelchair users mount tablets horizontally) are blocked by orientation lock.

The fix: remove orientation locks. If a specific feature genuinely requires a specific orientation (a side-by-side comparison view), provide an orientation-agnostic alternative.

Mobile checkout flow accessibility failures

Mobile checkout is where mobile accessibility failures have the most direct business impact. Common failures:

• Input type mismatches. Address fields that use type="text" instead of appropriate types (type="email", type="tel", type="number") do not trigger the appropriate mobile keyboard. A phone number field with a text keyboard makes entry slower and harder, particularly for users with motor impairments. Use inputmode attributes (inputmode="numeric", inputmode="email") to control keyboard type.
• Autocomplete attributes missing. (See our guide on accessible forms for ecommerce for the full list of required values.) WCAG 1.3.5 (Identify Input Purpose, Level AA) requires that form inputs collecting user data that can be auto-filled (name, email, address, payment information) have appropriate autocomplete attribute values. On mobile, autofill is particularly valuable because typing long form entries on a mobile keyboard is slow and error-prone.
• Touch target size in form controls. Checkbox and radio button inputs in checkout forms are often styled to be smaller than 44x44px. The label associated with the input should be made interactive to increase the effective touch area.
• Error message placement. On desktop, form error messages typically appear below the field. On mobile, when the keyboard is open, the screen shows only the top portion of the form. An error message below the visible area may not be seen. Consider inline error messages that appear adjacent to the field label (above the input) or ensure focus moves to the first error and the error is announced via role="alert".

Mobile-specific WCAG failures most commonly found in ecommerce

In Complyko's scan data from 382 ecommerce stores, mobile-specific failures that appear frequently:

• Viewport meta tags with user-scalable=no: present on approximately 18% of scanned stores.
• Touch targets smaller than 24x24px: present on 74% of scanned stores, concentrated in filter panels, cart quantity controls and social share buttons.
• Missing input type and autocomplete attributes on checkout forms: present on 61% of scanned stores with accessible checkout pages.
• Swipe-only product gallery with no button alternative: present on 41% of stores with mobile-specific gallery implementations.

Frequently asked questions

What is the minimum touch target size for WCAG compliance?

WCAG 2.2 (Level AA criterion 2.5.8) requires 24x24 CSS pixels minimum. Apple recommends 44x44pt and Google recommends 48x48dp. Aim for 44x44px for all primary interactive elements including add-to-cart buttons, quantity controls and filter options.

Does disabling pinch-to-zoom violate WCAG?

Yes. Setting user-scalable=no or maximum-scale=1 in the viewport meta tag violates WCAG 1.4.4. Users with low vision rely on pinch-to-zoom. The correct viewport tag: <meta name="viewport" content="width=device-width, initial-scale=1">.

Do swipe gestures need alternatives for accessibility?

Yes. WCAG 2.5.1 requires that any functionality using multipoint or path-based gestures (like swiping through a product gallery) must have a single-pointer alternative like tap-accessible previous and next buttons.

How do you test mobile ecommerce accessibility with VoiceOver?

Enable VoiceOver (Settings > Accessibility > VoiceOver). Swipe right/left to navigate, double-tap to activate. Test the complete purchase flow: browse products, select variants, add to cart, complete checkout. Check all buttons have meaningful ARIA labels.

How do you test with TalkBack on Android?

Enable TalkBack (Settings > Accessibility > TalkBack). Same swipe/double-tap navigation. TalkBack handles custom ARIA components differently from VoiceOver. If you can only test one, test VoiceOver first (higher share of mobile accessibility users), then TalkBack.

What percentage of ecommerce traffic is mobile?

Over 70% in most markets. 27% of screen reader users primarily use mobile (WebAIM 2024). 1 in 6 iPhone users has at least one accessibility feature enabled. Mobile accessibility is not optional.

What are the most common mobile accessibility failures?

Touch targets under 24px (74% of stores), missing autocomplete attributes on checkout forms (61%), viewport disabling zoom (18%), swipe-only galleries without buttons (41%) and orientation lock.

Does orientation lock violate WCAG?

Yes. WCAG 1.3.4 (Orientation, Level AA) requires content not be restricted to a single orientation. Some users mount devices in fixed positions. Remove screen.orientation.lock() and CSS orientation restrictions.

What mobile keyboard should checkout fields trigger?

Use type="email" for email, type="tel" for phone, inputmode="numeric" for ZIP/postal code, and autocomplete attributes for all address fields. Wrong keyboard types slow entry and frustrate users with motor impairments.

Are mobile WCAG requirements different from desktop?

No. The same WCAG 2.1 AA criteria apply. But mobile introduces additional failure points: touch target sizes, gesture alternatives, viewport zoom, orientation lock and mobile screen reader compatibility. Mobile-specific testing is essential.