Mobile Accessibility — Complete Guide

In this tutorial, you will learn about Mobile Accessibility. We cover key concepts, practical examples, and best practices to help you master this topic.

Mobile accessibility ensures touch interfaces, screen readers (TalkBack, VoiceOver), gestures, viewport settings, and responsive layouts work correctly for users with disabilities on smartphones and tablets.

What You'll Learn

• Mobile-specific accessibility challenges
• Touch target sizes and spacing
• Gesture accessibility and alternatives
• Mobile screen readers (TalkBack, VoiceOver)
• Viewport and zoom considerations
• Orientation and device posture

Why It Matters

• Over 60 percent of web traffic comes from mobile devices
• Mobile accessibility differs from desktop in significant ways
• Users with motor disabilities rely on mobile assistive features
• Google uses mobile-first indexing for search results

Real-World Use

• A banking app ensures touch targets are 44px minimum
• A news reader supports both portrait and landscape orientations
• A shopping app provides alternatives for swipe gestures
• A mobile game respects both left-handed and right-handed layouts

flowchart LR
  A[Mobile Accessibility] --> B[Touch Targets]
  A --> C[Gestures]
  A --> D[Screen Readers]
  A --> E[Viewport]
  B --> F[44x44 Minimum]
  C --> G[Alternate Input]
  D --> H[TalkBack, VoiceOver]
  E --> I[Zoom, Orientation]

Mobile Accessibility Fundamentals

Mobile accessibility is not just Responsive Design. It addresses how people with disabilities interact with touch screens, handle small screens, and use mobile assistive technologies.

Touch Target Size

The most common mobile accessibility failure is touch targets that are too small. WCAG 2.2 requires touch targets to be at least 24x24 CSS pixels, with 44x44 pixels recommended.

Code Example: Proper Touch Targets

<style>
    /* Ensure all interactive elements meet minimum touch target */
    .nav-link,
    .btn,
    .icon-button,
    input,
    select {
        min-height: 44px;
        min-width: 44px;
    }

    /* Spacing between touch targets */
    .nav-list {
        display: flex;
        gap: 8px;  /* Minimum 4px gap between targets */
    }

    /* List items with adequate spacing */
    .product-list li {
        padding: 12px 0;
        min-height: 44px;
    }

    /* Prevent accidental taps */
    .button-group {
        display: flex;
        gap: 12px;  /* Space between buttons */
    }

    /* Accordion headers as touch targets */
    .accordion-trigger {
        min-height: 44px;
        padding: 12px 16px;
        display: flex;
        align-items: center;
    }
</style>

<nav>
    <ul class="nav-list" style="display:flex; gap:8px; list-style:none; padding:0;">
        <li><a href="/" class="nav-link" style="display:inline-flex; align-items:center; padding:12px 16px;">Home</a></li>
        <li><a href="/products" class="nav-link" style="display:inline-flex; align-items:center; padding:12px 16px;">Products</a></li>
        <li><a href="/about" class="nav-link" style="display:inline-flex; align-items:center; padding:12px 16px;">About</a></li>
    </ul>
</nav>

Expected output: All links and buttons are at least 44px tall, making them easy to tap. The 8px gap prevents accidental taps on adjacent targets.

Gesture Accessibility

Some users cannot perform complex gestures like swiping, pinching, or multi-finger taps. Every gesture must have an alternative.

Code Example: Gesture Alternatives

<!-- Swipeable carousel with button alternatives -->
<div class="carousel" role="region" aria-label="Featured products" aria-roledescription="carousel">
    <button aria-label="Previous product" onclick="prevSlide()">
        <svg aria-hidden="true" width="24" height="24"><path d="M15 18l-6-6 6-6" fill="none" stroke="currentColor" stroke-width="2"/></svg>
    </button>

    <div class="carousel-content" aria-live="polite">
        <div class="slide" role="group" aria-roledescription="slide" aria-label="1 of 5">
            <!-- Product content -->
        </div>
    </div>

    <button aria-label="Next product" onclick="nextSlide()">
        <svg aria-hidden="true" width="24" height="24"><path d="M9 18l6-6-6-6" fill="none" stroke="currentColor" stroke-width="2"/></svg>
    </button>
</div>

