Mobile app accessibility best practices for platform accessibility in mobile apps start with the native iOS and Android experience: test critical journeys with VoiceOver and TalkBack, give controls meaningful accessible names, make important touch targets about 44 × 44 pt on iOS and 48 × 48 dp on Android, and make sure a swipe, drag, or other gesture is not the only path to complete an action. Then verify focus, text scaling, forms, authentication, media, errors, and complete user journeys on the devices people actually use.
For iOS and Android apps, that means going beyond an automated scan. Teams need to evaluate accessible names and roles, screen-reader behavior, touch interaction, text scaling, focus order, forms, authentication, gestures, media, errors, and complete user journeys.
The exact legal requirements that apply to a mobile app depend on the organization and context. From a technical perspective, WCAG principles and platform-specific accessibility guidance provide a strong framework for building and evaluating accessible mobile experiences.
For state and local government entities, the Department of Justice’s Title II web and mobile rule sets WCAG 2.1 Level AA as the technical standard for covered mobile apps; see our ADA Title II 2027–2028 checklist. For hands-on testing and remediation support, review ADA Access Group’s accessibility services.
Does WCAG Apply to Mobile Apps?
W3C does not maintain a separate normative standard called “Mobile WCAG.” Mobile accessibility is covered through WCAG and supporting guidance. W3C’s WCAG2ICT guidance explains how WCAG 2.0, 2.1, and 2.2 criteria can be applied to non-web software, including native mobile apps. W3C is also developing WCAG2Mobile guidance for applying WCAG 2.2 to mobile applications.
WCAG should still be combined with platform-specific guidance because native iOS and Android interfaces expose accessibility information differently from ordinary HTML pages.
For example, developers need to understand how an iOS control is exposed to VoiceOver or how Android semantics are presented to TalkBack—not merely whether a similar web component would pass an HTML-based automated test.
Mobile Accessibility and the ADA
It is important not to make a blanket statement that every mobile app in the United States is subject to exactly the same WCAG requirement.
For state and local governments covered by ADA Title II, the DOJ's web and mobile accessibility rule specifically applies to mobile apps and uses WCAG 2.1 Level A and Level AA as the technical standard, subject to the rule's provisions. See our Title II 2027 readiness checklist for the current compliance timeline.
Other organizations may have different requirements based on applicable law, contracts, procurement requirements, industry, or jurisdiction.
Technical accessibility testing can identify barriers and evaluate interfaces against defined accessibility criteria. It should not be represented as legal advice or a guarantee that an application satisfies every legal obligation.
13 Mobile App Accessibility Checks to Run
1. Give Every Important Control a Meaningful Accessible Name
A person using a screen reader often interacts with a control through accessibility information exposed by the operating system rather than through its visual appearance.
An icon that visually looks like a share button, close button, calendar, search control, or account menu may be obvious to a sighted user. If its accessible name is missing or unclear, a screen-reader user may hear something meaningless or may not understand the result of activating the control.
Accessible names should describe purpose, not merely appearance.
Good labels might include:
- “Search”
- “Close”
- “Share article”
- “Add payment method”
- “Show password”
Avoid labels that duplicate information the screen reader already announces. For example, if the platform exposes a control as a button, its name normally does not need to contain the word “button.”
iOS
VoiceOver relies on the accessibility information exposed by the application. Custom interface elements should provide appropriate labels, traits, values, and state information so the control can be understood without seeing the screen.
Android
TalkBack uses Android accessibility semantics to identify and describe controls. Interactive elements should expose meaningful descriptions, roles, states, and actions. Decorative elements should not create unnecessary screen-reader stops.
2. Test With VoiceOver and TalkBack
Automated tools can find some mobile accessibility problems, but they cannot tell you whether an entire interaction makes sense when spoken by a screen reader.
For iOS, manually test important workflows with VoiceOver. Apple’s current testing guidance also recommends checking key tasks with accessibility settings and assistive technologies such as Voice Control and Switch Control on supported devices. For Android, test important workflows with TalkBack and verify interaction on real target devices or representative emulator configurations.
During testing, ask:
- Can every important control receive accessibility focus?
- Does each element have a useful name?
- Is the control's role communicated correctly?
- Are states such as selected, expanded, checked, disabled, or required exposed?
- Does focus move in a logical order?
- When content changes, does the user receive the information they need?
- Can dialogs and other temporary interfaces be entered and exited correctly?
- Can the user complete the full task without relying on sight?
Do not limit screen-reader testing to the home screen. Test the actual workflows that matter to the product.
3. Make Touch Targets Easy to Operate
Small controls can be difficult to activate for people with limited dexterity, tremors, low vision, or other disabilities. Adequate target size and spacing also reduce accidental activation for many other users.
Current Apple design guidance lists a 44 × 44 pt default control size for iOS and iPadOS and identifies smaller platform minimums for controls in appropriate circumstances. Rather than designing every important action at the smallest permitted size, teams should favor comfortably sized, well-spaced controls.
Android recommends a touch target of at least 48 × 48 dp for interactive interface elements.
Remember that the visible icon and the actual interactive touch area do not always need to be the same size. A visually compact icon can have additional padding that creates a larger usable touch target.
4. Do Not Make Gestures the Only Way to Complete an Action
Swipe, drag, pinch, multi-finger, and other gestures can create barriers for users who have limited dexterity or use assistive technologies.
When a gesture performs an important action, consider whether an accessible alternative can be provided.
For example:
- If a list item can be deleted by swiping, provide an accessible delete action or button.
- If an item must be dragged to reorder it, provide another way to move it.
- If a custom gesture reveals important controls, make those controls available through another interaction method.
WCAG 2.2 also introduced criteria addressing dragging movements and target size, making these interaction patterns increasingly important when teams use WCAG 2.2 as an accessibility target.
5. Support Text Scaling Without Breaking the Interface
People with low vision frequently increase text size. An app can technically support larger fonts while still becoming unusable when content overlaps, disappears, truncates, or pushes critical controls off the screen.
On iOS
Support Dynamic Type where appropriate and test the interface at larger accessibility text sizes. Custom fonts and custom layouts need particular attention because they may not respond correctly without additional implementation work.
On Android
Test the application with increased font and display settings and verify that layouts adapt instead of clipping important text or controls.
When text becomes larger, check:
- navigation;
- buttons;
- form labels;
- validation messages;
- dialogs;
- cards;
- tables or data-heavy interfaces;
- bottom navigation;
- checkout or booking screens; and
- authentication screens.
6. Never Use Color as the Only Signal
Color can reinforce meaning, but important information should not depend on color perception alone.
A red border around a form field, for example, is not enough to explain that an error occurred. Add text or another programmatically available indicator explaining what is wrong and what the user should do next.
The same principle applies to:
- selected states;
- status indicators;
- charts;
- required fields;
- success and error messages;
- map markers; and
- availability indicators.
7. Check Contrast in Every Important State
Color contrast should be reviewed not just in a static design file but in the actual application.
Test normal text, larger text, important icons, input boundaries, focus indicators where applicable, disabled states, selected states, errors, and overlays.
Also test both light and dark appearance modes when the app supports them. A color combination that works in one theme can fail or become difficult to perceive in another.
8. Make Forms Accessible
Forms are one of the most important mobile accessibility areas because they are often required for registration, checkout, booking, payment, health information, account setup, and authentication.
Every field should have a clear purpose and an accessible label.
Do not rely only on placeholder text as the field's identity. Placeholder content can disappear after the user enters a value and may not provide sufficient programmatic information.
When validation fails:
- identify which field contains the error;
- explain what went wrong;
- provide instructions for fixing it;
- make the message available to assistive technology; and
- manage focus appropriately when necessary.
9. Review Authentication Carefully
Login and identity-verification flows deserve specific accessibility testing because a barrier can prevent a user from accessing the rest of the application.
Review:
- username and password fields;
- password managers;
- show/hide password controls;
- multi-factor authentication;
- one-time codes;
- CAPTCHA or challenge mechanisms;
- biometric alternatives;
- error recovery; and
- account recovery.
Do not assume a workflow is accessible because each individual text field has a label. Test the complete authentication journey.
10. Manage Accessibility Focus in Dynamic Interfaces
Modern mobile apps frequently update the interface without a traditional page load. Dialogs appear, drawers open, validation messages are inserted, items are added to carts, and confirmation screens replace previous content.
Visual users can often see these changes immediately. Assistive-technology users may need focus or an appropriate announcement to understand what happened.
Common problems include:
- focus remaining behind an open dialog;
- focus jumping to an unrelated element;
- a success message appearing visually but never being announced;
- a loading state completing without notifying the user;
- focus returning to the wrong control after a modal closes; and
- screen-reader users entering hidden or inactive content.
11. Make Media Accessible
Audio and video content should not communicate essential information through only one sensory channel.
Depending on the content, accessibility considerations may include:
- captions for spoken dialogue and meaningful audio;
- transcripts where appropriate;
- audio descriptions for important visual information;
- accessible media-player controls; and
- alternatives to instructions that rely only on sound or appearance.
12. Respect User Accessibility and Motion Preferences
Applications should account for system accessibility settings and user preferences where appropriate.
Avoid forcing unnecessary motion, animation, or time-sensitive interaction when an accessible alternative can be provided. Make sure content remains understandable when accessibility settings modify text, contrast, motion, or interaction behavior.
13. Test Real User Journeys, Not Just Screens
An app can contain individually accessible screens while still creating an inaccessible end-to-end experience.
Define the application's critical user journeys and test them from beginning to completion.
Examples include:
- create an account;
- sign in;
- search for a product or service;
- filter results;
- complete a booking;
- add an item to a cart;
- complete checkout;
- submit a form;
- upload a document;
- change account settings; and
- contact support.
Testing only isolated controls can miss barriers that appear when components interact.
A Practical Mobile Accessibility Testing Workflow
Step 1: Automated and developer checks
Use appropriate platform tools, linters, accessibility inspectors, and automated checks to identify potential issues efficiently.
Step 2: Manual screen-reader testing
Test critical iOS journeys with VoiceOver and Android journeys with TalkBack.
Step 3: Interaction testing
Review touch targets, gesture alternatives, navigation order, focus behavior, dynamic content, and error handling.
Step 4: Display and text testing
Increase text size, review orientation behavior where supported, inspect contrast, and test the interface under relevant system accessibility settings.
Step 5: Remediation
Fix issues at the component or design-system level when the same barrier appears throughout the application.
Step 6: Retesting
Verify each significant fix and repeat critical user journeys. Accessibility work is not complete simply because a ticket was moved to “done.”
Mobile Accessibility Checklist
- Important controls have meaningful accessible names.
- Roles and states are exposed correctly.
- Screen-reader focus follows a logical order.
- Critical workflows work with VoiceOver.
- Critical workflows work with TalkBack.
- Important touch targets are sufficiently large and spaced.
- Gesture-only actions have appropriate alternatives.
- Text can increase without blocking content or controls.
- Information is not communicated by color alone.
- Text and meaningful interface elements have adequate contrast.
- Forms have labels, instructions, and accessible errors.
- Authentication can be completed with assistive technology.
- Dynamic updates are communicated appropriately.
- Media includes appropriate accessibility alternatives.
- Important workflows are tested from start to finish.
- Automated findings are followed by manual testing.
- Remediated issues are retested.
Need a Mobile Accessibility Review?
A mobile accessibility review should show more than a list of automated warnings. It should identify potential barriers in the interfaces and workflows people actually use and translate confirmed findings into practical remediation work.
ADA Access Group combines automated checks with manual accessibility review to help teams understand and improve their digital experiences.
Explore our accessibility testing and audit services or contact us to discuss an iOS, Android, web, or cross-platform accessibility project.
Accessibility requirements can vary by organization, jurisdiction, and use case. ADA Access Group provides technical accessibility services and does not provide legal advice.