Mobile App Accessibility: A Developer's Complete Guide

One billion people worldwide live with some form of disability. When your mobile app ignores accessibility, you're not just failing a legal or ethical obligation — you're locking out a massive audience and delivering a worse experience for everyone. Accessibility features like larger text, high contrast, and keyboard navigation benefit users in bright sunlight, with one hand occupied, or simply aging eyes. This guide covers the concrete implementation steps developers need to make iOS and Android apps genuinely accessible: WCAG standards, screen reader support, color contrast, touch target sizing, haptic feedback, and accessible forms. This is not a theory lecture — every section ends with code you can use today.

For a broader look at the mobile development landscape, see our Mobile Development Complete Guide.

Understanding WCAG in a Mobile Context

The Web Content Accessibility Guidelines (WCAG) were written for the web but apply directly to mobile apps through the four core principles: Perceivable, Operable, Understandable, and Robust — often abbreviated POUR. WCAG 2.2 is the current standard, and both Apple's App Store review guidelines and Google's Play Store policies reference it. WCAG 2.1 Level AA is the compliance target for most apps subject to ADA or Section 508 requirements in the US, and the European Accessibility Act mandates it for apps serving EU customers starting June 2025.

Mobile-specific guidance lives in the companion document "Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile," but the key adaptations from web to mobile are straightforward. Touch replaces mouse input, so minimum target sizes and gesture alternatives matter more. Screen real estate is limited, so information architecture and zoom behavior need extra attention. Orientation lock should never trap users — some people mount devices in fixed positions due to physical limitations.

Perceivable: All information presented visually must also be available non-visually. Images need alt text. Audio needs captions. Color cannot be the sole means of conveying information.

Operable: All functionality must be achievable without touch alone. Keyboard (external Bluetooth keyboards are common for accessibility users), switch control, and voice must all work. Time limits must be adjustable or extendable.

Understandable: Labels must be clear. Error messages must identify what went wrong and how to fix it. Navigation must be predictable.

Robust: Your app must work with current and future assistive technologies. This means using native components where possible rather than custom-drawn UI that screen readers cannot parse.

VoiceOver on iOS: What Developers Need to Know

VoiceOver is Apple's built-in screen reader, activated by triple-clicking the side button. When VoiceOver is on, users navigate by swiping right to move to the next element, left to go back, and double-tapping to activate. Your job as a developer is to ensure every interactive element has a meaningful accessibility label, hint, and trait.

Accessibility labels: Every UIButton, UIImageView used as a button, and custom tappable view needs an accessibilityLabel. If your button shows an icon with no visible text, VoiceOver will read the image file name without a label — which sounds like "icon_checkmark_green_32" to a blind user. Set the label programmatically: myButton.accessibilityLabel = "Submit order". In SwiftUI, use the .accessibilityLabel() modifier.

Accessibility traits: Traits tell VoiceOver what kind of element it's reading. A button should have .button trait. A heading should have .header trait. A selected tab should have .selected trait. These map to ARIA roles on the web. Without correct traits, VoiceOver announces elements without any context — users cannot tell a heading from a paragraph from a button.

Grouping related elements: If you have a product card with an image, title, price, and rating displayed as four separate views, VoiceOver will visit each one individually. Group them into a single accessible element so users hear "Running Shoes, $89, 4.5 stars" in one swipe. In UIKit, set isAccessibilityElement = true on the container and isAccessibilityElement = false on children. In SwiftUI, use .accessibilityElement(children: .combine).

Custom actions: Swipe-to-delete rows and long-press context menus are invisible to VoiceOver users unless you expose them as accessibility custom actions. Add accessibilityCustomActions to your table cells so screen reader users can access the same destructive and contextual options available to touch users.

TalkBack on Android: Implementation Patterns

TalkBack is Android's screen reader, enabled through Accessibility settings or the volume key shortcut. It works similarly to VoiceOver — linear navigation by swiping, activation by double-tapping — but the implementation differs at the API level.

ContentDescription: The Android equivalent of accessibilityLabel is android:contentDescription in XML or view.contentDescription in Kotlin/Java. For ImageViews used decoratively, set android:importantForAccessibility="no" so TalkBack skips them entirely. For informational images, write a description that conveys the meaning, not just the visual content.

ViewCompat and AccessibilityNodeInfoCompat: For custom views, override onInitializeAccessibilityNodeInfo and use AccessibilityNodeInfoCompat to set roles, state descriptions, and actions. This is the Android equivalent of UIKit traits. The Jetpack Compose equivalent is the semantics modifier — use it on every composable that users interact with.

Heading traversal: Android 9 and above support heading navigation in TalkBack. Set ViewCompat.setAccessibilityHeading(view, true) on section headers, or use Modifier.semantics { heading() } in Compose. This lets power users skip between sections instead of navigating element by element.

Live regions: When your app updates content dynamically — a loading indicator that becomes a success message, a countdown timer, a live chat feed — TalkBack needs to announce the change. Set ViewCompat.setAccessibilityLiveRegion(view, ViewCompat.ACCESSIBILITY_LIVE_REGION_POLITE) for updates that should be announced when TalkBack finishes the current utterance, or ASSERTIVE for urgent updates that should interrupt.

Color Contrast and Visual Accessibility

