Accessibility Testing for Mobile Apps: A Practical Guide

Over 1.3 billion people worldwide live with some form of disability. If your mobile app isn't accessible, you're locking out roughly 16% of potential users — and in many markets, you're also breaking the law.

But accessibility testing on mobile is a different challenge than on web. You're not just checking alt text and keyboard navigation. You're testing how VoiceOver and TalkBack read your screens, whether touch targets are large enough for motor-impaired users, whether your app survives Dynamic Type on iOS and font scaling on Android, and whether your UI works with Switch Control, voice input, and magnification enabled.

This guide covers mobile-specific accessibility testing: what to check, how to check it, which tools to use, and how to build accessibility into your CI pipeline.

What Is Accessibility Testing?

Accessibility testing verifies that people with disabilities can use your app effectively. It evaluates whether users who are blind, low vision, deaf, hard of hearing, motor-impaired, or cognitively disabled can perceive, navigate, and interact with every screen and feature.

For mobile apps, this means testing with the actual assistive technologies built into iOS and Android — not just running an automated scanner and calling it done.

The standard framework is WCAG (Web Content Accessibility Guidelines), which applies to mobile as well. WCAG is built on four principles:

• Perceivable

  — users can see, hear, or otherwise access all content

• Operable

  — users can navigate and interact with all controls

• Understandable

  — content and navigation are clear and predictable

• Robust

  — the app works with current and future assistive technologies

WCAG defines three conformance levels: A (minimum), AA (recommended for most apps), and AAA (highest). Most legal requirements and enterprise contracts target AA compliance.

Get the Mobile Testing Playbook Used by 800+ QA Teams

Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.

Email addressGet Instant Access

100% Free. No spam. Unsubscribe anytime.

Why Accessibility Matters for Mobile Apps

Legal exposure. ADA (US), Section 508, the EU Web Accessibility Directive, AODA (Canada), and the RPwD Act (India) all extend to mobile apps. Lawsuits over inaccessible digital products have increased sharply — and settlements are expensive.

App store expectations. Apple actively promotes accessibility in its Human Interface Guidelines and App Store review process. Google Play's pre-launch reports include accessibility checks. Both platforms reward accessible apps with better visibility.

Enterprise deals require it. If you sell to government agencies, healthcare organizations, financial institutions, or universities, accessibility compliance is a procurement requirement — not optional.

It improves UX for everyone. Larger touch targets help users with big fingers. Captions help users watching videos in noisy environments. High contrast helps users in direct sunlight. Good accessibility is good design.

Mobile-Specific Accessibility: What to Test

1. Screen Reader Compatibility

Screen readers are how blind and low-vision users navigate your app. On iOS, that's VoiceOver. On Android, it's TalkBack.

What to check:

• Every interactive element (buttons, links, inputs, tabs) has a meaningful accessibility label. "Button" is useless. "Submit order" is clear.

• Reading order matches visual order. Screen readers traverse the screen in a linear sequence — if your visual layout doesn't match the DOM/view order, the app is confusing to navigate.

• Custom UI components are properly annotated. Standard platform controls (UIButton, MaterialButton) get accessibility support for free. Custom views, animated elements, and canvas-drawn UI need manual annotation.

• Modal dialogs trap focus correctly. When a dialog opens, the screen reader should focus inside it — not continue reading the background content.

• State changes are announced. When a loading spinner appears, a toast notification shows, or a list refreshes, the screen reader needs to announce it — otherwise the user doesn't know anything happened.

• Swipe gestures have alternatives. A screen reader user navigates by swiping left/right to move between elements. If your app relies on custom swipe gestures (swipe to delete, swipe to dismiss), provide an accessible alternative.

How to test: Enable VoiceOver (iOS: Settings → Accessibility → VoiceOver) or TalkBack (Android: Settings → Accessibility → TalkBack). Navigate your entire app using only the screen reader. If you can't complete every core flow — login, browse, purchase, settings — there's a bug.

2. Touch Target Size

