How to Make Your Website Accessible on Mobile

Making your website accessible on mobile means the same WCAG principles still apply, but the phone context adds challenges you do not face on desktop: tiny touch screens instead of a precise mouse, one-handed use on the move, pinch-to-zoom, orientation changes, and screen readers driven by gestures. The essentials: make touch targets large and well spaced (roughly 44x44 to 48x48 px), never disable zoom and ensure content reflows (WCAG 1.4.10 and 1.4.4), support both orientations (1.3.4), make everything work with mobile screen readers (VoiceOver and TalkBack) through proper semantic HTML, keep a visible focus state for external keyboards, avoid hover-only interactions, and build accessible mobile forms with real labels and the right input types. This guide walks through each, with a fix for every common issue.

It extends what web accessibility is and why it matters into the mobile context and overlaps heavily with how to make a website keyboard accessible, since many mobile users attach keyboards or switch devices.

Why mobile accessibility needs its own attention

A large and growing share of web traffic is on phones, and disabled users are no exception — many people use a smartphone as their primary or only device. The WCAG standard does not change on mobile (the same POUR principles and AA target apply), but the way people interact does, and that surfaces specific barriers:

• Input is touch, which is far less precise than a mouse pointer — fingers are blunt, and people may be walking, holding a child, or using one hand.
• Screens are small, so layouts compress and text shrinks, and zoom becomes essential rather than occasional.
• Devices rotate, so your layout must work in both portrait and landscape.
• Screen readers are driven by gestures, not a keyboard, changing how navigation works.
• Many users attach external keyboards or switch devices, so keyboard accessibility still matters on mobile.

So mobile accessibility is not a different standard — it is the same standard tested against a harder, more varied interaction model. The table at the end of each section, and the consolidated one below, pairs each common issue with its fix.

Touch target size and spacing

The most distinctive mobile issue is touch target size. A mouse pointer is a single pixel; a fingertip covers a wide, imprecise area. Targets that are too small or packed too closely cause mis-taps, which are frustrating for everyone and a genuine barrier for people with tremors, limited dexterity, or large fingers.

The guidance converges on generous sizing:

• Apple's Human Interface Guidelines recommend a minimum tappable area of about 44x44 points.
• Google's Material Design recommends about 48x48 density-independent pixels.
• WCAG 2.5.5 (Target Size, Enhanced) sets 44x44 CSS pixels at Level AAA.
• WCAG 2.2 added 2.5.8 (Target Size, Minimum) at Level AA, requiring at least 24x24 CSS pixels with spacing rules so smaller targets are not crowded.

The practical rule: make interactive elements at least ~44-48px in their tappable dimension where you can, and always ensure adequate spacing between adjacent targets so a finger cannot easily hit the wrong one. Note that the visible element can be smaller than its tappable area — you can extend the hit area with padding — but the area a user can actually tap is what counts. This matters most for icon buttons, close (x) controls, inline links sitting close together, and items in tight menus.

Zoom, resize and reflow

People with low vision zoom, and on a phone almost everyone zooms sometimes. Two WCAG criteria govern this, and one common mistake violates both.

• WCAG 1.4.4 (Resize Text), AA — text must be resizable up to 200% without loss of content or function.
• WCAG 1.4.10 (Reflow), AA — content must reflow so that it can be presented without two-dimensional scrolling at a width equivalent to 320 CSS pixels (roughly a phone in portrait). In plain terms: when zoomed or on a narrow screen, content should reflow into a single column rather than forcing the user to scroll horizontally to read each line.

The cardinal mistake is disabling zoom. Setting user-scalable=no or maximum-scale=1 in the viewport meta tag stops pinch-to-zoom entirely, which locks out low-vision users who need to enlarge text. Never do this. Always allow zooming, and design a responsive, reflowing layout so that when content is enlarged it stacks cleanly into one column without clipping, overlap, or horizontal scrolling. Testing this is simple and revealing: zoom your page on a phone (or narrow a desktop browser to ~320px) and check that everything stays readable and reachable — the same kind of zoom/reflow check we describe in how to check if a website is accessible.

Orientation support

Some users fix their device orientation — for example, a phone mounted on a wheelchair may be locked in landscape, or a user may keep portrait lock on for comfort. WCAG 1.3.4 (Orientation), AA requires that content is not restricted to a single orientation (portrait or landscape) unless a specific orientation is essential (a piano app might be one rare exception). So your layout must work and remain usable in both orientations. In practice this means responsive design that adapts gracefully when the device rotates, rather than code that assumes or forces portrait only.

Mobile screen readers: VoiceOver and TalkBack

Blind and low-vision users navigate mobile sites with built-in screen readers — VoiceOver on iOS/iPadOS and TalkBack on Android — and these work very differently from a mouse. They are driven by touch gestures:

• Swipe right / left to move focus to the next / previous element.
• Double-tap anywhere to activate the element currently in focus (you do not tap the element directly; you focus it by swiping, then double-tap).
• Two-finger swipe, rotor (iOS) or local context menus (TalkBack) to read continuously or to navigate by headings, links, form fields and other element types — the mobile equivalent of the heading and link navigation desktop screen-reader users rely on (see what are screen readers and how do they work).

