Skip to main content
Accessibility (A11y) – Complete Beginner to Advanced Guide
CHAPTER 10 Beginner

Accessibility in Mobile Apps

Updated: May 16, 2026
25 min read

# CHAPTER 10

Accessibility in Mobile Apps

1. Introduction

A desktop computer is a stable, controlled environment. The user is seated, the monitor is massive, and the mouse provides pixel-perfect precision. A mobile phone is chaos. The screen is tiny, the user is walking down a crowded street, sunlight is glaring off the glass, and they are navigating your interface with a blunt, imprecise thumb. Mobile Accessibility is not just about supporting users with permanent disabilities; it is about recognizing that every single mobile user operates in a state of constant situational impairment. In this chapter, we will master Accessibility in Mobile Apps. We will enforce strict mathematics for Touch Targets, design for the ergonomics of One-Handed Use, and understand how native OS screen readers (VoiceOver and TalkBack) fundamentally alter touch screen interactions.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Enforce the absolute minimum mathematical requirements for Touch Targets.
  • Design ergonomic, bottom-heavy interfaces for one-handed thumb navigation.
  • Ensure layouts survive Dynamic Type (user-forced 200% font scaling).
  • Understand the gesture mechanics of iOS VoiceOver and Android TalkBack.
  • Prevent accessibility failures caused by device orientation locks.

3. Touch Targets (The 44x44 Rule)

The human finger is not a laser pointer. If buttons are too small or placed too closely together, users with motor tremors (or someone simply walking while texting) will "fat-finger" the wrong button, causing massive frustration.
  • The iOS Standard (Apple HIG): Minimum touch target is 44x44 points.
  • The Android Standard (Material Design): Minimum touch target is 48x48 dp.
  • The WCAG 2.1 Standard: Minimum is 44x44 CSS pixels.
  • *The Crucial Detail:* The visible icon (like a tiny 'X') can be 16x16px, as long as the invisible, clickable bounding box *wrapping* the icon meets the 44x44 requirement.

4. Ergonomics and One-Handed Use

A significant percentage of mobile users navigate with one hand, supporting the phone with their fingers and swiping exclusively with their thumb.
  • The Reachability Zone: The bottom third of the screen is the "Green Zone" (easy to reach). The top left corner is the "Red Zone" (impossible to reach without readjusting grip or using a second hand).
  • The UX Mandate: Critical, high-frequency actions (like "Checkout", "Add Post", primary navigation) MUST be anchored to the bottom of the screen (e.g., Bottom Navigation Bars, Sticky Bottom CTAs). Placing the primary "Submit" button at the absolute top right corner of a massive iPhone Pro Max is a severe accessibility failure for motor-impaired and situational users.

5. Dynamic Type (Font Scaling)