Users with motor impairments, tremors, or limited dexterity need large enough tap targets. A tiny "X" button to dismiss a dialog is a common failure.

Standards:

• WCAG recommends a minimum of 44×44 CSS pixels for touch targets

• Apple HIG recommends 44×44 points minimum

• Material Design recommends 48×48 dp minimum

What to check:

• All buttons, links, icons, and interactive elements meet the minimum size

• Touch targets don't overlap — tapping one element shouldn't accidentally trigger an adjacent one

• Spacing between interactive elements is sufficient (at least 8dp/8pt between targets)

• Gesture-based actions (swipe to delete, long press for options) have visible, tappable alternatives

3. Color Contrast

Low-vision users and users in bright outdoor conditions need sufficient contrast between text and backgrounds.

Standards:

• WCAG AA: 4.5:1 ratio for normal text, 3:1 for large text (18pt+)

• WCAG AAA: 7:1 for normal text, 4.5:1 for large text

What to check:

• All text meets AA contrast ratio against its background — including text on images, gradients, and colored backgrounds

• UI controls (buttons, form borders, icons) meet 3:1 contrast against adjacent colors

• Error states, success states, and status indicators don't rely on color alone — use icons, text labels, or patterns alongside color

• Dark mode maintains contrast ratios. Many apps that pass in light mode fail in dark mode because text and background colors aren't tested together

Tools: Use Xcode's Accessibility Inspector (View → Accessibility Inspector) for iOS or Android's Accessibility Scanner for quick audits. For specific elements, use a contrast checker like WebAIM's Contrast Checker with the exact hex values from your design system.

4. Dynamic Type and Font Scaling

Both iOS (Dynamic Type) and Android (font scaling in Display settings) let users increase system font size — sometimes up to 300%. If your layout breaks at large font sizes, you're excluding users who need this feature.

What to check:

• Text reflows and doesn't get clipped, truncated, or hidden at the largest font size

• Buttons and interactive elements grow with their text — a button that stays fixed-width while its label overflows is broken

• No text overlaps other text or UI elements at large sizes

• Scrollable containers handle expanded content without layout breaks

• Images and icons don't obscure text when text size increases

How to test: On iOS, go to Settings → Accessibility → Display & Text Size → Larger Text and set it to maximum. On Android, go to Settings → Display → Font Size and set it to the largest option. Walk through every screen.

5. Keyboard and Switch Control Navigation

Users with motor impairments may navigate using an external keyboard, Switch Control (iOS), or Switch Access (Android) instead of touching the screen.

What to check:

• All interactive elements are reachable via Tab key (external keyboard) or switch scanning

• Focus order is logical — left to right, top to bottom, matching visual layout

• Focus is visible — the currently focused element has a clear visual indicator (outline, highlight)

• No keyboard traps — the user can always navigate away from any element

• Custom gestures (pinch, rotate, multi-finger swipes) have keyboard-accessible alternatives

6. Motion and Animation

Users with vestibular disorders or motion sensitivity can be physically harmed by excessive animation. Both iOS and Android provide a "Reduce Motion" accessibility setting.

What to check:

• When "Reduce Motion" is enabled, parallax effects, zoom transitions, and sliding animations are replaced with simple fades or cuts

• Auto-playing animations can be paused

• No content relies solely on animation to convey meaning — a progress animation should also have a text percentage

7. Media Accessibility

Deaf and hard-of-hearing users need captions for video and transcripts for audio content.

What to check:

• All videos have accurate closed captions (not just auto-generated — review for accuracy)

• Audio-only content (podcasts, voice messages) has text transcripts

• Captions don't obscure important visual content

• Media controls (play, pause, volume, captions toggle) are accessible to screen readers and keyboard navigation

8. Form Accessibility

Forms are where most accessibility failures hit hardest — especially in fintech, healthcare, and e-commerce apps.

What to check:

• Every input field has a visible label (not just placeholder text — placeholders disappear when the user types)

• Error messages are specific and associated with the relevant field — "Invalid input" is useless; "Email address must include @" is actionable

