Making a Mobile App Accessible

What the platforms ask for

Apple's accessibility guidelines say an accessible interface "allows people to experience your app or game regardless of their capabilities or how they use their devices".

Android's guide to making apps more accessible lists who benefits: people with "impaired vision, color blindness, impaired hearing, impaired dexterity, cognitive disabilities, and many other disabilities".

The easiest way to get there is to use the platform's standard controls wherever you can. Android notes that in Jetpack Compose "many built-in Material components" already meet its touch size minimum, while for custom elements "you need to set the size yourself". Apple recommends system colours because they "automatically adapt" to settings such as Increase Contrast. Every custom control is extra accessibility work.

Labels for VoiceOver and TalkBack

VoiceOver on iPhone and TalkBack on Android read the screen aloud. Each needs a text label for every button, icon and meaningful image. Apple's VoiceOver guidelines say:

• Label all key elements. System controls "have generic labels by default", but you should provide "more descriptive labels that convey your app's functionality", and add labels to any custom elements.
• Describe meaningful images, but "exclude purely decorative images from VoiceOver".
• Give each screen a title and headings. "The title is the first information someone receives from an assistive technology when arriving on a page or screen".
• Announce changes. An unexpected content or layout change is confusing because "their mental map of the content is no longer accurate".

Android's guide adds practical rules for writing labels:

• describe "the purpose and result of the interaction, not the visual details";
• a submit button's label should be "Submit", not "Submit button";
• each label should be unique, for example each city in a list.

The same idea as alt text on a website, covered in our website accessibility basics, applies here.

Text that grows

Both platforms let people choose a larger text size for every app. The app has to follow that setting and still work.

• iPhone and iPad. Apple says "ideally, give people the option to enlarge text by at least 200 percent", either through custom settings or "by adopting Dynamic Type", the systemwide text size setting. Its typography guidelines ask you to make sure "your app's layout adapts to all font sizes", keep truncation "to a minimum".
• Android. Android 14's release notes say the system "supports font scaling up to 200%". If text sizes are set in scaled pixels (sp), "these additional options and scaling improvements are applied automatically". Google adds: do not use sp for padding, and set line height in sp so it "scales along with your text".

To test, set the largest text size and check every screen. Look for text that is cut off or overlapping.

Touch targets and gestures

Small buttons are hard to hit with a tremor or limited dexterity. The platforms set these sizes:

• Apple: a default control size of 44x44 pt on iPhone and iPad, and a minimum of 28x28 pt. Apple also says spacing matters as much as size: about 12 points of padding around elements with a bezel and about 24 points around those without.
• Android: each interactive element should have a touch target "of at least 48dpx48dp. Larger is even better."

Gestures need care too. Apple's guidelines say to "use the simplest gesture possible", and "offer alternatives to gestures": if a swipe dismisses a view, "also make a button available". Android's principles for improving app accessibility say the same for drag and swipe actions: expose them as accessibility actions so that users of "TalkBack, Voice Access, or Switch Access" can complete them.

Colour and contrast

Both platforms use the WCAG contrast ratios:

• Android: at least 4.5:1 for text "smaller than 18sp, or if the text is bold and smaller than 14sp", and at least 3:1 for other text;
• Apple: 4.5:1 for text up to 17 pt, 3:1 for 18 pt and above or bold text, checked "in both light and dark appearances" if the app supports dark mode.

Colour must not be the only signal. Apple says "convey information with more than color alone". Android recommends "different shapes or sizes", text or patterns. A form error, for example, should have an icon and a message, not just a red outline.

Motion, media and time limits

• Motion. When people turn on Reduce Motion, Apple asks apps to reduce "automatic and repetitive animations, including zooming, scaling, and peripheral motion", for example by replacing sliding transitions with fades.
• Video and audio. Apple says important information should not be "communicated through audio alone", and lists captions, subtitles, audio descriptions and transcripts. Android asks for controls to "pause or stop the media, change the volume, and toggle subtitles (captions)", and a transcript where a video is vital to a task.
• Time limits. Apple warns that views that "auto-dismiss on a timer" are a problem for people who need longer, and says to "prefer dismissing views with an explicit action".

