Skip to main content
Contact us

Mobile App Accessibility Checklist for iOS and Android

The short answer: an accessible mobile app works with the phone’s screen reader (VoiceOver on iOS, TalkBack on Android), with large text settings and with alternatives to complex gestures. The essentials are clear labels on every control, a logical focus order, touch targets of at least 44 by 44 points, good contrast, text that scales, and forms that explain errors.

One thing I tell every product team before we start: in apps there is no magic layer. On websites people still try floating accessibility widgets. In a native or cross-platform app there is nothing you can install that makes it accessible with one click. Accessibility lives in the code, the UX and the app logic, or it is not there at all.

The good news is that most of the issues we find in our app audits come back to the same short list. Use this checklist with your designers, developers and QA team, from the first wireframe to every release.

1. Labels and roles

In our app audits, the most common blocker is still the simplest one: a button or icon with no accessible name. For a screen reader user, that screen is simply blank or broken.

  • Every button, icon and image that does something has an accessible name (accessibilityLabel on iOS, contentDescription on Android).
  • Icon-only buttons say what they do: “Search”, not “Magnifier”.
  • Decorative images are hidden from the screen reader.
  • Custom controls expose the right role (button, switch, tab) and state (selected, expanded, off).

2. Focus order and navigation

  • Swiping through the screen moves in a logical reading order.
  • When a dialog or bottom sheet opens, focus moves into it, and returns to the trigger when it closes.
  • Headings are marked as headings so screen reader users can jump between sections.
  • Nothing traps focus.
  • Content that changes on its own is announced, so the user knows the screen has changed.

3. Touch targets and gestures

  • Targets are at least 44 x 44 points on iOS and 48 x 48 dp on Android, with space between them.
  • Every swipe, drag, pinch or long press has a simple alternative, such as a button.
  • Nothing depends on shaking or tilting the device alone.

4. Color and contrast

  • Text contrast is at least 4.5:1, and 3:1 for large text and key icons.
  • Color is never the only signal. An error has text or an icon too.
  • The app works in dark mode without losing contrast.

5. Text size and layout

  • Text follows the system font size (Dynamic Type on iOS, sp units on Android).
  • At the largest sizes text wraps instead of being cut off.
  • The app works in both portrait and landscape unless one orientation is essential.

When we work with UI and UX designers, the goal is to support dynamic text and proper contrast without hurting the look of the brand. It is almost always possible when it is planned in the design system.

6. Forms and errors

Sign up, login and checkout forms are where we see users get stuck most often. A typical case: the error message appears on screen, but the screen reader never reads it, so the user has no idea why the form will not submit.

  • Every field has a visible label that stays after the user starts typing.
  • Errors say what went wrong and how to fix it, and are announced to the screen reader.
  • Use the right keyboard type for email, phone and numbers.

7. Media and motion

  • Videos have captions; audio has a transcript.
  • Animations respect the “Reduce motion” setting.
  • Content does not auto-play with sound.

8. Test it like a user

We test apps on physical devices, on both iOS and Android, with the screen reader turned on, exactly the way a blind user or a user with a motor disability would use them. We compare what is shown on screen with what is actually heard. That gap is where most problems hide.

  • Run through the main journeys with VoiceOver and TalkBack turned on: sign up, login, search, purchase, contact.
  • Repeat at the largest text size and with an external keyboard.
  • Use the platform tools (Accessibility Inspector in Xcode, Accessibility Scanner on Android) as a first pass, then test by hand.

Automated tools catch part of the issues. The rest shows up only when a person uses the app the way a screen reader user does. When possible, we also include testing by users with disabilities on their own devices, with their own assistive technology. It is not always required, but it saves surprises after launch.

A note on AI-generated code

Many teams now build screens and even whole apps with AI tools. The code looks great and the interface runs smoothly, but in our experience the AI almost always forgets accessibility. We see missing labels and hints, broken focus order, system messages that are not read aloud (especially in Hebrew apps) and contrast that does not meet the standard. Fast development still needs a real accessibility check.

Where to start if your app is already live

My recommendation is always the same: plan accessibility before development, not after. It is much easier to adjust screens, menus and content in a new app than in one that is already in the stores.

If your app is already live, do not jump straight into fixes without knowing what is actually broken. Start with the journeys that matter most to your business and your users, find the critical blockers there, then work through the rest screen by screen. Add the checklist to your design review and your definition of done so new features stay accessible, and keep checking after version updates instead of waiting for things to break.

A developer knows how to implement the fixes, but usually cannot spot every gap and check it against the standard alone. The process works best as a partnership between an experienced developer and an accessibility consultant.

Our experts have tested and fixed native and hybrid apps for 9+ years. See our app accessibility services or read Apple’s Human Interface Guidelines on accessibility.

FAQ

Which standard applies to mobile apps?

WCAG 2.1 and 2.2 at level AA are the common reference for apps as well as websites. In the EU, EN 301 549 applies to apps, and in Israel IS 5568 is based on WCAG. Either way, the app needs to be accessible on both iOS and Android.

Do cross-platform apps (React Native, Flutter) need special care?

Yes. Native and cross-platform apps talk directly to the operating system’s accessibility layer. Both frameworks support accessibility, but labels, roles and focus need to be set deliberately and tested on each platform.

How often should we test app accessibility?

Before every major release, and whenever you add a new flow. A short screen reader pass in each QA cycle prevents most regressions.