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)."
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. The Tool: Take a screenshot of the homepage of a popular mobile app on your phone.
- 2. The Import: Import that screenshot into Figma.
-
3.
The Measurement: Draw a bright red square that is exactly
44x44 pixels.
- 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).
- 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).
- 6. *Result:* You now have a mechanical tool to verify motor accessibility in mobile layouts.
11. Practice Exercises
- 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?
- 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?