Because mobile screen readers consume the same accessibility information as desktop ones, the foundation is identical: semantic HTML. Real headings give a navigable outline; real buttons and links are announced and operable; proper labels make form fields usable; alt text describes images; landmarks let users jump around. If your markup is semantic, it works for VoiceOver and TalkBack largely for free.

Two mobile-specific cautions. First, custom gestures (swipe-to-delete, complex drag interactions, multi-finger tricks) can conflict with the screen reader's own gestures and may be unreachable — so any function offered only through a custom gesture must have an accessible alternative (a visible button, for instance). WCAG 2.5.1 (Pointer Gestures) requires that functionality using multipoint or path-based gestures can also be operated with a single pointer. Second, test on a real device with VoiceOver or TalkBack turned on; the gesture-driven experience is hard to imagine from the desktop.

Visible focus and external input

It is easy to assume mobile means touch-only, but many people pair external keyboards with tablets and phones, and switch-access users navigate by stepping focus through elements. That means the desktop keyboard rules still apply on mobile: there must be a visible focus indicator so these users can see where they are (WCAG 2.4.7, AA), focus order must be logical, and there must be no keyboard traps. Do not strip focus styling just because the primary input is touch — the full reasoning is in how to make a website keyboard accessible.

Avoid hover-only interactions

On desktop, hovering a mouse can reveal a menu or a tooltip. On a touch screen, there is no hover — a finger either touches or it does not. So any content or function that appears only on hover can be completely unreachable on mobile (and is problematic for many desktop users too). WCAG 1.4.13 (Content on Hover or Focus) adds requirements about such content being dismissable, hoverable and persistent. The mobile fix is to ensure hover-revealed content is also available on tap/click or focus, and never to hide essential actions or information behind hover alone.

Accessible mobile forms

Forms are hard on a small screen, and they are where accessibility most often breaks. The essentials:

• Real, associated labels for every field — a programmatically linked <label>, not just a placeholder. Placeholders disappear when the user starts typing, are often low-contrast, and are not reliably announced, so they are not a substitute for a label.
• The correct input type and attributes, so the device shows the right on-screen keyboard and can autofill: type="email" brings up an email keyboard, type="tel" a number pad, type="url", type="number", and so on; appropriate autocomplete values let the device fill name, email and address fields (which also satisfies WCAG 1.3.5, Identify Input Purpose). This reduces typing — a real burden on mobile — for everyone.
• Large, well-spaced fields and buttons that meet the touch-target guidance above, so people can tap and edit comfortably.
• Clear, specific error handling: errors shown in text near the relevant field (not by colour alone), announced by the screen reader, and explaining how to fix the problem.
• A logical order and minimal length, because every extra field is heavier on a phone.

Good mobile form design overlaps almost entirely with good accessible form design — proper labels, helpful errors, sensible structure — applied with extra care to the constraints of a small touch screen.

Issue-and-fix summary

Pulling the guidance into one reference:

Mobile issue	Fix
Touch targets too small or crowded	Size targets ~44-48px with adequate spacing (WCAG 2.5.8 AA / 2.5.5 AAA)
Zoom disabled	Remove user-scalable=no/maximum-scale; always allow pinch-zoom (1.4.4)
Horizontal scrolling when zoomed	Build a responsive layout that reflows to one column at ~320px (1.4.10)
Locked to one orientation	Support both portrait and landscape unless essential (1.3.4)
Custom gestures unreachable by screen reader	Provide a single-pointer / button alternative (2.5.1)
No visible focus for external keyboards	Keep a clear focus indicator; no traps (2.4.7)
Hover-only menus or tooltips	Make the same content available on tap/click or focus (1.4.13)
Placeholder used as the only label	Add a real associated <label> for every field
Wrong keyboard / no autofill on inputs	Use correct type and autocomplete attributes (1.3.5)
Errors shown by colour only	Show specific errors in text, announced, near the field

How to test mobile accessibility

A practical test pass: open the site on a real phone and try a key task with VoiceOver or TalkBack turned on, navigating by swipe and double-tap; zoom the page and rotate the device to confirm reflow and orientation both hold up; tap the small controls (close buttons, icon buttons, tight links) to check they are reachable; pair a Bluetooth keyboard and tab through to confirm focus is visible and nothing traps; and fill in a form to check labels, keyboards, autofill and error messages. This mobile pass slots straight into the broader process in how to run an accessibility audit, and it catches issues that a desktop-only check never will.

The bottom line

Mobile accessibility applies the same WCAG standard under a harder interaction model. Make touch targets large and well spaced (~44-48px), never disable zoom and ensure content reflows at narrow widths (1.4.10, 1.4.4), support both orientations (1.3.4), make everything work with VoiceOver and TalkBack through solid semantic HTML, provide single-pointer alternatives to custom gestures, keep a visible focus state for external keyboards, avoid hover-only content, and build accessible mobile forms with real labels and correct input types. Test it on a real device with a screen reader and at zoom. For the foundations, see what web accessibility is and why it matters; for the testing process, how to check if a website is accessible.

Want to see how your site scores on a WCAG accessibility check, alongside mobile performance and SEO? Analyse any URL with StackOptic — one report, free, no sign-up.