<!-- Pull-to-refresh with button alternative -->
<div class="feed">
    <button onclick="refreshFeed()" aria-label="Refresh feed">
        <svg aria-hidden="true" width="20" height="20"><path d="M12 4V1L8 5l4 4V6c3.31 0 6 2.69 6 6s-2.69 6-6 6-6-2.69-6-6H4c0 4.42 3.58 8 8 8s8-3.58 8-8-3.58-8-8-8z"/></svg>
        Refresh
    </button>
    <!-- Feed items -->
</div>

Expected output: Users who cannot swipe can use Previous/Next buttons. Users who cannot pull-to-refresh can tap a Refresh button.

Mobile Screen Readers

VoiceOver (iOS) and TalkBack (Android) have different navigation patterns than desktop screen readers.

TalkBack gestures:

• Swipe right: Next element
• Swipe left: Previous element
• Double-tap: Activate
• Two-finger scroll: Scroll page

VoiceOver gestures:

• Swipe right: Next element
• Swipe left: Previous element
• Double-tap: Activate
• Three-finger swipe: Scroll page

Viewport and Zoom

The viewport meta tag must allow zooming. Disabling zoom violates WCAG:

<!-- BAD: prevents zoom - inaccessible -->
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

<!-- GOOD: allows zoom - accessible -->
<meta name="viewport" content="width=device-width, initial-scale=1.0">

Code Example: Orientation Support

<style>
    /* Support both orientations */
    .dashboard {
        display: grid;
        grid-template-columns: 1fr;
        gap: 1rem;
    }

    /* Landscape: two columns */
    @media (orientation: landscape) {
        .dashboard {
            grid-template-columns: 1fr 1fr;
        }
    }

    /* Portrait: single column, larger touch targets */
    @media (orientation: portrait) {
        .dashboard .action-button {
            min-height: 56px;  /* Larger for portrait usage */
            font-size: 1.1rem;
        }
    }

    /* Prevent forced orientation */
    /* Do NOT use: orientation: lock in manifest */
</style>

Expected output: The dashboard adapts to both portrait and landscape orientations. Touch targets are larger in portrait mode where one-handed use is common.

Common Mistakes

1. Disabling zoom with user-scalable=no — Users with low vision need to zoom. Never disable pinch-to-zoom.
2. Touch targets under 44px — Small links and buttons are frustrating to tap, especially for users with motor tremors.
3. Gesture-only interactions — Swipe-to-delete without a button alternative excludes users who cannot perform the gesture.
4. Forcing orientation — Some users cannot rotate their device or have it mounted in a fixed position. Support both orientations.
5. Hover-only interactions on mobile — Hover does not exist on touch devices. Use click/tap for all interactions.
6. Fixed headers that cover content — A fixed header can take up half the screen on mobile, obscuring content.
7. Poor mobile screen reader testing — Mobile screen readers behave differently from desktop. Always test on actual devices.

Practice Questions

1. What is the minimum recommended touch target size on mobile? 44x44 CSS pixels (WCAG recommends this, minimum is 24x24).
2. Why should you never disable user zoom on mobile? Users with low vision need to zoom to read content. Disabling zoom violates WCAG Success Criterion 1.4.4.
3. What are the two main mobile screen readers and their platforms? VoiceOver (iOS) and TalkBack (Android).
4. How do you support both portrait and landscape orientations? Use CSS media queries with orientation: portrait and orientation: landscape to adapt layouts.
5. Challenge: Audit a mobile website of your choice using TalkBack or VoiceOver. Find at least 5 mobile accessibility issues and document each with: the issue description, the WCAG criterion it violates, and the fix required.

FAQ

Mini Project

Build a mobile product listing page optimized for accessibility. The page must include: a product grid with touch targets of at least 44x44px (including add to cart buttons), a filter panel that slides in (with keyboard and touch support), swipeable product images with previous/next button alternatives, orientation support (single column portrait, two columns landscape), viewport that allows zoom, and a screen reader optimized product card announcing name, price, rating, and availability. Test with VoiceOver (iOS) or TalkBack (Android). Document all accessibility features and fixes.

What's Next

Continue with Lesson 23: Touch Targets and Pointer Accessibility to learn detailed guidelines for touch and pointer interaction design.