Mobile Accessibility: Making Your Website Work for Everyone

More than half of all web traffic now comes from phones and tablets. That number has been climbing for years, and it's not going back. If your site isn't accessible on mobile, you're shutting out a massive portion of your audience, including people with disabilities who rely on mobile assistive technologies every day.

I've scanned thousands of sites with our free accessibility scanner, and mobile-specific issues are some of the most common problems I see. Tiny buttons, broken zoom, locked orientations, forms that are painful to fill out on a phone. The frustrating part is that most of these are easy to fix once you know what to look for.

This guide covers everything you need to know about mobile website accessibility: the WCAG criteria that apply, practical code examples, testing strategies, and a quick wins checklist you can start working through today.

Why Mobile Accessibility Matters

Here's the reality: mobile devices are the primary way most people access the web. As of 2025, mobile accounts for roughly 60% of global web traffic. For many users with disabilities, a smartphone is their main (or only) computing device. Screen readers are built right into iOS and Android. Voice control, switch access, magnification: it's all there in the phone's settings.

People with motor impairments often find touchscreens easier to use than a mouse and keyboard. People with low vision use the built-in zoom and large text settings on their phones constantly. People who are blind navigate entirely through VoiceOver or TalkBack, swiping through page elements one at a time.

When your mobile experience is inaccessible, you're not just violating WCAG guidelines. You're cutting off real people from your content, your products, and your services. And yes, the legal risk applies to mobile too. ADA lawsuits don't distinguish between desktop and mobile experiences. If your site is inaccessible on a phone, it's inaccessible, period.

The good news: mobile accessibility and good mobile UX overlap heavily. Fixing accessibility issues almost always makes the experience better for everyone.

Touch Target Sizes

This is probably the single most common mobile accessibility failure I see. Buttons, links, and interactive elements that are too small to tap reliably. If you've ever tried to tap a tiny "X" to close a popup on your phone and hit the wrong thing three times in a row, you know exactly how frustrating this is.

WCAG 2.2 introduced a new success criterion specifically for this: 2.5.8 Target Size (Minimum), which requires interactive elements to be at least 24x24 CSS pixels, or have sufficient spacing from adjacent targets. The recommended size (WCAG 2.5.5, AAA level) is 44x44 CSS pixels, and that's what you should actually aim for.

Why 44px? Because fingers are imprecise. The average adult fingertip covers about 48px on a typical phone screen. A 24px button technically passes the minimum, but users with motor impairments, tremors, or limited dexterity will struggle with anything smaller than 44px.

Here's how to implement proper touch targets in CSS:

/* Minimum touch target size */
.btn, button, [role="button"] {
  min-width: 44px;
  min-height: 44px;
  padding: 12px 16px;
}

/* For inline links that can't be 44px tall,
   add vertical padding to increase the tap area */
a {
  padding: 8px 0;
  display: inline-block;
}

/* Icon buttons need explicit sizing */
.icon-btn {
  width: 44px;
  height: 44px;
  display: flex;
  align-items: center;
  justify-content: center;
}

/* Ensure spacing between adjacent targets */
.nav-list a {
  min-height: 44px;
  display: flex;
  align-items: center;
  margin-bottom: 4px;
}

Watch out for these common offenders: social media icon rows, pagination links, footer link lists, close buttons on modals, and breadcrumb navigation. All of these tend to have undersized tap targets on mobile.

Zoom and Text Resizing

One of the most harmful things a developer can do is disable pinch-to-zoom. I still see this on a shocking number of sites:

<!-- NEVER do this -->
<meta name="viewport" content="width=device-width,
  initial-scale=1, maximum-scale=1, user-scalable=no">

<!-- Do this instead -->
<meta name="viewport" content="width=device-width,
  initial-scale=1">

WCAG 1.4.4 (Resize Text) requires that text can be resized up to 200% without loss of content or functionality. WCAG 1.4.10 (Reflow) requires that content reflows properly at 320px width (equivalent to 400% zoom on a 1280px viewport). When you disable pinch-to-zoom, you're violating both of these criteria and making your site unusable for people with low vision.

Beyond the viewport meta tag, you should also use relative units for font sizes. Pixels are fixed. If a user sets their phone's font size to "Large" or "Extra Large" in their device settings, text set in px won't respond. Use rem or em instead.

/* Bad: fixed pixel sizes ignore user preferences */
body { font-size: 14px; }
h1 { font-size: 32px; }

/* Good: relative units respect user preferences */
body { font-size: 1rem; }
h1 { font-size: 2rem; }
p { font-size: 1rem; line-height: 1.6; }

/* Use clamp() for fluid typography that scales well */
h1 {
  font-size: clamp(1.5rem, 4vw + 1rem, 2.5rem);
}

