How Do You Make a Mobile App Accessible? The Basics Every App Owner Should Ask For

You make a mobile app accessible by making it work with the assistive features already built into phones, mainly the screen readers (VoiceOver on iOS, TalkBack on Android) and the system text size setting, and by meeting a short list of basics: a label on every control, touch targets that are large enough, readable color contrast, no meaning carried by color alone, and captions on video. Most of this costs little when it is planned at the design stage and noticeably more when it is added after launch.

As an app owner you do not need to implement any of it, only to know what to ask for and how to check you received it. The decisions that matter most are made in design, before any code exists, so accessibility belongs in the mobile app UI and UX design stage rather than in final testing.

Who does mobile app accessibility help?

It helps people with permanent disabilities first, and a much larger group of people in ordinary situations second. The first group includes people who are blind or have low vision, people who are deaf or hard of hearing, people with limited hand movement or tremor, and people who find dense or fast-moving screens hard to process.

The second group is most of your customers at some point: someone reading in bright sunlight, someone using one thumb while carrying something, someone watching a video with the sound off, and anyone who has increased the text size on their phone as their eyesight changed.

Which phone features does an accessible app have to work with?

At a minimum, the screen reader and the text size setting on each platform. Users choose these in their phone settings, and your app either respects them or it does not.

On iOS: VoiceOver and Dynamic Type

Apple describes VoiceOver as "a screen reader that lets people experience your app's interface without needing to see the screen". Dynamic Type is Apple's system for user-chosen text sizes. Apple's Human Interface Guidelines on accessibility say that ideally people should be able to enlarge text by at least 200 percent. The same page names Switch Control, Voice Control and the Reduce Motion setting as features an app should support.

On Android: TalkBack and font scaling

TalkBack is Android's built-in screen reader. Android also has a system font size setting, and starting in Android 14 the system supports font scaling up to 200%. The app follows that setting only when text sizes are defined in scalable units (sp), which is something to confirm with your developers.

What are the basics every app should get right?

Six things cover most of the problems real users hit. The numbers below were checked against the linked sources on October 6, 2026.

• Labels on controls. Every button, icon and image that means something needs a text label the screen reader can speak. An unlabeled cart icon is announced as "button" and nothing else. Android's guidance is to describe the purpose of the control, not its appearance.
• Touch target size. Android recommends a touch target of at least 48dp x 48dp for each interactive element. Apple lists 44x44 pt as the default control size on iOS and iPadOS, with 28x28 pt as the minimum.
• Color contrast. WCAG 2.2, the W3C standard, requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text at Level AA (criterion 1.4.3). Apple and Android both use the same figures in their own guidance.
• Text scaling. Screens must stay usable when the user enlarges text: nothing cut off, nothing overlapping, no button pushed off screen. WCAG criterion 1.4.4 sets the bar at 200 percent.
• Not relying on color alone. A red border on a form field is invisible to a color-blind user. Add an icon or a text message. This is WCAG criterion 1.4.1.
• Captions. Prerecorded video with speech needs captions (WCAG criterion 1.2.2).

How is app accessibility tested?

It is tested in two ways that do not replace each other: a person walks through the app with the screen reader on, and automated checkers scan each screen.

The screen reader walkthrough

A tester turns on VoiceOver or TalkBack and completes the app's main tasks, such as sign up, search, checkout and booking, without looking at the screen. This finds what tools cannot: controls read in a confusing order, a pop-up the reader cannot escape, a label that is present but meaningless. The tester then repeats the tasks with text at its largest size.

The platform checkers

On iOS, Apple's Accessibility Inspector audits an app for issues "such as clipped text and unlabeled elements" and checks text size and color contrast. On Android, the Accessibility Scanner app looks at content labels, clickable items and contrast and suggests fixes, and Google Play runs accessibility tests in its pre-launch report after a build is uploaded. Automated tools catch missing labels and low contrast reliably. They cannot tell you whether a task is actually completable.

Why is it cheaper to design accessibility in than to add it later?

Because the expensive accessibility problems are design problems, and design is cheapest to change before it is built. A brand color that fails contrast, fixed-height boxes that cannot hold larger text, and a row of small icons packed together all have to be redesigned, rebuilt and retested on every screen where they appear.

Decided up front, the same things cost almost nothing extra: the designer picks a compliant palette once, and the developer builds flexible layouts and adds labels as each screen is written. Whichever framework you choose, ask your team how it exposes controls to VoiceOver and TalkBack; our comparison of native, Flutter and React Native covers the other trade-offs.

What are the common mistakes?

The most common mistake is treating accessibility as a final test phase rather than a design requirement. The others follow a pattern:

• Icon-only buttons with no label.
• Light gray text on white, usually for hints, placeholders and legal copy.
• Text that ignores the system size setting, or screens that break when it is honored.
• Custom-built controls such as sliders, carousels and swipe-only actions that a screen reader cannot operate.
• Error states shown only in red.
• Passing an automated scan and assuming the app is therefore accessible.

What should you put in the brief?

Put in measurable requirements, not the phrase "the app should be accessible". A workable brief asks for:

1. WCAG 2.2 Level AA as the target, alongside Apple's and Android's own accessibility guidelines.
2. Full support for VoiceOver and TalkBack on every main user task, which you list by name.
3. Support for system text sizes up to the largest setting, with no clipped or overlapping content.
4. Touch targets that meet each platform's stated size.
5. A contrast check on the design files before development starts.
6. Accessibility testing as a named deliverable: checker results plus a screen reader walkthrough of each release.

Legal requirements for app accessibility differ by country and sector, so confirm which apply to you with a qualified adviser; this is not legal advice.

What should you do next?

If the app is not built yet, add the six brief items above to your requirements and ask each prospective supplier how they would test them. If the app is live, turn on the screen reader on your own phone and try to complete your most important task, then set text size to maximum and try again. What you find is a concrete list to take to your developers.

Quick answers

What makes a mobile app accessible?

A mobile app is accessible when people can use it with the phone's assistive features, mainly the screen reader and enlarged text, and when it has labeled controls, large enough touch targets, sufficient color contrast and captions on video.

What is the minimum touch target size for a mobile app?

Android recommends touch targets of at least 48dp by 48dp. Apple lists 44 by 44 points as the default control size on iOS and iPadOS, with 28 by 28 points as the minimum. Checked October 6, 2026.

What color contrast ratio does a mobile app need?

WCAG 2.2 Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Apple and Android use the same figures in their accessibility guidance.

What are VoiceOver and TalkBack?

VoiceOver is the screen reader built into iPhones and iPads, and TalkBack is the screen reader built into Android devices. Both read the screen aloud so people can use an app without seeing it, which only works if the app's controls have text labels.

Can automated tools prove an app is accessible?

No. Tools such as Apple's Accessibility Inspector and Android's Accessibility Scanner find missing labels, small targets and low contrast, but they cannot confirm that a person can complete a task. A manual walkthrough with the screen reader is still needed.

Conclusion

Mobile app accessibility comes down to working with VoiceOver, TalkBack and system text sizes, and getting six basics right. Write them into the brief as measurable requirements, and ask for a screen reader walkthrough as well as checker results.

Entrant Technologies builds mobile apps, websites, web applications and custom software. If you are planning an app, or have one that fails the checks above, contact us and we will take a look.