If you’ve spent any time working on web accessibility, you’ve probably focused on the desktop experience: keyboard navigation, screen reader compatibility, color contrast, and alt text. Those are all critical. But there’s a gap that many teams overlook — and it’s the same gap that most of your users are staring at right now.

More than 60% of all web traffic now comes from mobile devices. That means the majority of your visitors are experiencing your site on a small touchscreen, often with one hand, sometimes in bright sunlight, and frequently with assistive technologies that behave differently than their desktop counterparts. If your accessibility efforts stop at the desktop, you’re leaving the majority of your audience behind.

Mobile web accessibility isn’t a separate standard — it’s the same WCAG 2.1 AA requirements applied to the mobile context. But the way those requirements play out on a phone is materially different from how they play out on a laptop. Here’s what you need to know, and what you need to do about it.

Why Mobile Accessibility Is Different

On a desktop, users have a precise pointing device (a mouse), a full keyboard, a large screen, and a stable context. On a mobile device, almost all of those assumptions break down:

  • Touch targets are imprecise. A finger is much larger than a mouse cursor. Buttons and links that work fine with a mouse can be nearly impossible to tap accurately.
  • There’s no hover state. Many desktop interactions rely on hovering to reveal menus, tooltips, or additional content. On mobile, hover doesn’t exist — and what’s hidden behind a hover may be completely inaccessible.
  • Screen readers work differently. Mobile screen readers like VoiceOver (iOS) and TalkBack (Android) use different gestures and navigation patterns than desktop screen readers like JAWS or NVDA.
  • The viewport is small. Content that’s readable on a 27-inch monitor may be cramped, overwhelming, or unusable on a 6-inch screen.
  • Context is unpredictable. Users may be on a bumpy train, in bright sunlight, or holding their phone with one hand. Motor precision and visual conditions vary wildly.

These differences mean that a site that passes a desktop accessibility audit can still fail badly on mobile — and since most of your users are on mobile, that’s a problem.

The Core Principles of Mobile Accessibility

1. Touch Targets Must Be Large Enough

WCAG 2.5.5 (Target Size) recommends that touch targets be at least 44 by 44 CSS pixels. This isn’t an arbitrary number — it’s roughly the size of a fingertip. Buttons, links, form fields, and interactive elements that are smaller than this are difficult to tap accurately, especially for users with motor impairments.

In practice, this means:

  • Navigation links shouldn’t be crammed together with no spacing.
  • Icon-only buttons need adequate padding around the icon.
  • Form checkboxes and radio buttons should have large associated tap areas, not just the tiny default control.
  • Inline links within paragraphs should have enough line height and spacing to be tappable without accidentally hitting an adjacent link.

2. Don’t Rely on Hover

Hover-based interactions are one of the most common mobile accessibility failures. Dropdown menus that only open on hover, tooltips that only appear on hover, and content that’s only revealed when the mouse is over a specific element — all of these are inaccessible on touch devices.

The fix: Every hover-triggered interaction should also have a touch-friendly equivalent. Use on click or on focus in addition to on hover. Better yet, design your interactions so that hover is an enhancement, not a requirement. If a user can’t hover, they should still be able to access everything.

3. Make Sure Content Reflows Properly

WCAG 1.4.10 (Reflow) requires that content be presented without loss of information or functionality when users zoom to 400% or view on a narrow viewport. On mobile, this means your site should reflow into a single column rather than requiring horizontal scrolling.

Common reflow problems include:

  • Fixed-width layouts that don’t adapt to narrow screens.
  • Tables that don’t collapse or scroll independently.
  • Images that overflow their containers.
  • Text that’s too small to read and can’t be zoomed because the viewport is locked.

The fix: Use responsive design with flexible grids and relative units (like rem and % instead of px). Test your site at 320px wide — the narrowest common mobile viewport — and make sure nothing is cut off or requires horizontal scrolling.

4. Test With Mobile Screen Readers

Desktop screen reader testing is standard practice, but mobile screen reader testing is just as important — and it reveals different issues. VoiceOver on iOS and TalkBack on Android are the two most widely used mobile screen readers, and they interact with your site differently than JAWS or NVDA.

Key things to test:

  • Reading order: Does VoiceOver read content in a logical order, or does it jump around due to CSS positioning?
  • Landmark navigation: Can users navigate by headings, landmarks, and form fields?
  • Form labels: Are form fields properly labeled so the screen reader announces them correctly?
  • Dynamic content: When content updates dynamically (e.g., a cart count changes, a modal opens), does the screen reader announce it?
  • Focus management: When a modal or dialog opens, does focus move to it? When it closes, does focus return to the triggering element?

5. Respect the User’s Settings

Mobile users customize their devices extensively — font sizes, color schemes (including dark mode), reduced motion, and increased contrast. Your site should respect these preferences, not override them.