WCAG and apps

WCAG was written for the web, but it is also the usual reference for apps. The W3C's WCAG2ICT note explains how WCAG 2.0, 2.1 and 2.2 "can be applied to non-web Information and Communications Technologies", including software such as apps. Three points matter:

• It "provides informative guidance (guidance that is not normative and does not set requirements)".
• Many criteria apply "as written". For example, the WCAG 2.2 minimum target size of 24 by 24 CSS pixels applies to software, and the platform sizes above are larger.
• Some laws point to it. The note says the US Department of Justice's 2024 rule for state and local governments "directs implementers to utilize the guidance in this document" for mobile apps.

For which laws apply to your app, see our overview of website and app accessibility laws. This guide is general information, not legal advice.

Accessibility labels on the App Store

Apple's Accessibility Nutrition Labels appear on an app's product page and "help users learn if an app will be accessible to them before they download". Developers declare support for features such as VoiceOver, Voice Control, Larger Text ("200% or more"), Sufficient Contrast, Reduced Motion and Captions.

Apple says the labels are "voluntary to start", but that "over time, you'll be required to share accessibility support details to submit new apps and app updates". It recommends evaluating VoiceOver first, because that work "can also make it more accessible for users of other assistive technologies". Declare a feature only after testing it against Apple's criteria.

Checking as you build

Check while screens are built, not only before launch:

• for Apple platforms, Apple recommends Accessibility Inspector to "highlight accessibility issues" and see how the app appears to accessibility features;
• on Android, Google's Accessibility Scanner can scan the screens of your app, but Google says it "isn't a replacement for manual testing and doesn't guarantee the accessibility of the app";

Then use the app yourself with VoiceOver and TalkBack on, with the largest text size and with Reduce Motion. Our guide to testing a mobile app covers screen reader testing alongside beta testing and device coverage.

A checklist

• Standard platform controls are used wherever possible; custom ones are designed for accessibility from the start.
• Every button, icon and meaningful image has a short, unique label; decorative images are hidden from screen readers.
• Text follows the system text size up to the largest setting without being cut off.
• Touch targets meet 44x44 pt on iPhone and 48x48 dp on Android, with space between them.
• Text contrast is at least 4.5:1, or 3:1 for large text, in light and dark mode, and colour is never the only signal.
• The app respects Reduce Motion, videos have captions and controls, and nothing important disappears on a timer.
• The app has been used end to end with VoiceOver and TalkBack.

Frequently asked questions

Do I need to build a separate accessible version of my app?

No. Accessibility is built into the same app: labels for screen readers, text that follows the system size, large enough touch targets, good contrast and alternatives to gestures. Using the standard iOS and Android controls gives you much of this from the start.

What touch target size should an app use?

Apple's default control size on iPhone and iPad is 44x44 pt, with 28x28 pt as the minimum. Android recommends at least 48dp by 48dp for each interactive element. The tappable area can be larger than the visible icon.

Does WCAG apply to mobile apps?

WCAG was written for the web, but the W3C's WCAG2ICT note explains how its criteria can apply to software, including apps. The note itself sets no requirements. Laws and regulations decide what is required, and some refer to WCAG or WCAG2ICT.

How large should text be able to get?

Apple suggests letting people enlarge text by at least 200 percent, for example through Dynamic Type. Since Android 14 the system supports font scaling up to 200%, and text sized in sp units follows it automatically.

What are Accessibility Nutrition Labels?

They are labels on an app's App Store page that show which accessibility features, such as VoiceOver or Larger Text, the app supports. Apple says they are voluntary to start but will become required for new apps and updates over time.

Planning an app that everyone can use? We build iPhone and Android apps together with the backend, API and admin dashboard behind them. See our mobile app development service and all our services, or email [email protected].