• Error messages are announced by screen readers when they appear

• Required fields are clearly marked (with text, not just color)

• Date pickers, dropdowns, and custom inputs are operable with screen readers and keyboard

Accessibility Testing Tools for Mobile

How Quash fits: Quash integrates accessibility checks into your existing test automation workflow. When you run functional tests on real devices, Quash simultaneously checks for missing accessibility labels, insufficient touch target sizes, and contrast violations — and flags them alongside functional bugs. You don't need a separate accessibility testing pass. Failures include screen recordings and device context so developers can see exactly which element failed on which device.

Building Accessibility into CI/CD

Accessibility testing shouldn't be a quarterly audit. It should run on every build, the same way you run functional regression tests.

Automated gates: Add accessibility scanning to your CI pipeline. Flag builds that introduce new WCAG AA violations — missing labels, low contrast, small touch targets. These are objective, automatable checks.

Manual validation on major releases: Automated tools catch ~30-40% of accessibility issues. The rest — reading order, meaningful labels, screen reader flow logic — require a human with a screen reader. Schedule manual accessibility walkthroughs before major releases.

Accessibility regression tests: When you fix an accessibility bug, add a test that prevents it from regressing. "Login button has accessibility label 'Sign in to your account'" is a test case, just like "Login button triggers authentication."

Track compliance over time: Measure the number of WCAG violations per build. Set a target: zero new AA violations per release. Track it on your QA dashboard alongside functional bug counts.

Accessibility Across Industries

Fintech: Account balances, transaction histories, and payment forms must be fully accessible. Screen reader users need to verify amounts and confirm transactions independently. Biometric authentication must have fallback options for users who can't use fingerprint or face recognition.

Healthcare: Patient portals, appointment booking, and medication tracking are critical for users with disabilities. HIPAA compliance and accessibility compliance often go hand-in-hand in procurement requirements.

E-commerce: Product images need descriptive alt text. Checkout flows must work with screen readers end-to-end. Size selectors, color swatches, and quantity pickers need accessible alternatives to visual-only selection.

Education: E-learning apps must provide captions for video content, accessible quizzes, and screen-reader-compatible navigation through course materials.

FAQ

Which WCAG level should my mobile app target? AA. It's the standard required by most accessibility laws (ADA, Section 508, EU Directive) and enterprise procurement contracts. AAA is ideal but often impractical for every element — aim for AAA on critical flows like checkout and account management.

Do native apps need to follow WCAG? Yes. While WCAG was originally written for web, WCAG 2.1 and 2.2 include mobile-specific success criteria (touch target size, orientation support, motion activation). Both Apple and Google map their accessibility guidelines to WCAG principles.

How do I test accessibility without a screen reader? You can run automated scanners (Accessibility Scanner on Android, Accessibility Inspector on iOS, axe DevTools) for objective checks like contrast and label presence. But for meaningful validation, you need to test with VoiceOver or TalkBack at least on critical flows. There's no shortcut — automated tools miss 60%+ of real accessibility issues.

How does Quash help with accessibility testing? Quash runs accessibility checks as part of your functional test suite on real devices. It flags missing accessibility labels, touch target violations, and contrast failures alongside functional bugs — so you don't need a separate testing pass. Results include device-specific context (screen recordings, element properties, OS version) for fast debugging.

Is accessibility testing a one-time task? No. Every new feature, UI update, or design change can introduce accessibility regressions. Build accessibility checks into CI and run them on every build. Schedule manual screen reader walkthroughs before major releases.

Conclusion

Accessibility testing for mobile apps goes far beyond checking alt text and contrast ratios. It means testing with VoiceOver and TalkBack on real devices, validating touch target sizes across screen densities, ensuring your layout survives Dynamic Type at maximum size, and confirming that every custom UI component is properly annotated for assistive technologies.

Build accessibility into your CI pipeline with automated checks. Supplement with manual screen reader testing on major releases. And use Quash to catch accessibility violations alongside functional bugs on every build — on real devices, with full context on every failure.