Mobile App Accessibility Testing: Step-by-Step Guide

This guide walks you through testing a mobile app for accessibility, covering both Android and iOS. You’ll learn how to check screen reader compatibility, touch target sizes, color contrast, and more, so you can find and fix barriers that affect users with disabilities. No special hardware is needed—just your development device and a few free tools.

What You’ll Need

A mobile device (Android or iOS) with the app installed in a debug or test build.
USB cable to connect the device to your computer (for some tools).
Android Studio (for Android testing) or Xcode (for iOS testing) installed on your computer.
Accessibility scanner apps: Accessibility Scanner (Android) or Xcode Accessibility Inspector (iOS). Both are free.
A screen reader: TalkBack (Android) or VoiceOver (iOS), both built into the operating systems.
Optional: a physical keyboard to test keyboard navigation.

Step-by-Step

Set up your device for testing. On Android, go to Settings > Accessibility > TalkBack and turn it on. On iOS, go to Settings > Accessibility > VoiceOver and enable it. Keep the screen reader on for the entire test session.
Run the automated scanner first. On Android, install the Accessibility Scanner app from the Play Store, open it, and tap the floating “Scan” button while your app is open. On iOS, open your app in Xcode, then launch the Accessibility Inspector from the Xcode menu (Xcode > Open Developer Tool > Accessibility Inspector). Review the list of issues it finds—these often include low contrast, small touch targets, and missing content descriptions.
Test screen reader navigation. With TalkBack or VoiceOver on, swipe right (or left) to move focus through every element on each screen. Verify that each element is announced in a logical order, that buttons and links have clear labels, and that images have meaningful descriptions (or are marked as decorative if they convey nothing).
Check all interactive elements. Tap every button, switch, slider, and text field using the screen reader’s double-tap gesture. Confirm that each control performs its expected action and that the focus lands on the correct element after the action (e.g., after submitting a form, focus should move to the confirmation message, not stay on the button).
Test touch target sizes. Using the Accessibility Scanner (Android) or Accessibility Inspector (iOS), look for warnings about touch targets smaller than 48×48 dp (Android) or 44×44 pt (iOS). Manually try tapping each target with a finger—if you miss often, it’s too small. Increase padding or make the hit area larger.
Verify color contrast. Use the contrast checker built into the Accessibility Scanner or a free web tool like WebAIM’s Contrast Checker. For normal text, the contrast ratio between text and background must be at least 4.5:1; for large text (18pt or 14pt bold), it’s 3:1. Test both light and dark mode if your app supports them.
Test with dynamic type and font scaling. On iOS, go to Settings > Accessibility Display & Text Size > Larger Text and slide the size to the maximum. On Android, go to Settings > Accessibility > Font size and set it to the largest. Open your app and check that text doesn’t get cut off, overlap, or cause buttons to become unusable.
Test orientation and screen rotation. Rotate your device between portrait and landscape. Ensure all content remains accessible, no controls are hidden, and the screen reader focus stays on the correct element after rotation.
Test with a physical keyboard (optional but recommended). Connect a Bluetooth or USB keyboard. On Android, press Tab to move focus, Enter to activate, and arrow keys to navigate lists. On iOS, enable Full Keyboard Access in Settings > Accessibility > Keyboard. Verify that every interactive element can be reached and activated without touching the screen.
Listen for screen reader announcements during dynamic changes. Trigger any loading spinners, error messages, or content that updates without a page reload. The screen reader should announce these changes (e.g., “Loading,” “Error: invalid email”). If not, you’ll need to add live regions (Android) or accessibility announcements (iOS) in code.
Test forms and input fields. Tap each text field and verify the screen reader announces the label, the input type (e.g., “email address”), and any placeholder text. Check that error messages are announced and that the focus moves to the first invalid field when submitting.
Document your findings. For each issue, note the screen, the element, the exact problem, and the severity (critical, major, minor). Include a screenshot or screen recording. Share this report with your development team.

Common Mistakes

