This mobile app accessibility checklist is the pre-launch pass we run on every app before it goes to the store: a screen-reader pass with VoiceOver and TalkBack, a contrast check that holds up on a real phone in daylight, and a tap-target review that catches the buttons users keep missing. If you are a founder, product manager, or lead developer with a launch date approaching, it will help you find the failures automated scanners miss — while fixes are still cheap.
Accessibility is often treated as polish for after launch. In practice it is a launch-quality issue: an app a blind user cannot navigate, a low-vision user cannot read, or a user with a motor impairment cannot operate is not finished, And fixes get expensive once the app is live.
Mobile app accessibility checklist: the VoiceOver and TalkBack pass
Start with the screen reader, because it exposes the largest class of launch-blocking problems in the shortest time. Turn on VoiceOver on an iPhone and TalkBack on an Android device, close your eyes, and try the core journey: sign in, find the main feature, complete the key action, and get back. If you cannot do that by listening alone, neither can a blind user, and no visual polish compensates.
Work through these checks screen by screen. First, every interactive element needs a clear, unique label. Icon-only buttons are the most common failure: a share, filter, or close icon with no label is announced as just ‘button’, which tells the user nothing. Give each one a short verb label such as ‘Share article’ or ‘Close dialog’. Second, hide decorative images from the screen reader rather than letting them be announced with a filename. Third, avoid duplicate labels: five buttons all announced as ‘More’ force the user to guess, so qualify them with context, for example ‘More options for this order’.
Next, check reading order and structure. Headings should mark screen sections so a VoiceOver user can jump between them, and swipe order should follow the visual layout rather than jumping from a footer button back to the top. Custom components are where this breaks: a hand-built tab bar, carousel, or bottom sheet often reports itself as one meaningless element, or traps focus so the user cannot swipe out. Test any custom control with the screen reader on before testing anything else about it. Finally, test dynamic content: when a form submits or an error appears, the screen reader should announce it — a silent failure after tapping ‘Pay’ leaves the user unsure whether payment went through.
Test on both platforms, not one. VoiceOver and TalkBack differ in gestures and label handling, and a component that works on iOS can be unusable on Android — so test on real devices, where screen-reader behaviour differs from a simulator. For the standards, the Web Content Accessibility Guidelines (WCAG) set the conformance targets, and Apple’s Human Interface Guidelines on accessibility cover iOS-specific expectations.
Contrast that survives a real phone
Contrast failures are the most common accessibility defect in shipped apps, and the easiest to check, so there is no excuse for launching with them. The WCAG 2.2 AA bar is 4.5:1 for normal text and 3:1 for large text, with icons and focus indicators held to 3:1. Measure the actual colours in your build, not the design file.
Check both themes. An app passing in light mode frequently fails in dark mode, where a muted grey fine on white becomes nearly invisible on black. Check both again with high-contrast and bold-text settings on. Then take the phone outside: sunlight on a glossy screen is the harshest contrast test your app will face, and much real usage happens there. If prices or error messages wash out in daylight, the ratio is too close to the line even if a tool reports a pass.
Two further rules catch teams out. First, never use colour alone to convey meaning: an error shown only as red text fails for colour-blind users, so pair it with an icon and words, and label chart series rather than distinguishing them by colour only. Second, make focus visible: keyboard, switch, and screen-reader users need a clear indicator of where they are, and a faint or missing focus ring on custom controls makes an app unnavigable even when every label is correct.
Tap targets, spacing, and gestures
Tap targets are where good-looking apps most often fail real hands. Apple recommends 44 by 44 points and Google recommends 48 by 48 density-independent pixels; WCAG 2.2 AA sets a floor of 24 by 24 CSS pixels, with 44 by 44 as the enhanced AAA target. Treat the platform numbers as your build target and the WCAG floor as the minimum you never ship below. The practical rule: if you cannot reliably hit a control with your thumb, one-handed, on a moving bus, it is too small.
Size alone is not enough; spacing matters just as much. Two 44-point targets jammed together with no gap produce almost as many mis-taps as one small target, because the finger lands on the boundary. Give adjacent targets breathing room, and remember the visual size of an icon is not its hit area: a 20-point icon inside a 44-point padded button is fine, while a 20-point icon that is itself the button is not. Expanding the invisible tappable area around a small icon is the standard fix, costing nothing in layout terms.
Then audit gestures. Every swipe, pinch, long-press, or multi-finger action needs a single-tap alternative — for users with motor impairments, users holding a child, and switch-control users who depend on it. Watch carousels, swipe-to-delete rows, pull-to-refresh, and drag-to-reorder lists: each is a classic place where an app works for able-bodied testers and is partly unusable for everyone else. Where a gesture is genuinely the feature, such as a drawing canvas, still provide buttons for the actions around it, like zoom and confirm.
Text size, motion, and focus order
An app that only works at its default text size is not finished. Switch on the largest Dynamic Type size on iOS and the largest font size on Android, then walk every screen: text must scale, containers must grow, and nothing important may be clipped or pushed off-screen. The usual casualties are tab-bar labels, prices in cards, and fixed-height buttons; the fix is almost always to let layouts grow instead of fixing heights in points.
Motion deserves the same pass. Respect Reduce Motion: parallax backgrounds, auto-playing carousels, and animated transitions should calm down or stop when the user asks for less motion. Flashing content is a harder line — anything flashing more than three times per second is a seizure risk and must not ship. Auto-playing video needs a pause control and captions.
Finally, verify focus order and keyboard access. External keyboards, switch devices, and screen-reader swipe order all follow it, so focus should move logically through a screen, never jump to a hidden element, and never get trapped inside a dialog or bottom sheet. Every action reachable by touch must be reachable without touch.
From our experience: where teams actually fail
Across the apps we have built and audited over 9+ years and 300+ projects, the same four failures account for most pre-launch accessibility rework. The first is bolting accessibility on at the end: retrofitted labels, focus order, and dynamic-type support touch every screen twice, while built into the component library from the start, each new screen inherits them for free. If your team is mid-build, fix the shared components — buttons, cards, dialogs, tab bars — before polishing individual screens.
The second failure is trusting the automated scanner. Scanners are genuinely useful — they catch missing labels, contrast ratios, and tiny targets across hundreds of screens in minutes, and we run them on every build. But they cannot tell you whether a label makes sense, whether swipe order matches the visual layout, or whether an error announcement reaches the user. Treat a clean scanner report as the start of testing, not the end. The third failure is third-party SDKs: vendor payment sheets, chat widgets, and authentication screens often carry their own defects on your most critical flows. Test vendor screens with the screen reader on and raise defects early, because you cannot fix their code from your side.
The fourth failure is the one nobody budgets for: store review and legal exposure. Apple and Google treat accessibility as part of app quality, and an app unusable with a screen reader risks rejection at the worst possible moment — launch week. Beyond the stores, accessibility law increasingly reaches mobile apps: the European Accessibility Act now applies to many digital services sold in the EU, and ADA-related claims in the US have long since moved past websites to apps. This checklist is not optional polish; it is part of shipping a professional product. If you need help running it, our mobile app development team runs this pass as part of every launch.
The pre-launch run sheet
Hand this sequence to whoever tests the release candidate. It takes a focused tester roughly half a day for a typical consumer app.
- Run the automated scanner on the release build and clear every error.
- With VoiceOver on, complete the core journey without looking at the screen.
- Repeat the core journey with TalkBack on an Android device.
- Check every screen at the largest text size, in both themes, with bold text on.
- Measure contrast on text, icons, and focus indicators in both themes.
- Thumb-test every primary control one-handed; expand any hit area below 44 points (iOS) or 48 dp (Android).
- Confirm every gesture has a single-tap alternative and no dialog traps focus.
- Switch on Reduce Motion; verify animations calm down and nothing flashes.
- Test error states: submit an invalid form and a failed payment; confirm the screen reader announces both.
- Record defects with the screen, the assistive technology, and exact reproduction steps.
Do not waive failures silently. If a defect cannot be fixed before launch, record it as a known limitation with an owner and a date — and never let one sit on sign-up, checkout, or payment, where it decides whether some users can become customers at all.
Frequently asked questions
How long does a mobile accessibility pass take before launch?
For a typical consumer app, a focused pass takes about half a day of testing plus the fix time it uncovers. A first pass on a never-tested app usually finds a day or two of fixes. Apps that build accessibility into shared components from the start find far less — which is why the cheapest time to do this work is during development, not the week before launch.
Do I need to test with both VoiceOver and TalkBack?
Yes. VoiceOver and TalkBack differ in gestures, label handling, and how custom components are exposed, so a screen that works on one platform can fail on the other. Test the core journey on both, on real devices.
What contrast ratio does my app need?
Aim for WCAG 2.2 AA: at least 4.5:1 for normal text, 3:1 for large text, and 3:1 for icons and focus indicators. Measure shipped colours in both themes, and re-check with bold text and high-contrast settings on.
Are 44-point and 48 dp tap targets mandatory?
They are the platform recommendations from Apple and Google, and the target you should build to. WCAG 2.2 AA only requires 24 by 24 pixels as a floor, but that floor is a compliance minimum, not a usability target. Building to 44 points on iOS and 48 dp on Android satisfies both.
Accessibility is not a separate feature competing with your roadmap; it is the quality bar that decides whether what you built is usable by everyone you built it for. Run this mobile app accessibility checklist on your release candidate, fix what it finds, and ship an app that works for your whole audience. If you would like a second pair of eyes, talk to us — we run this pass on client apps every week.