/* Avoid setting height on text containers
   so content can expand when text is enlarged */
.card {
  min-height: 200px;  /* not height: 200px */
  overflow: visible;   /* not overflow: hidden */
}

Also test what happens when text gets larger. Does it overflow its container? Does it overlap other elements? Does the layout break? These are all reflow failures, and they're more common than you'd think. For more on how WCAG 2.2 handles these requirements versus the previous version, check our WCAG 2.2 vs 2.1 comparison.

Responsive Design and Accessibility

A lot of developers assume that "responsive" and "accessible" mean the same thing. They don't. A responsive site adjusts its layout for different screen sizes. An accessible site works for people with different abilities. You need both, and they're separate concerns.

That said, responsive design and accessibility share a lot of common ground. A layout that reflows properly at narrow widths also works better for zoomed-in users. A navigation menu that collapses into a hamburger on mobile needs to be keyboard accessible. Media queries that adjust font sizes help users with low vision.

Here's where responsive design helps accessibility:

• Reflow: Content that wraps and stacks on narrow screens also works when users zoom in to 400%.
• Readable line lengths: Constraining content width on large screens improves readability for everyone, especially users with cognitive disabilities.
• Flexible images: Images that scale with their container don't cause horizontal scrolling.

And here's where responsive design falls short:

• Touch targets: Your desktop-sized buttons might be fine with a mouse, but too small for fingers. You need separate touch target sizing for mobile.
• Hover states: Tooltips and dropdown menus triggered by hover don't work on touchscreens. You need tap or focus alternatives.
• Focus management: A hamburger menu that slides in needs proper focus trapping and ARIA attributes. Responsive layout alone doesn't handle this.
• Content hiding: If you use display: none at mobile breakpoints to hide content, screen readers won't see it either. Make sure you're not hiding important information.

/* Responsive pattern that's also accessible */
@media (max-width: 768px) {
  .desktop-nav {
    display: none; /* hidden from everyone on mobile */
  }
  .mobile-nav {
    display: block;
  }

  /* Stack columns on mobile */
  .two-col {
    flex-direction: column;
  }

  /* Increase touch targets on mobile */
  .nav-link {
    min-height: 44px;
    padding: 12px 16px;
  }
}

/* Don't do this: hiding content that users need */
@media (max-width: 768px) {
  .important-info {
    display: none; /* Now mobile users can't access this! */
  }
}

The takeaway: responsive design is necessary but not sufficient for mobile accessibility. You still need to think about touch targets, focus management, zoom support, and screen reader compatibility.

Orientation: Don't Lock to Portrait

WCAG 1.3.4 (Orientation) is straightforward: don't restrict your content to a single display orientation unless a specific orientation is essential for the content to function. A piano app? Sure, landscape makes sense. A blog, a store, a contact form? There's no reason to lock orientation.

This matters more than you might think. Some users mount their phones in a fixed position (on a wheelchair mount, for example) and can't rotate the device. Others use landscape mode for a wider viewport, which can help with reading and navigation. Some switch devices only work in one orientation.

Check for this in your CSS:

/* Don't do this */
@media (orientation: portrait) {
  .content { display: block; }
}
@media (orientation: landscape) {
  .content { display: none; } /* Hiding content in landscape! */
}

/* Also check your web app manifest or meta tags */
<!-- Don't lock orientation here either -->
<meta name="screen-orientation" content="portrait">

And in your JavaScript, avoid using the Screen Orientation API to force portrait mode. Your site should work in both orientations, even if the layout changes.

Mobile Screen Readers: VoiceOver and TalkBack

If you've never used a mobile screen reader, spending 10 minutes with one will teach you more about mobile accessibility than reading any article (including this one). Here's a quick primer on the two built-in screen readers.

VoiceOver on iOS

VoiceOver is built into every iPhone. To turn it on, go to Settings, then Accessibility, then VoiceOver, and toggle it on. You can also ask Siri: "Turn on VoiceOver." Fair warning: the gesture system changes completely once VoiceOver is active.

• Swipe right: Move to the next element
• Swipe left: Move to the previous element
• Double-tap: Activate the selected element (like a click)
• Two-finger swipe up: Read all content from the current position
• Rotor (two-finger twist): Switch between navigation modes (headings, links, form fields)

Test your site with VoiceOver and pay attention to: Are all images announced with their alt text? Do buttons and links have understandable labels? Can you navigate through form fields and submit a form? Is the reading order logical?

TalkBack on Android

TalkBack is Android's built-in screen reader. Enable it in Settings, then Accessibility, then TalkBack. The gestures are similar to VoiceOver.

