Mobile app accessibility,
built in from the first screen.
Real mobile app accessibility means a blind user can finish checkout with VoiceOver, a low-vision user does not miss a button they are aiming for, and a screen reader on Android reads your interface in the right order. It is not a checkbox you tick after launch, it comes down to a handful of concrete requirements: the WCAG 2.2 success criteria that actually apply to mobile, correct VoiceOver and TalkBack labeling, and touch targets sized for real fingers. If you have not settled on your app’s visual design yet, read mobile app design basics first, accessibility is far easier to build in from the start than to retrofit later.
The short version
Three requirements, not fifty.
Mobile app accessibility guidelines can look like an endless list, but the part that actually changes whether a screen reader user can complete your app comes down to three things: every interactive element has a clear, accurate label; every tappable target is large enough to hit reliably (44×44pt on iOS, 48×48dp on Android); and nothing in the app requires a specific gesture, color, or precise timing with no alternative.
WCAG 2.2 formalizes those requirements into testable success criteria, VoiceOver and TalkBack are how iOS and Android actually expose them to a screen reader user, and the rest of this guide walks through both, plus a checklist you can run before you ship. None of it requires a separate mobile accessibility app or plugin, it is a property of how you build the one you already have.
The standard
WCAG 2.2 AA: what mobile actually needs.
WCAG 2.2, published by the W3C, added nine new success criteria on top of WCAG 2.1. Four of them are Level AA and speak directly to how a phone gets used: touch, drag, a connected keyboard, and login. These are the ones worth checking against a mobile app specifically.
| Criterion | Name | Level | What it requires |
|---|---|---|---|
| 2.5.7 | Dragging Movements | AA | Anything operated by a drag also has a single-tap or single-pointer alternative. |
| 2.5.8 | Target Size (Minimum) | AA | Pointer targets are at least 24 by 24 CSS pixels, with narrow exceptions for spacing, inline, and essential cases. |
| 2.4.11 | Focus Not Obscured (Minimum) | AA | A focused control is not fully hidden behind other content, relevant once someone connects a Bluetooth keyboard to a phone or tablet. |
| 3.3.8 | Accessible Authentication (Minimum) | AA | Login does not force a memory or puzzle-solving test unless an accessible alternative (like biometric or a paste-friendly password field) exists. |
Source: W3C, Understanding Target Size (Minimum)
Target Size (Minimum): the one that trips up most apps
Success Criterion 2.5.8 says a pointer target must be at least 24 by 24 CSS pixels, with exceptions for targets that are spaced far enough apart, inline in a sentence, essential to a legally required layout (a map pin, for instance), or already controlled by the user agent rather than your app.
Where this shows up
Icon-only buttons in a dense toolbar, close (×) buttons on a modal, and row actions in a list are the usual offenders, because the visible icon is often 16 to 20px while the actual tappable area is exactly that size, with no padding around it.
In practice
Five mistakes, and the fix.
Each of these traces back to one of the criteria above. Seeing them as a concrete before-and-after is usually faster than re-reading the success criterion.
| Mistake | Why it fails | Fix |
|---|---|---|
Icon-only button with no label | VoiceOver and TalkBack both read it as just “button,” with nothing to say what it does | Set accessibilityLabel (iOS) or contentDescription (Android) to a clear action, like “Delete item” |
16px close (×) icon with no padding | The tappable area is exactly 16px, under the 24×24 WCAG floor and well under 44pt / 48dp | Pad the touch area to at least 44×44pt / 48×48dp; the icon itself can stay small |
A card that only responds to swipe-to-delete | WCAG 2.5.7 (Dragging Movements) requires a non-drag alternative for anything operated by a drag | Add a visible action, a menu item or a long-press button, that does the same thing |
Light gray body text on a white card | Falls under the 4.5:1 AA contrast floor for body text, unreadable in bright light | Darken the text or background until a contrast checker shows at least 4.5:1 |
A puzzle or transcription step as the only way to log in | WCAG 2.2's Accessible Authentication criterion flags a login with no non-cognitive alternative | Offer biometric login (Face ID / fingerprint) or a standard password field alongside it |
Screen readers
VoiceOver vs. TalkBack: how they actually behave.
VoiceOver is Apple’s built-in screen reader, TalkBack is Google’s. Both are built around the same core pattern, swipe to move, double-tap to activate, but the exact gestures and how you reach them differ enough that testing on one platform tells you almost nothing about the other.
| VoiceOver (iOS) | TalkBack (Android) | |
|---|---|---|
| Turn it on | Settings > Accessibility > VoiceOver, or a triple-click of the side button once configured | Settings > Accessibility > TalkBack |
| Explore the screen | Drag one finger slowly around the screen; VoiceOver speaks whatever it passes over | Drag one finger slowly around the screen; TalkBack announces each item it passes over |
| Move to next / previous item | Swipe right for the next item, swipe left for the previous one | Swipe right for the next item, swipe left for the previous one |
| Activate the selected item | Double-tap anywhere on the screen to activate the selected item | Double-tap anywhere on the screen to activate the selected item |
| Read the whole screen | Two-finger swipe up to read the whole screen from the top | Swipe up then down (or use the reading-controls menu) to read continuously |
| Adjust a slider | With a slider selected, swipe up or down with one finger to change its value | With a slider selected, swipe up or down with one finger to change its value |
Sources: Apple Support, Learn VoiceOver gestures on iPhone and Google, Navigate your device with TalkBack
- Turn on: Settings > Accessibility > VoiceOver, or a triple-click of the side button once configured
- Move around: Swipe right for the next item, swipe left for the previous one
- Activate: Double-tap anywhere on the screen to activate the selected item
Touch targets
Minimum touch target sizes, iOS and Android.
Three sources, three numbers, and none of them are identical. Design to the largest one that applies to your platform and every other number falls in line underneath it.
WCAG 2.2 AA minimum (Target Size, Success Criterion 2.5.8)
Apple's Human Interface Guidelines recommended minimum, iOS
Android's accessibility guidelines and Material Design 3 minimum
On Android, Google’s own accessibility documentation is explicit: “for touch interfaces, we recommend that each interactive UI element have a focusable area, or touch target size, of at least 48dp x 48dp. Larger is even better,” and notes that many built-in Material components already enforce this. On iOS, Apple’s Human Interface Guidelines put the equivalent floor at 44 by 44 points for any tappable control. Both numbers are far easier to honor on the mobile app wireframe than in a finished layout: a 48dp box drawn at the sketch stage rarely shrinks later, whereas a 24px icon placed without padding almost always has to be fixed after the fact.
In React Native, one of the most common frameworks for native mobile apps, this usually means padding the touch area rather than resizing the icon itself, and setting accessible and accessibilityLabel on the pressable component so VoiceOver and TalkBack both read it correctly, neither platform infers a good label from an icon alone.
None of this is limited to the phone in someone’s hand, either. If your product ships a companion wear os app, the same labeling and target-size rules apply there too, just on a screen with even less room for a mis-sized button.
Try it
Check your contrast, live.
Pick a foreground and background color, or start from a preset, and this computes the real contrast ratio using the same relative-luminance formula the standard does, then checks it against the 4.5:1 and 3:1 AA thresholds already covered above.
Contrast ratio
Testing
Mobile app accessibility testing, five passes.
None of these require special equipment, just the phone in your pocket and the settings screen you have probably never opened.
- 1
Turn on the platform screen reader and go label-hunting
Enable VoiceOver on an iPhone and TalkBack on an Android device (a simulator works, but a real device catches more). Swipe through every screen in your core flow. Any element that reads as “button” with no further description, or gets skipped entirely, needs a real accessibilityLabel or contentDescription.
- 2
Try to complete your main flow blind
Close your eyes, or turn the screen brightness down, and complete sign-up or checkout using only swipes and double-taps. Every place you get stuck, an icon with no label, a target you keep missing, a step that only makes sense visually, is a real bug, not an edge case.
- 3
Check contrast on your actual text and backgrounds
Run your real color pairs, not your design system's defaults, through a contrast checker. Body text under 18pt (or bold text under 14pt) needs a 4.5:1 ratio; larger text needs 3:1. Gradients and photos behind text are the most common place this quietly fails.
- 4
Turn the system font size all the way up
iOS Settings > Accessibility > Display & Text Size > Larger Text, or Android Settings > Accessibility > Font size, set to maximum. Reload every screen. Text that clips, buttons that overlap, or labels that get cut off at large sizes will affect real low-vision users daily, not just at the extreme setting.
- 5
Measure your smallest tap targets
Screenshot your densest screen, icon rows, tab bars, close buttons, and check the tappable area (not just the icon itself) against 44pt on iOS or 48dp on Android. A 24px icon centered in a 48dp touch area passes; the same icon with no padding around it does not.
Check your work
Run this before you ship.
Check off each line as it is genuinely true of your app. It is not a formal audit or a substitute for testing with real assistive-technology users, just a way to catch the obvious gaps before launch.
What’s next
Accessibility is one pass, not the whole QA process.
So what is left once the accessibility pass comes back clean? Quite a lot: functional bugs, performance on real devices, crash-free sessions, and the App Store and Google Play submission requirements that reviewers check independently of anything WCAG says. Newly’s guide to testing your app before launch covers that wider pre-launch process, with this pass as one line item inside it.
Where Newly fits
A native foundation, not a shortcut.
Newly is an AI app builder, from $25 a month: you describe the app you want and it generates a real, native iOS and Android app built on React Native and Expo, not a webview or a mockup. That matters for accessibility because standard native components already speak to VoiceOver and TalkBack correctly by default, you are not fighting a custom-rendered canvas that neither screen reader understands.
What generation does not do on its own is choose good labels or generous touch targets, that still takes a deliberate pass, in your prompt or afterward, the same as it would in any other codebase.
FAQ
Mobile app accessibility, answered.
Mobile app accessibility means someone using a screen reader like VoiceOver or TalkBack, a switch control, voice control, or just a shaky hand on a crowded train, can still use every feature of your app. In practice it comes down to three things: every interactive element has a clear accessible label, touch targets are large enough to hit reliably, and the app can be operated without relying on a specific gesture, color, or exact timing. WCAG 2.2 is the technical standard that defines these requirements precisely.
Build it accessible the first time.
See what real, native apps built with Newly look like, then describe yours with accessibility in mind from the first prompt.