WCAG 2.2 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Level AAA requires 7:1 and 4.5:1 respectively. These ratios apply to text on backgrounds — and to UI components like form borders, focus indicators, and icons that convey information.

The most common failures in mobile apps are light gray text on white backgrounds, placeholder text in form fields, and disabled state styling that drops contrast below 3:1 without providing an alternative way to convey the disabled state. Placeholder text is a particular trap — WCAG requires 4.5:1 even for placeholder, but most design systems style it at 40% opacity by default, which almost never passes.

Color alone cannot convey meaning. Error states marked only by red borders fail users with color blindness. Required fields marked with a red asterisk fail if no text label says "required." Add text, icons, or patterns as secondary signals. For form validation errors, combine a red border with an error icon AND an error message text below the field.

Dark mode compliance: If your app supports dark mode — and it should, since both iOS and Android provide system-level dark mode — verify contrast ratios in both themes. Colors that pass in light mode often fail in dark mode, especially semi-transparent overlays and shadow-based elevation.

Use tools like Figma's accessibility contrast plugin during design review, and the Accessibility Inspector on macOS (which can connect to iOS simulators) and Android's built-in "Color correction" and "Remove animations" developer options during testing.

Touch Target Sizing

WCAG 2.5.5 (Level AAA) recommends a minimum touch target size of 44x44 CSS pixels. Apple's Human Interface Guidelines specify 44x44 points. Google's Material Design specifies 48x48dp. These are not the visual size of the element — a 24x24dp icon can have an invisible 48x48dp touch target surrounding it.

In iOS, extend touch targets using contentEdgeInsets on UIButton, or override point(inside:with:) to expand the hit test area beyond the visible bounds. In SwiftUI, use .contentShape(Rectangle()) combined with a larger frame and .clipped(false). In Android, use TouchDelegate to extend the touch area of a view, or simply add padding to the container view.

The most commonly undersized targets in production apps are icon-only navigation bar items, close buttons in modals, inline "remove" buttons on tags and chips, and checkbox/radio inputs without tappable labels. Audit these specifically rather than assuming your grid system handles them.

Haptic Feedback and Non-Visual Feedback

Haptic feedback is not just a delight feature — it provides confirmation to users who cannot see screen transitions or who are looking away from their device. iOS provides three haptic feedback generators through UIKit: UIImpactFeedbackGenerator for impacts (button taps, list reorders), UINotificationFeedbackGenerator for success/warning/error outcomes, and UISelectionFeedbackGenerator for selection changes like picker scrolls.

Android provides similar capabilities through Vibrator and VibrationEffect, with predefined constants like EFFECT_CLICK, EFFECT_DOUBLE_CLICK, and EFFECT_HEAVY_CLICK. In Jetpack Compose, use LocalHapticFeedback.current.performHapticFeedback().

Use haptics intentionally. Success haptic on form submission, error haptic when validation fails, impact haptic when a drag-and-drop item lands. Do not add haptics to every interaction — overuse dulls their meaning and annoys users who turn them off for battery reasons. Always respect the user's system haptic settings; both iOS and Android provide APIs to check whether haptics are enabled.

Accessible Forms

Forms are where accessibility failures have the most user impact — a user who cannot complete your checkout or registration form is completely excluded from your service. The requirements are concrete and testable.

Every input must have a persistent label. Placeholder text disappears when the user starts typing. Use a persistent label above or beside the field. If space constraints require hiding the visual label, set the accessibility label programmatically so screen readers still announce it.

Error messages must be specific and programmatically associated with the field. "Invalid input" is not acceptable. "Email address must include an @ symbol" is. On iOS, use accessibilityErrorMessage (iOS 17+) or set the accessibility label dynamically to include the error. On Android, use ViewCompat.setStateDescription() or set an error on TextInputLayout, which automatically moves focus to the errored field.

Keyboard type must match field content. Phone number fields should use the numeric keyboard. Email fields should trigger the email keyboard with the @ key visible. URL fields should show the URL keyboard. This is both an accessibility requirement and a basic usability expectation — and it is wrong in a surprising number of production apps.

Autocomplete attributes: iOS supports textContentType and Android supports autofillHints. Setting these correctly allows the system to autofill from iCloud Keychain or Google Password Manager, which is essential for users with motor disabilities who find typing laborious. Use values like .emailAddress, .password, .givenName, and .streetAddressLine1.

Testing Your Accessibility Implementation

Manual testing with real screen readers is non-negotiable. Enable VoiceOver or TalkBack and navigate your app's critical flows — onboarding, authentication, core feature, and checkout — without looking at the screen. If you cannot complete these flows by ear alone, your app is not accessible.

Automated tools catch a subset of issues. On iOS, Xcode's Accessibility Inspector flags missing labels and contrast failures. On Android, Accessibility Scanner from Google Play scans screens and reports violations. Both tools miss context-dependent issues and focus order problems, but they are fast and free and should run in CI.

For a deeper audit, test with Switch Control (iOS) and Switch Access (Android), which simulate users who navigate with a single switch input. Also test with Display and Text Size settings cranked to maximum — if your layouts break at 200% text size, you have failed users with low vision who rely on large text.

Related Reading

• Mobile App Testing Guide: From Unit Tests to App Store Launch
• Mobile UX Design Principles That Drive Retention
• Cross-Platform Mobile Development: React Native vs Flutter vs Native