Mobile and Touch Accessibility

The plain-language idea

Mobile accessibility isn't just "the desktop rules, but smaller." Several things are genuinely specific to touch devices, not a smaller version of a desktop concern:

Mobile screen readers use different navigation gestures entirely. VoiceOver on iOS and TalkBack on Android don't use Tab and Enter — there's no physical keyboard. Instead, a user swipes left or right to move between elements one at a time, and double-taps anywhere on the screen to activate whatever currently has focus. A component tested only with a desktop screen reader and a keyboard hasn't actually been verified for mobile; the interaction model is different enough that desktop testing doesn't transfer automatically.

Touch targets need real size, and it's a different problem than desktop click targets. Commonly-cited accessible touch target guidance sits in roughly the 44-48px range (exact figures vary slightly by platform and guideline, so treat this as a general, well-established range rather than one precise universal number). This is a genuinely different problem from sizing something for a mouse: a fingertip is far less precise than a mouse cursor, and touch has no hover state — there's no way to preview what's about to be tapped the way a mouse cursor hovering over a link previews it before the click.

Orientation and zoom have their own real failure modes. Content shouldn't be locked to a single orientation without a genuine reason — locking portrait-only when nothing about the content actually requires it excludes users who've mounted their device, or who simply prefer landscape. And pinch-to-zoom should never be disabled. A common, real, avoidable anti-pattern is setting user-scalable=no in the viewport meta tag, which actively blocks low-vision users from zooming in to read content at all.

See it in a real thing: the viewport meta tag anti-pattern

<!-- Blocks zoom entirely -- a real, common, avoidable mistake -->
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no" />

<!-- Lets the user zoom, which is what low-vision users depend on -->
<meta name="viewport" content="width=device-width, initial-scale=1" />

user-scalable=no is usually added to prevent an accidental double-tap zoom on a form field, but the cost is total: it removes the one accommodation a low-vision mobile user relies on most, for every user, everywhere on the page, to solve a narrow and usually better-solved-elsewhere problem.

What people usually miss

Watch out

• Desktop screen-reader testing and mobile screen-reader testing are not interchangeable. The gesture vocabulary is fundamentally different (swipe and double-tap versus Tab and Enter), so a desktop-only pass leaves mobile genuinely unverified.
• 44-48px touch targets exist because fingertip precision is worse than cursor precision, not as an arbitrary design rule. Treating it as a style preference rather than an accessibility floor is a common way small, tightly-packed touch targets ship anyway.
• There's no hover state on touch, which removes a whole category of "preview before commit" affordance designers often lean on for desktop — a tooltip or hover-revealed action has to have a touch-equivalent, not just quietly disappear on mobile.
• user-scalable=no is a real, specific, still-common anti-pattern, not a hypothetical example — it's frequently added to solve one narrow annoyance (accidental input-field zoom) at the cost of blocking zoom entirely for every low-vision user on the page.

Why this matters in interviews

"This component was fully tested with a screen reader — are we good to ship on mobile?" is a real question that tests whether a candidate knows mobile screen readers use a different gesture model entirely, and that "tested with a screen reader" without naming which one and on what platform is an incomplete claim.