Testing only with the automated scanner. Automated tools miss many issues, such as confusing screen reader order or unclear labels. Always combine automated scans with manual screen reader testing.
Ignoring the screen reader order. The visual order on screen is not always the logical reading order. Swipe through your app with the screen reader and fix any elements that are announced out of sequence.
Using unlabeled icons. An icon button without a content description is announced as “unlabeled button” or just “button”—useless for screen reader users. Every icon needs a text label.
Forgetting about landscape mode. Many apps work fine in portrait but break in landscape, with elements overlapping or being pushed off-screen. Always test both orientations.
Testing only on one platform. Android and iOS handle accessibility differently. An app that’s accessible on iOS may have serious issues on Android, and vice versa. Test on both if your app supports both.
Skipping the keyboard test. Some users navigate with a switch device or keyboard, not touch. If your app can’t be operated without a touchscreen, those users are locked out.

Tips

Start testing early. Fixing accessibility issues during development is much cheaper than fixing them after release. Run a quick accessibility check with every build.
Use real device testing. Simulators and emulators don’t always replicate the exact behavior of screen readers on physical hardware. Test on at least one real device per platform.
Learn the screen reader gestures. To test effectively, you need to know how to navigate with TalkBack or VoiceOver. Practice on a simple app first, like the Settings app.
Check the accessibility tree. In Android’s Layout Inspector or iOS’s Accessibility Inspector, you can see the accessibility hierarchy. This helps you understand what the screen reader “sees” and why it announces things in a certain order.
Test with real users when possible. Automated checks and your own manual testing are valuable, but nothing beats feedback from people who actually use screen readers daily. If you can, recruit a few testers with disabilities.
Keep a checklist. Create a reusable checklist based on the steps above. This ensures you don’t forget any part of the test when you’re in a hurry.

Troubleshooting

The screen reader doesn’t announce anything. Check that TalkBack or VoiceOver is actually on (look for the focus outline on the screen). Also, verify that your app isn’t setting importantForAccessibility="no" (Android) or accessibilityElementsHidden="YES" (iOS) on the entire screen by mistake.
The screen reader announces “unlabeled” for a button that has visible text. The text may be inside a separate TextView that isn’t linked to the button. In code, set the button’s content description to the text, or combine the elements into a single clickable container.
Focus jumps around randomly when swiping. This usually means the accessibility order is not defined. On Android, set accessibilityTraversalBefore or After properties; on iOS, use accessibilityElements array to define the order.
Touch targets are too small but you can’t increase the visual size. You can enlarge the touch area without changing the visual appearance by adding invisible padding or increasing the touchTarget property (Android) or using accessibilityFrame (iOS).
Color contrast fails but you can’t change the colors. Consider adding a text shadow, a background overlay, or making the text bold. Sometimes increasing font weight alone can push the contrast ratio above the threshold.
The app crashes when TalkBack is on. This is often caused by a custom view that doesn’t handle accessibility events properly. Check the logcat (Android) or console (iOS) for errors related to accessibility, and test the custom view in isolation.

Frequently Asked Questions

Q: Do I need to test both Android and iOS if I only have one device?
A: Yes, if your app runs on both platforms. Each platform has its own screen reader and accessibility APIs, and issues are often platform-specific. If you can’t test both, prioritize the platform your primary audience uses, but clearly document that the other platform is untested.

Q: What is the minimum touch target size?
A: Google recommends 48×48 dp (about 9mm) for Android, and Apple recommends 44×44 pt for iOS. These sizes are based on average finger width. Smaller targets are harder to hit, especially for users with motor impairments.

Q: How do I test color contrast if my app uses gradients or images as backgrounds?
A: The contrast ratio should be measured between the text and the actual background behind it. For gradients, test the darkest and lightest points. For images, test the area where the text sits. Many design tools have a contrast checker that can sample specific pixels.

Q: Can automated tools replace manual testing?
A: No. Automated tools catch about 30-40% of accessibility issues. They can’t judge whether a screen reader announcement makes sense, whether the focus order is logical, or whether a custom gesture is discoverable. Manual testing with a real screen reader is essential.

Q: What should I do if my app uses a custom gesture (like swipe to delete)?
A: Provide an alternative accessible action. For example, add a visible “Delete” button that appears when the item is focused, or support a screen reader-specific action like “Activate” to reveal options. Never rely on a single gesture as the only way to perform an action.

Q: How often should I run accessibility tests?
A: Ideally, run a quick automated scan with every build, and do a full manual screen reader test before every major release. Accessibility regressions are common when new features are added, so regular testing is the only way to keep the app accessible.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →