How to Test Accessibility in Mobile Apps

Test mobile app accessibility by completing the app’s real user workflows on every supported platform, first with platform inspection and automated checks, then manually with screen readers and other relevant accessibility settings. Record issues, fix them, and repeat the affected workflow. Include feedback from people with disabilities when possible. An automated audit can find some defects; a clean audit does not prove the app is accessible.

This process works for native iOS and Android apps, as well as hybrid apps with web content. The exact checks depend on your app, user tasks, supported devices, and applicable requirements.

1. Define the test scope

Start with user goals rather than a list of controls. A button can have a good label in isolation and still fail as part of a workflow if focus moves unexpectedly, an error is not announced, or the user cannot reach the next step.

1. List key workflows: onboarding, login, search, purchases, forms, primary actions, dialogs, notifications, recovery, and sign-out as applicable.
2. Map each workflow to screens and states: include validation errors, loading, empty results, success, permission prompts, and network or authentication failures.
3. List supported environments: iOS and Android versions, device types and representative screen sizes. Choose devices based on your support range; there is no universal device matrix.
4. Choose relevant assistive technology and settings: at minimum, screen readers for visual content; also consider switch, voice, text scaling, contrast, motion, captions, audio description, and transcripts based on the app’s features.
5. Record the baseline: app version/build, OS/device, workflow, accessibility configuration, expected outcome, and known limitations.

A useful test matrix has workflows as rows and platform/configuration combinations as columns. Prioritize tasks with high user impact, but do not let a passing sample stand in for every supported workflow.

Workflow or state	iOS checks	Android checks
Login and recovery	VoiceOver, larger text, field labels, validation and focus	TalkBack, text scaling, field labels, validation and focus
Primary task	VoiceOver plus relevant Voice Control or Switch Control use	TalkBack plus relevant Voice Access or Switch Access use
Dialogs and temporary messages	Announcement, reading order, dismissal and return focus	Announcement, reading order, dismissal and return focus
Media or visual content	Descriptions, captions/transcripts and contrast as applicable	Descriptions, captions/transcripts and contrast as applicable

2. Run platform inspection and automated checks

iOS: Accessibility Inspector and UI-test audits

In Xcode, open Xcode > Open Developer Tool > Accessibility Inspector. Inspect the accessibility hierarchy and the properties exposed for each important element. Run its available audits to look for issues such as missing element descriptions, small hit regions, contrast, element detection, and clipped text at larger Dynamic Type sizes.

Apple also documents adding audits to UI tests with performAccessibilityAudit(for:). For example, a minimal XCTest audit can look like this (adapt the app launch and navigation to your project):

import XCTest

final class AccessibilityAuditTests: XCTestCase {
    func testMainScreenAccessibilityAudit() throws {
        let app = XCUIApplication()
        app.launch()
        // Navigate to the screen under test before auditing it.
        try app.performAccessibilityAudit()
    }
}

Run the test on the screen states that matter; an audit of the initial screen does not inspect screens the test never visits. Apple cautions that clearing reported audit issues does not guarantee a fully accessible app, and recommends testing with assistive apps such as VoiceOver. See Apple’s audit guidance and Accessibility Inspector documentation.

Android: analysis tools and automated UI tests

Use Android’s accessibility analysis tools and UI tests alongside manual operation. For Jetpack Compose, inspect the semantics tree and use Compose testing APIs to verify the semantics exposed to accessibility services. Teams using the Android Views system should follow the Views-specific documentation linked from the current Android accessibility testing guidance, since some Android documentation is being refactored toward Compose.

Use the Accessibility Scanner where suitable to find certain on-screen issues, then verify each finding in the actual workflow. Automated assertions should cover important semantics and states, not just whether a screen rendered. Android recommends combining manual testing, analysis tools, automation, and user testing; see Android’s Compose accessibility guidance.

Keep automation’s coverage explicit

For each check, note what it can detect and what it cannot. A tool can flag a missing description, for example, but it cannot reliably decide whether the description communicates the right purpose or whether the entire task makes sense when heard. Do not report “accessible” solely because automated checks pass.

3. Manually test iOS with VoiceOver

1. Install the app on a supported physical iPhone or iPad. Apple notes that VoiceOver is not available in Simulator.
2. Turn on VoiceOver in Accessibility settings or with the configured Accessibility Shortcut.
3. Start at the beginning of each selected workflow. Navigate using VoiceOver gestures rather than sighted tapping alone.
4. Listen for each control’s name, role, value, and state. Check that the spoken description answers what the element is and what activating it will do.
5. Move through the screen in order. Confirm that all required elements are discoverable, related content is grouped sensibly, and focus does not jump or become trapped.
6. Activate controls and complete the task. Check that dialogs, validation messages, changing content, and success/failure states are announced and that focus returns to a useful place.
7. Repeat with relevant settings, such as larger Dynamic Type, color and contrast options, motion settings, Voice Control, Switch Control, captions, audio descriptions, or transcripts.

Screen Curtain can help evaluate some nonvisual interactions by hiding the display while VoiceOver remains on. Voice Control testing needs an environment where spoken commands can be given clearly. Select settings that fit the app rather than treating every setting as relevant to every product. Apple’s accessibility testing guidance covers physical-device testing and assistive technology use.

4. Manually test Android with TalkBack

1. Enable TalkBack on a supported Android device.
2. Repeat the same workflows tested on iOS, using TalkBack navigation. Android describes linear navigation by swiping right or left and touch exploration by dragging a finger over the screen.
3. Check whether spoken feedback makes each element’s purpose clear and whether every action needed for the task can be reached and activated.
4. Trigger errors, alerts, loading changes, and temporary messages. Confirm they are spoken at the right time and do not disappear before they can be understood.
5. Test Switch Access when the workflow must work without touch input. Android describes moving focus with a “Next” action and activating with a “Select” action.
6. Test Voice Access where spoken control is relevant, and check text scaling, contrast, and media alternatives as applicable.

Do not assume equivalent behavior between Android and iOS just because the screens look alike. Each implementation exposes its own accessibility structure and needs to be checked with its platform’s tools and assistive technology.

5. Check the experience across disability and interaction needs

Use these questions during hands-on tests. Apply the relevant ones to each workflow and configuration.

• Names and purpose: Does each interactive element have a useful spoken name and role? Are icon-only actions understandable?
• Order and reachability: Can a person navigate through all necessary content in a sensible order? Is any essential action available only through a gesture that some users cannot perform?
• State and feedback: Are selected, expanded, disabled, loading, and error states conveyed? Do updates receive appropriate announcements?
• Text and layout: Does content remain readable at larger text sizes? Is text clipped, overlapped, or hidden? Can controls still be reached?
• Touch and motor access: Are interactive areas practical to activate? Can the workflow be completed with the relevant switch or voice interaction?
• Visual access: Does the interface remain understandable with applicable contrast, color, and display settings? Is meaning conveyed without color alone?
• Audio and video: Are captions, transcripts, or audio descriptions available where needed? Can users control audio that could interfere with assistive technology?
• Recovery: Can users correct errors, dismiss overlays, return to a useful place, and recover from interrupted or failed actions?

For apps with web views, test the web content in its embedded context as well as native controls around it. A screen reader transition between native and web content can expose issues that a browser-only check misses.

6. Use WCAG as a framework, with clear limits

W3C’s Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile) explains how WCAG 2.2 Level A and AA success criteria can be interpreted for native apps, mobile web apps, and hybrid apps with web components. It uses mobile screens or views where appropriate. The note is informative rather than normative and does not cover every platform-specific or component accessibility need by itself.

There is no separate W3C mobile accessibility guideline; mobile accessibility is addressed through existing guidance, including WCAG. Use WCAG criteria to organize evaluation and communicate issues, then add platform-specific checks and real task testing. Applicable legal or procurement requirements depend on jurisdiction and product context; do not infer them from this technical guide.

As one example of a public-sector audit process, the UK Government Digital Service says its monitoring tests sites and mobile apps against WCAG 2.2 A and AA, and that mobile app tests cover both Android and iOS versions. That describes GDS’s approach, not a universal requirement for every team or country. See GDS: Accessibility monitoring, how we test.

7. Include user testing and regression checks

Invite people with disabilities to try representative workflows when feasible. Their experience can expose barriers that an internal team, checklist, or automated tool may miss. Make the session accessible, explain the task without coaching the solution, and let participants choose the assistive technology and interaction approach they normally use where possible.

Log each finding with reproducible details:

• App build, device and OS version
• Workflow, screen, and exact steps
• Assistive technology and settings
• Expected behavior and what actually happened
• Impact on completing the task, with a recording or screenshot only when appropriate and consented

Fix the underlying issue, rerun the affected workflow on the relevant platform, and rerun automated checks. Keep stable, high-value audit checks in UI tests so regressions are caught during development. Revisit manual testing after changes to navigation, component libraries, forms, overlays, or dynamic content.

8. Troubleshooting common problems

Symptom	Likely cause	What to do
Audit passes but a user cannot complete the task	Automated checks cover detectable patterns, not the full meaning or usability of a workflow.	Reproduce the task with VoiceOver or TalkBack, then involve users with disabilities where feasible. Check order, announcements, and recovery states.
A control is skipped by the screen reader	It may be hidden from accessibility services, incorrectly grouped, or absent from the exposed semantics.	Inspect the accessibility hierarchy or Android semantics tree. Correct the element exposure/grouping and repeat the whole workflow.
A control is announced but its purpose is unclear	The accessible name may be missing, generic, duplicated, or disconnected from the action.	Give it a concise, specific name and verify the spoken result in context, including role and state.
Errors appear visually but are not spoken	Validation changes may not move focus or expose an announcement to assistive technology.	Test invalid submissions and asynchronous failures. Expose the error accessibly and ensure users can find and correct the associated field.
Large text clips or overlaps content	Layout assumes fixed text dimensions or does not adapt to the platform’s text scaling.	Repeat tests at larger supported text sizes, allow content to reflow or scroll, and check that controls remain available.
VoiceOver test cannot run in Simulator	VoiceOver is not available there according to Apple’s testing guidance.	Install the build on a physical supported Apple device and test there.
Compose test cannot find an element by its visible text	Visible rendering and exposed accessibility semantics can differ, or the test targets the wrong node/group.	Inspect the Compose semantics tree, then assert against the intended accessible semantics and state.
Temporary messages are missed	The update may not be announced, may arrive too late, or may vanish before users can respond.	Trigger the state repeatedly with the screen reader active; adjust announcement and persistence behavior so the information can be perceived and acted on.

9. Performance, reliability, and cost of a test program

Accessibility testing has no single fixed runtime or device count: effort depends on the supported platform range, workflows, states, assistive technologies, and depth of user research. Keep checks efficient by running automated audits in UI tests on stable high-value screens and reserving hands-on sessions for complete workflows and changes that can alter interaction.

• Reliability: test real supported devices for assistive technology behavior, and repeat high-impact workflows after OS, app, or component changes. Record environment details so findings can be reproduced.
• Coverage: track the workflow/platform/state combinations actually exercised. A sample audit or one device is evidence for that sample only.
• Cost: use platform-provided inspection and accessibility settings as part of development, then plan staff time for manual testing and participant feedback. The dossier identifies no vendor pricing or universal budget, so estimate from your own scope.
• Evidence: retain issue steps, expected/actual behavior, environment, and retest result. Avoid turning a tool’s pass status into a blanket compliance claim.

Or skip the browser setup

For screenshots of web content embedded in a mobile workflow or for visual review artifacts, ScreenshotNeo is a website screenshot API and MCP server. It does not test app accessibility or replace VoiceOver, TalkBack, or user testing. One GET request captures a URL as PNG, JPEG, WebP, or PDF. The parameter names used by other screenshot APIs also work, which makes switching easier.

Example capture of a web page used in your app:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

See the ScreenshotNeo API documentation for request options. Before capture, it accepts cookie/consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Its response identifies the page verdict and billing status in headers. The MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Sign up free for 1,000 screenshots a month, with no card required.

FAQ

Can an accessibility scanner certify my app?

No. A scanner reports issues it can detect. Complete workflows with assistive technology and include user feedback where possible; follow the standards and legal requirements applicable to your context.

Do I need separate iOS and Android tests?

If you ship both, test both. Similar screens can expose different accessibility behavior because each platform has its own implementation and accessibility system.

Should I test on an emulator or a physical device?

Automation and inspection can be useful in development environments, but test assistive technology on supported physical devices as needed. Apple specifically notes VoiceOver is unavailable in Simulator.

Does WCAG2Mobile create new requirements?

No. It is informative guidance for interpreting WCAG 2.2 A and AA in mobile apps, not a normative specification or a complete account of mobile accessibility needs.