Both iOS and Android allow users to go into their system settings and crank the global font size up to 200% or more.
  • The Failure: If your mobile app design uses strict, fixed-height boxes (e.g., setting a button height to exactly 50px), when the user cranks the font size up, the text will completely overflow the box and become unreadable.
  • The Fix: UI layouts must be liquid. You must use flexible containers (like Figma's Auto Layout set to "Hug Contents") so that if the text doubles in size, the container dynamically expands to hold it safely.

6. Mobile Screen Readers (VoiceOver & TalkBack)

When a blind user turns on VoiceOver (iOS) or TalkBack (Android), the physical mechanics of the touchscreen change entirely.
  • Standard swipe-to-scroll stops working.
  • The user drags their finger around the screen. As their finger crosses an element, the phone reads it aloud.
  • Once they find the button they want, they must Double-Tap anywhere on the screen to "click" it.
  • *The Design Impact:* Swiping left/right becomes the method to jump linearly between UI elements. If your app relies on a highly complex, custom multi-finger gesture (like "swipe with three fingers to delete"), a screen reader user cannot perform it. You must always provide a standard button alternative.

7. Diagrams/Visual Suggestions

*Visual Concept: The Thumb Reachability Map* Provide an outline of a large modern smartphone.
  • Bottom Arc (Green): A comfortable arc easily reached by the thumb originating from the bottom right corner. Label: "Natural Reach."
  • Middle Arc (Yellow): Requires slight hand stretching. Label: "Stretch."
  • Top Corner (Red): The top left quadrant. Label: "Inaccessible (Requires grip shift or two hands)."
This visual instantly justifies the necessity of Bottom Navigation Bars in modern app design.

8. Best Practices

  • Device Orientation: WCAG 2.1 Guideline 1.3.4 explicitly states that an application must not lock the screen orientation to just Portrait or just Landscape (unless absolutely necessary, like a piano app). Users with motor disabilities often have their devices permanently mounted in a fixed position on their wheelchair. Your app UI must dynamically rotate and reflow to accommodate them.

9. Common Mistakes

  • Hiding Actions Behind Hover: As discussed in previous chapters, there is no mouse cursor on a smartphone. A touchscreen cannot detect a "hover." If you hide the "Edit" or "Delete" buttons on a list item and assume they will appear when the user hovers over them, the mobile user will never see them. All actions on mobile must be explicitly visible or hidden behind an explicit "Tap" (like an [...] action menu).

10. Mini Project: Audit Touch Targets on Mobile

Let's measure the physical constraints.
  1. 1. The Tool: Take a screenshot of the homepage of a popular mobile app on your phone.
  1. 2. The Import: Import that screenshot into Figma.
  1. 3. The Measurement: Draw a bright red square that is exactly 44x44 pixels.
  1. 4. The Audit: Drag that red square over the interactive elements in the screenshot (the Hamburger menu, the profile icon, the tiny text links in the footer).
  1. 5. The Observation: Do the interactive elements comfortably fill the 44x44 box? If two links are stacked on top of each other, do their 44x44 boxes overlap? (If they overlap, a user with tremors will hit the wrong one).
  1. 6. *Result:* You now have a mechanical tool to verify motor accessibility in mobile layouts.

11. Practice Exercises

  1. 1. Define the mathematical WCAG and Apple HIG standards for "Touch Targets" on mobile interfaces. Why is it acceptable for the visual icon (like an 'X') to be 16x16px, as long as the invisible bounding box is larger?
  1. 2. Explain the UX necessity of "Dynamic Type" (system-level font scaling) on iOS and Android. How must a UI designer architect their components in Figma to ensure the layout does not break when a low-vision user increases the system font size by 200%?

12. MCQs with Answers

Question 1

According to Apple Human Interface Guidelines (HIG) and standard WCAG recommendations, what is the absolute minimum acceptable size for an invisible, clickable bounding box (Touch Target) to ensure a mobile app is accessible to users with motor tremors?

Question 2

When a blind user activates VoiceOver on iOS or TalkBack on Android, the physical behavior of the touchscreen fundamentally changes. How does the user "Click" a button while using a mobile screen reader?

13. Interview Questions

  • Q: A client wants to put the primary "Submit Order" button at the absolute top right corner of a mobile checkout screen because it looks "unconventional and clean." Walk me through the ergonomic arguments you would use to move that button to the bottom of the screen, referencing the "Thumb Reachability Map."
  • Q: Explain why relying on complex, custom multi-finger gestures (like "Swipe left with two fingers to delete") is an accessibility failure. How do native mobile screen readers (like VoiceOver) conflict with these custom gestures?
  • Q: Walk me through the concept of "Situational Impairment" specifically regarding mobile devices. How does designing high-contrast interfaces with massive touch targets for visually impaired users simultaneously solve problems for non-disabled users?

14. FAQs

Q: Do I need to design a separate app for landscape mode? A: You don't need a separate app, but you must ensure your UI uses fluid grids and flexible components (Auto Layout) so that when the device rotates sideways, the content stretches and reflows logically without cutting off critical information or trapping the user.

15. Summary

In Chapter 10, we descended into the chaos of the mobile environment. We acknowledged that the smartphone screen is fraught with situational and physical impairments. We abandoned the precision of the mouse, enforcing the strict 44x44px Touch Target mathematics required to accommodate the blunt human thumb and motor tremors. We studied the ergonomics of one-handed use, anchoring our critical actions to the bottom "Green Zone" to prevent physical strain. By respecting the transformative power of Dynamic Type and native screen readers, we ensure our mobile applications bend, scale, and adapt to the specific biological realities of the human holding the glass.

16. Next Chapter Recommendation

We have secured the foundation. Now we must secure the pathways users take to navigate that foundation. Proceed to Chapter 11: Accessible Navigation and Menus.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·