How to Test Mobile App Accessibility Manually: A Step-by-Step Guide
How to Test Mobile App Accessibility Manually: What Automated Tools Will Never Catch
Automated accessibility testing tools are useful. They catch missing labels, low contrast, and undersized touch targets quickly and consistently. But they have a hard ceiling — most tools identify somewhere between 30 and 40 percent of real accessibility issues.
The rest only show up when a human navigates the app. Mobile app accessibility testing manual processes are not a supplement to automated tools — they are the core of any credible accessibility evaluation. This guide explains what manual testing looks like, what to check on each platform, and how to structure the process so nothing important gets missed.
Why Manual Testing Is Non-Negotiable
Automated tools evaluate code structure. They cannot evaluate experience.
They can confirm that a button has a content description. They cannot tell you whether that description makes sense to a screen reader user in context. They can flag a color contrast failure. They cannot evaluate whether a form’s error flow is navigable when a keyboard replaces a touchscreen.
The failures that cause the most friction for users with disabilities — broken focus order, silent state changes, inaccessible custom components, gestures with no keyboard alternative — are almost never caught by automated scanning. These require a human tester who understands assistive technology behavior and knows what a good experience feels like versus a broken one.
Setting Up for Manual Accessibility Testing
Before testing begins, set up the test environment correctly. Poor setup is the most common reason manual testing misses issues that later surface in user reports.
Devices: Test on physical hardware, not emulators or simulators. TalkBack and VoiceOver behavior, focus timing, and announcement patterns differ between real devices and emulated environments in ways that matter. Use at least one mid-range device — not just a flagship — since performance differences can affect accessibility behavior.
Platform coverage: Test on both iOS and Android if the app is cross-platform. Accessibility APIs differ between platforms, and a component that works correctly with VoiceOver may behave differently with TalkBack, or vice versa.
Assistive technology versions: Check which version of TalkBack or VoiceOver is installed on your test device. Screen reader behavior has changed meaningfully across versions and testers should document the version used so results can be reproduced.
Test accounts: Use test accounts that reflect real user states — logged in, logged out, with notifications, with partially completed forms. Accessibility issues often only appear in specific states.
Manual Testing with Screen Readers
Screen reader testing is the highest-priority element of mobile app accessibility testing manual processes, because it reveals how the app behaves for blind and low-vision users who cannot see the screen at all.
Testing with VoiceOver (iOS)
Enable VoiceOver at Settings > Accessibility > VoiceOver, or use the triple-click shortcut if configured.
Navigate through every screen of the app using only VoiceOver gestures:
- Swipe right to move focus forward through elements
- Swipe left to move backward
- Double-tap to activate
- Use the rotor (two-finger rotation gesture) to switch between navigation modes
What to check on each screen:
Every interactive element must have a meaningful label. An icon-only button must announce what it does, not just “button.” A product image in a shopping app must announce the product name, not “image.”
Focus order must match the logical reading sequence. If focus jumps from a headline to a footer link before reaching the body content, the reading order is broken. This often happens in complex layouts with overlapping views or absolute positioning.
State changes must be announced. When a user marks an item as favorite and the icon changes, VoiceOver must announce the new state — “Added to favorites.” Silent visual updates are inaccessible to screen reader users.
Modals and overlays must trap focus. When a dialog opens, focus should move into it and stay there until the dialog is dismissed. If focus can escape a modal, screen reader users can end up interacting with content behind it.
Testing with TalkBack (Android)
Enable TalkBack at Settings > Accessibility > TalkBack, or use the volume-key shortcut.
The navigation model is similar to VoiceOver — swipe to move focus, double-tap to activate — but the announcement patterns and focus behavior differ in platform-specific ways.
Key differences to check on Android:
Content descriptions on Android use the contentDescription attribute. Test that every image, icon button, and decorative element is either correctly labeled or correctly hidden from TalkBack.
Custom views that extend View rather than standard Android widgets have no built-in accessibility support. These need to be tested carefully — they often have zero TalkBack interaction by default.
Live regions — areas of the screen that update dynamically, like a progress indicator or a loading status — must be marked with accessibilityLiveRegion so TalkBack announces the change without requiring the user to navigate back to that element.
Manual Testing with Voice Control
Voice control testing — Voice Control on iOS, Voice Access on Android — tests whether the app can be operated entirely by voice command.
The core test is straightforward: activate voice control, display labels, and attempt to activate every interactive element by speaking its label name. Any element that cannot be activated by voice because its label does not match what a user would naturally say is a failure.
Get BarrierBreak’s stories in your inbox
Join Medium for free to get updates from this writer.
Common issues that only surface during voice control testing:
- Buttons labeled with internal identifiers rather than visible text (“btn_primary” instead of “Submit”)
- Multiple elements with identical labels on the same screen, making voice commands ambiguous
- Elements that respond to touch but are not recognized as interactive by the voice control overlay
Manual Testing with External Keyboards
Switch control users and users with motor impairments who connect Bluetooth keyboards to their devices navigate apps using keyboard commands rather than touch gestures.
Connect a Bluetooth keyboard and attempt to navigate through the entire app using Tab to move forward, Shift+Tab to move backward, and Enter or Space to activate elements.
What to check:
Every interactive element must be reachable by keyboard navigation. Elements that can be tapped but are not in the keyboard tab order are inaccessible to keyboard users.
Focus indicators must be visible. The currently focused element must have a visual indicator that distinguishes it from unfocused elements. Many apps suppress the default focus ring, leaving keyboard users with no way to track their position on screen.
No keyboard trap must exist. Users must be able to navigate away from every component using only the keyboard. Custom dropdowns, date pickers, and modal dialogs are the most common places keyboard traps appear.
Manual Testing for Text Scaling and Display Settings
A frequently overlooked element of mobile accessibility testing is verifying how the app responds to system-level display settings.
Test with the largest system font size enabled — including the five Accessibility Text Sizes available on both iOS and Android. Check that:
- Text scales rather than clipping or truncating
- Layouts reflow rather than causing elements to overlap
- Containers expand to accommodate larger text rather than cutting it off
Also test with Bold Text enabled (iOS) and Display Size set to largest (Android). Some apps break layout entirely at extreme display settings, which is a critical accessibility failure for users with low vision.
Structuring the Manual Testing Process
Ad hoc manual testing catches some issues but misses others systematically. A structured approach covers more ground and produces results that can be reproduced and compared across releases.
A practical testing sequence for each screen:
- Navigate the full screen with the screen reader and document focus order
- Check labels and announcements for every interactive element
- Trigger all state changes (form submission, toggle, selection, error) and confirm announcements
- Switch to voice control and attempt to activate each interactive element by label
- Connect a keyboard and verify tab order and focus visibility
- Increase text to the largest size and check layout
Teams looking for a more formal framework for structuring mobile accessibility evaluations — including how to scope testing, document findings, and prioritize remediation — can find a detailed overview of the approach at BarrierBreak’s mobile accessibility testing service.
Conclusion
Mobile app accessibility testing manual processes are not optional for teams serious about compliance or user experience. Automated tools provide a starting point. Manual testing with screen readers, voice control, keyboards, and real users with disabilities provides the complete picture.
The issues that matter most to users — broken navigation, silent state changes, unreachable elements, illegible text at system sizes — are precisely the issues automated tools cannot find. Building manual testing into each development sprint, rather than treating it as a pre-release checkpoint, is the most cost-effective way to maintain accessibility over time.
For organizations that need expert-led mobile accessibility evaluations — including testing by specialists who use assistive technologies as their primary interface — BarrierBreak works with teams across iOS, Android, and cross-platform frameworks to deliver WCAG-aligned mobile audits and remediation support.
FAQ
How long does a manual mobile accessibility test take?
It depends on the scope. A single screen with five to ten interactive elements takes roughly 30 to 45 minutes to test thoroughly across VoiceOver, TalkBack, voice control, and keyboard. A full app with twenty screens can take two to three days. The scope should be agreed before testing begins and focused on core user journeys first.
Can I use the iOS Simulator or Android Emulator for manual accessibility testing?
Simulators and emulators are useful for quick checks and catching obvious issues, but they do not accurately replicate screen reader behavior on real hardware. VoiceOver and TalkBack timing, announcement behavior, and gesture recognition differ between emulated and physical environments. Always validate findings on real devices before reporting or remediating.
Should manual testing be done by someone with a disability?
Where possible, yes — and for the most reliable results, testing by people who use assistive technologies as their primary means of interacting with a device is the gold standard. Developers and QA testers who learn screen reader navigation can catch a large proportion of issues, but they do not replicate the full experience of a long-term assistive technology user. A mixed approach — developer testing plus user testing — produces the most complete results.
What is the difference between manual testing and a formal accessibility audit?
Manual testing is the process of evaluating an app with assistive technologies and accessibility-focused review. A formal accessibility audit is a structured evaluation that documents findings against specific WCAG success criteria, assigns severity levels, provides remediation guidance, and typically produces a deliverable (audit report or VPAT) that can be used for procurement or legal compliance purposes. An audit includes manual testing but adds the formal documentation layer.
How often should manual accessibility testing be done?
Testing once before release and never again is insufficient — apps change constantly through feature additions, OS updates, and third-party library upgrades. A practical cadence is a full manual review at major releases and a targeted check of changed screens and components at each sprint that touches the UI.
Does React Native or Flutter require different manual testing than native apps?
The manual testing process is the same — VoiceOver, TalkBack, voice control, keyboard — but the results can differ significantly between cross-platform frameworks and native code. React Native and Flutter each have known accessibility gaps and platform-specific behaviors that affect how components expose information to screen readers. The testing approach is identical; the issues found may be framework-specific.