Specifically:

  • Don’t disable pinch-to-zoom. Setting user-scalable=no in your viewport meta tag prevents users from zooming in, which is critical for low-vision users. This is a WCAG 1.4.4 (Resize Text) violation.
  • Support prefers-color-scheme. If you force a light theme on a user who’s selected dark mode, you may create contrast issues or discomfort.
  • Honor prefers-reduced-motion. Some users experience motion sensitivity. If you have animations, parallax effects, or auto-playing video, respect this preference and reduce or eliminate motion.
  • Use relative font sizes. If you hardcode font sizes in pixels, users who increase their system font size won’t see any change on your site. Use rem or em units instead.

6. Simplify Navigation and Input

Mobile users are working with limited screen real estate and imprecise input. Complex navigation menus, long forms, and multi-step processes can be especially challenging.

Best practices:

  • Keep navigation simple. Consider a hamburger menu for primary navigation, but make sure it’s easy to open and that menu items are large enough to tap.
  • Minimize form fields. Every field you add is another interaction on a small screen. Ask only for what you truly need.
  • Use appropriate input types. Use type="email", type="tel", type="number", etc. so that mobile devices show the right keyboard for each field.
  • Autofill and autocomplete. Use autocomplete attributes so browsers can fill in common fields (name, email, address) automatically, reducing the amount of typing required.
  • Avoid time limits. If your form or process has a timeout, make sure it’s generous enough for users who need more time, and provide a way to extend it.

Mobile Accessibility Testing: A Practical Approach

Testing mobile accessibility doesn’t require a lab full of devices. Here’s a practical approach you can follow:

  1. Test on real devices. Emulators are helpful, but they don’t fully replicate the touch experience, screen reader gestures, or real-world conditions. Test on at least one iOS device with VoiceOver and one Android device with TalkBack.

  2. Use your browser’s device emulation. Chrome DevTools and Firefox Responsive Design Mode let you quickly check how your site looks at different viewport sizes. This is a fast first pass before you move to real device testing.

  3. Run automated scans on mobile viewports. Many accessibility scanning tools, including Accessible Metrics, can scan your site and identify issues that are particularly relevant to mobile users — small touch targets, missing viewport configuration, fixed font sizes, and more.

  4. Test with zoom. Manually zoom to 400% in your mobile browser and make sure content reflows without horizontal scrolling.

  5. Navigate by keyboard and gestures. Try navigating your site using only a Bluetooth keyboard connected to your phone, and then using only screen reader gestures. If you can’t reach all interactive elements, neither can your users.

  6. Test in real-world conditions. Step outside in bright sunlight. Try using your site with one hand. These aren’t formal WCAG tests, but they’ll quickly reveal contrast and usability problems that affect real users.

Common Mobile Accessibility Mistakes to Avoid

  • Locking the viewport. Setting maximum-scale=1 or user-scalable=no prevents zooming and violates WCAG.
  • Tiny close buttons. Modal dialogs with a tiny “X” in the corner are nearly impossible to tap on mobile. Make close buttons at least 44x44 pixels.
  • Sticky elements that cover content. Fixed headers or footers that take up too much screen real estate can obscure content, especially when the user zooms in.
  • Custom interactive components without ARIA. Custom dropdowns, accordions, and tabs that work with a mouse but aren’t keyboard-accessible or screen-reader-accessible are a frequent failure point.
  • Interstitials and pop-ups. Full-screen overlays that are difficult to dismiss on mobile can trap users and block access to content entirely.
  • Inaccessible captcha. Captcha challenges that require precise interaction or visual recognition can be impossible for some mobile users. Provide accessible alternatives.

The Business Case for Mobile Accessibility

If the ethical and legal arguments aren’t enough, consider the numbers. Mobile traffic is the majority of web traffic. Users who can’t use your mobile site will leave — and they’ll go to a competitor whose site works. Bounce rates on mobile are already higher than desktop; accessibility barriers make them worse.

There’s also the SEO angle. Google uses mobile-first indexing, meaning it primarily looks at the mobile version of your site for ranking signals. Sites that are fast, usable, and accessible on mobile are rewarded in search results. Sites that aren’t are penalized.

And from a legal standpoint, accessibility lawsuits increasingly cite mobile-specific barriers. Courts have recognized that mobile apps and mobile websites are places of public accommodation under the ADA. If your desktop site is compliant but your mobile experience isn’t, you’re still at risk.

Start Where You Are

Mobile accessibility can feel overwhelming if you’ve never thought about it before, but you don’t have to fix everything at once. Start with a scan to identify your most critical mobile issues. Fix the high-severity problems first — locked viewports, missing labels, tiny touch targets. Then work your way through the rest.

The most important thing is to start testing on mobile today. If you’re only testing on desktop, you’re testing for less than half your users. Every fix you make brings your site closer to being truly accessible — for every user, on every screen, in every context.

Ready to see how your site performs on mobile? Run a free accessibility scan with Accessible Metrics and get a detailed report against WCAG 2.1 AA standards — including mobile-specific issues like touch target size, viewport configuration, and reflow problems.