• Swipe right: Next element
• Swipe left: Previous element
• Double-tap: Activate the selected element
• Swipe up then right: Open the navigation menu (similar to VoiceOver's rotor)

TalkBack is a bit more forgiving than VoiceOver in some areas, but stricter in others. It's worth testing on both platforms if you can. You don't need physical devices. Android Studio's emulator supports TalkBack, and Xcode's simulator supports VoiceOver. For a deeper look at screen reader testing, read our screen reader testing guide.

Gesture Alternatives

Mobile apps and websites increasingly rely on gestures: swipe to delete, pinch to zoom, drag to reorder, pull to refresh. These can be great for usability, but they're a barrier for people who can't perform complex gestures.

WCAG 2.5.1 (Pointer Gestures) says that any functionality triggered by a multipoint or path-based gesture must also be available through a single pointer action (a tap or click). WCAG 2.5.7 (Dragging Movements) in WCAG 2.2 extends this to drag-and-drop interactions.

What this means in practice:

• If users can swipe to delete an item, also provide a delete button.
• If users can drag to reorder a list, also provide "move up" and "move down" buttons.
• If users can pinch to zoom a map, also provide zoom in/out buttons.
• If users can swipe between carousel slides, also provide previous/next buttons and pause controls.

<!-- Swipeable card with button alternative -->
<div class="card" role="group" aria-label="Email from John">
  <div class="card-content">
    <p>Meeting tomorrow at 3pm</p>
  </div>
  <!-- This button provides a non-gesture alternative
       to the swipe-to-delete action -->
  <button class="delete-btn" aria-label="Delete email from John">
    Delete
  </button>
</div>

<!-- Sortable list with button alternatives -->
<ul class="sortable-list">
  <li>
    <span>Item 1</span>
    <button aria-label="Move Item 1 up">Up</button>
    <button aria-label="Move Item 1 down">Down</button>
  </li>
</ul>

The key principle: every gesture should have a simple tap/click alternative that achieves the same result. Not everyone can swipe, pinch, or drag with precision.

Forms on Mobile

Forms are already one of the trickiest accessibility areas, and mobile makes them harder. Small keyboards, autocorrect, tiny fields: the potential for frustration is enormous. For the full rundown on form accessibility, read our accessible forms guide. Here are the mobile-specific considerations.

Use the Right Input Types

HTML5 input types trigger different virtual keyboards on mobile devices. Using the right type makes a huge difference for usability and accessibility.

<!-- Use type="email" for email fields - shows @ key -->
<input type="email" id="email" name="email"
       autocomplete="email">

<!-- Use type="tel" for phone numbers - shows number pad -->
<input type="tel" id="phone" name="phone"
       autocomplete="tel">

<!-- Use type="url" for URLs - shows .com key -->
<input type="url" id="website" name="website"
       autocomplete="url">

<!-- Use inputmode="numeric" for numbers that aren't
     phone numbers (like zip codes) -->
<input type="text" id="zip" name="zip"
       inputmode="numeric" pattern="[0-9]*"
       autocomplete="postal-code">

Enable Autocomplete

The autocomplete attribute is a huge win on mobile. It lets the browser autofill fields from saved information, which means users don't have to type as much on a small keyboard. WCAG 1.3.5 (Identify Input Purpose) actually requires this for common fields like name, email, phone, and address.

<label for="full-name">Full Name</label>
<input type="text" id="full-name" name="name"
       autocomplete="name">

<label for="street">Street Address</label>
<input type="text" id="street" name="street"
       autocomplete="street-address">

<label for="cc-number">Card Number</label>
<input type="text" id="cc-number" name="ccnumber"
       inputmode="numeric" autocomplete="cc-number">

Large Tap Targets for Form Elements

Form fields, checkboxes, and radio buttons need to be large enough to tap accurately. The default size for checkboxes on most browsers is tiny on mobile. Use CSS to increase the tap area.

/* Make form inputs comfortable to tap */
input[type="text"],
input[type="email"],
input[type="tel"],
input[type="url"],
select,
textarea {
  min-height: 44px;
  font-size: 16px; /* prevents iOS zoom on focus */
  padding: 10px 12px;
  width: 100%;
  box-sizing: border-box;
}

/* Make checkboxes and radio buttons easier to tap */
input[type="checkbox"],
input[type="radio"] {
  width: 24px;
  height: 24px;
  margin-right: 8px;
}

/* Associate labels so tapping label activates the input */
label {
  display: block;
  margin-bottom: 4px;
  font-weight: 500;
}

One important tip: on iOS, any input with a font size smaller than 16px will cause the browser to zoom in when the field is focused. This is disorienting and often breaks the layout. Always set your form inputs to at least 16px.

Mobile Navigation Patterns

Mobile navigation is one of the most important accessibility considerations, and one of the most commonly broken. Here's what to get right.

Hamburger Menus

The hamburger menu is everywhere on mobile. It can be accessible, but only if you implement it correctly. For keyboard accessibility patterns that apply here, see our keyboard accessibility guide.

• The toggle button needs aria-expanded="false" (or "true" when open) and aria-controls pointing to the nav element's ID.
• When the menu opens, focus should move to the first link inside it.
• When the menu closes, focus should return to the toggle button.
• The menu should be closable with the Escape key.
• When the menu is closed, its links should not be reachable via Tab.

<button class="menu-toggle"
        aria-expanded="false"
        aria-controls="mobile-nav"
        aria-label="Menu">
  <span class="hamburger-icon"></span>
</button>

<nav id="mobile-nav" aria-label="Main navigation">
  <a href="/">Home</a>
  <a href="/products">Products</a>
  <a href="/about">About</a>
  <a href="/contact">Contact</a>
</nav>

Bottom Navigation Bars

Bottom navigation bars (the row of icons at the bottom of the screen, like in most native apps) are becoming more common on mobile websites. They're actually great for accessibility because they're always visible and easy to reach with your thumb. Just make sure each icon has a visible text label and an accessible name. Icon-only navigation is a common accessibility failure.

Sticky Headers

Sticky navigation bars that follow you as you scroll can reduce the visible content area significantly on small screens. This creates problems for users who zoom in, because the sticky header might take up half the viewport at 200% zoom. Consider making the header non-sticky on mobile, or at least keeping it compact (under 60px tall).

Testing Mobile Accessibility

You can catch many mobile accessibility issues without a phone. But for a thorough test, you need to use actual devices.

Desktop-Based Testing

Start with our free accessibility scanner, which checks for touch target sizes, zoom restrictions, and other mobile-relevant WCAG criteria. Then use your browser's responsive design mode (Chrome DevTools device toolbar, Firefox Responsive Design Mode) to visually inspect your layout at mobile widths.

Check for: horizontal scrolling, text overflow, overlapping elements, and touch targets that look too small. This catches layout issues but not interaction issues.

Real Device Testing

Nothing replaces testing on a real phone. Here's a quick process:

1. Open your site on an iPhone and an Android phone (if you have both).
2. Try to use every interactive element: links, buttons, forms, menus, accordions.
3. Pinch to zoom. Does the layout break? Is any content cut off?
4. Rotate the device. Does the site work in both portrait and landscape?
5. Turn on VoiceOver (iOS) or TalkBack (Android) and navigate through a page.
6. Increase the text size in your device settings and reload the page. Does text overflow or overlap?

Common Mobile Accessibility Tools

• axe DevTools mobile: Runs accessibility checks on mobile views
• Accessibility Inspector (Xcode): Inspects accessibility properties of elements on iOS
• Accessibility Scanner (Android): Google's app that scans and flags accessibility issues on Android
• BrowserStack / Sauce Labs: Cloud-based testing on real devices if you don't have physical devices

Quick Wins Checklist

Here's what to fix first. Each of these addresses a specific WCAG criterion and has a real impact on mobile users.

1. Remove maximum-scale=1 and user-scalable=no from your viewport meta tag. This is a one-line fix that immediately improves accessibility for users with low vision.
2. Set all interactive elements to at least 44x44px. Buttons, links, form fields, checkboxes. Use the CSS examples from this article.
3. Set form input font size to at least 16px. This prevents the iOS auto-zoom behavior that disorients users.
4. Add autocomplete attributes to all common form fields (name, email, phone, address, payment).
5. Use correct input types (email, tel, url, number) so mobile keyboards match the expected input.
6. Test your hamburger menu with a keyboard. Can you open it, navigate it, and close it without a mouse? Does focus management work correctly?
7. Check that your site works in landscape orientation. Don't lock to portrait.
8. Add button alternatives for all gesture-based interactions. Swipe, drag, pinch: each needs a tap/click fallback.
9. Test with VoiceOver or TalkBack for at least 10 minutes. Navigate your homepage and one form page.
10. Run an accessibility scan to get a full report of issues across all categories.

Mobile accessibility isn't a separate discipline from web accessibility. It's the same set of principles applied to the device most of your users are actually using. The WCAG criteria I've covered here, from touch targets to zoom to orientation, were all added or updated because mobile usage has become the norm, not the exception.

The best place to start is by scanning your site to see where you stand. From there, work through the checklist above, test on a real phone, and iterate. You don't need to get everything perfect on day one. You just need to start making progress.

For more on the specific WCAG criteria that apply to all of these areas, read our guide on fixing color contrast (which is even harder to get right on mobile screens in direct sunlight) and our post on what WCAG is and how it applies to your site.