App design · 11 Nov 2026 · 7 min read
Mobile app accessibility: what to check and how to test
An accessible app can be used by people who see, hear, move or think differently, and by anyone in poor conditions. This guide gives you checks you can run on your own phone today.
The short answer
Mobile app accessibility means people can use the app with large text, a screen reader, voice control, switch devices or one hand. Start with text size, contrast, touch target size, labels on every control and a logical reading order. Then test the main journey with VoiceOver on iPhone and TalkBack on Android.
Mobile app accessibility: who it is for
Mobile app accessibility is the practice of building an app so that people with different abilities can complete the same tasks. That includes people who are blind or have low vision, people who are deaf or hard of hearing, people with limited movement or a tremor, and people with dyslexia or memory and attention differences. It also helps in ordinary circumstances: a customer holding a bag in one hand, someone on a train with glare on the screen, a person whose wrist is in a cast.
Both major phone platforms ship accessibility settings and services, including a screen reader, larger text, magnification, voice control and options to reduce motion. An accessible app works with those settings instead of fighting them. The names and menus change between system versions, so check the current documentation for each platform.
Ten-minute checks on your own phone
You can learn a lot before anyone writes a test plan. Open your app, or a prototype of it, and try these in turn.
- Raise the system text size to a large setting and open the app. Is any text cut off, overlapping or unreadable? Do buttons still fit their labels?
- Turn the screen brightness down, or take the phone outside. Can you still read grey text on a white background?
- Hold the phone in one hand and use only your thumb. Can you reach the main actions? Are the close buttons tiny and in a far corner?
- Look for meaning carried by colour alone, such as a red border for an error with no message, or a green dot for available with no label.
- If your phone has a reduce motion setting, switch it on and check that animations calm down.
- Play any video with the sound off. Does it explain something that is never written down?
- Fill in a form with a deliberate mistake. Does the error appear next to the field, say what to fix, and stay on screen long enough to read?
- Find any message that disappears after a few seconds. Is there enough time to read it?
What to check first, and how
The table puts the checks in the order that usually matters most for a first release.
| Area | What good looks like | Quick test |
|---|---|---|
| Text size | Text grows with the system setting and layouts adapt without clipping | Set the biggest text size and open every main screen |
| Contrast | Text and icons stand out clearly from the background | Look in bright light, and run the design files through a contrast checker |
| Touch targets | Buttons are big enough to tap and are not packed together | Tap with a thumb; each platform publishes a recommended minimum size, so check it |
| Labels | Every button, icon and field has a name that a screen reader can speak | Turn on a screen reader and listen |
| Reading order | Items are read in a logical sequence | Swipe through each screen one item at a time |
| Colour alone | Nothing depends on colour to be understood | View the screen in greyscale |
| Media | Captions or a transcript for speech, and no flashing content | Play every video muted |
| Forms | Errors are clear, close to the field and stay visible | Submit wrong entries on purpose |
| Motion and timing | Animation can be reduced, and timed content can be extended | Switch on reduce motion and wait on timed screens |
The Web Content Accessibility Guidelines set minimum contrast ratios for text. Check the current version on the W3C site for the figures that apply, and use them as the target for your designer.
How to test with a screen reader
A screen reader speaks what is on screen and lets people move through it without seeing it. Apple's is VoiceOver and Android's is TalkBack. Both are built in and free. Learn the basics first: how to switch it on in the accessibility settings, how to move to the next item, how to activate the item in focus, which is a double tap on both, and how to scroll. The platforms' help pages explain the current gestures. Practise on the home screen before you open your app.
Then run a script built around your main journey. Use a real task, for example: open the app, sign in, find a product, add it to the basket, pay, and find the confirmation.
- With the screen reader on, open the app and swipe through the first screen. Listen to each item. Write down any that are read out as button or image with no name.
- Complete the task with the screen dimmed or turned away from you. Note where you get lost.
- Open a pop-up or a sheet. Does the focus move into it, and is the background ignored while it is open? When you close it, does focus return to a sensible place?
- Submit a form with an error. Is the error announced without you hunting for it?
- Check that controls say what they are and what state they are in, such as a switch that says on or off, or a tab that says it is selected.
Common failures are icon-only buttons without names, images with useless descriptions such as a file name, decorative images that are read out anyway, custom controls that look like buttons but are read as plain text, and a reading order that follows the code instead of the layout. Report each with the screen, the item and what you heard.
Automated scanners can flag missing labels and some contrast problems. They cannot tell whether a label makes sense or whether the journey is usable. Treat them as a first pass, not a result.
Build it in at the design stage
Accessibility is usually less work to include in the design than to add after the build. At the wireframe stage, mark the reading order of each screen, note which images need descriptions, and show how errors will appear. The guide to app wireframes and prototypes describes what each stage is for, and a prototype is a good place to test text size and touch targets before any code exists.
Put the requirements in writing. In the app brief for your developer, say that the app must work with the platform's text size, screen reader and reduce motion settings, that every control needs an accessible name, and that you will test with VoiceOver and TalkBack before you approve a release.
The technology choice matters a little. Standard controls supplied by the platform usually bring accessibility behaviour with them. Custom-drawn controls, and some cross-platform components, need that behaviour added by hand. The guide to native apps and web apps compares the approaches. Ask any developer how they will handle accessibility in the one they propose.
Payment and shopping screens
Screens that take money are where a failure costs most. The store's own payment sheet is provided by the platform, but the screens around it, such as the plan comparison, the terms and the restore button, are yours to make accessible. In-app purchases and subscriptions basics explains what those screens must show.
If you already have an online shop, the app should not be a step back from it. Ecommerce website vs mobile app compares what each does well. Carry the website's accessible patterns across, such as clear error messages and labelled fields, and test the app's checkout with a screen reader as carefully as the website's.
Standards, law and keeping it up
The W3C publishes the Web Content Accessibility Guidelines, usually shortened to WCAG. They were written for the web, but their principles, such as sufficient contrast, text alternatives and controls that can be operated in several ways, are used as a reference for apps too. Check the W3C's current pages on how they apply to mobile. Laws and public-sector rules on accessibility differ by country and change, and some apply to private businesses while others do not. Ask a lawyer about the markets you sell into rather than relying on a general guide.
Accessibility fades unless it is checked. Add a short pass to the release checklist: text size, a screen reader on the main journey, and any new screen. Give users a way to report barriers, such as an email address on the support screen, and read what arrives. To plan an accessible app with a development team, see the mobile app development page from Liftup Technologies.
Related guides
- Mobile app development
- How to write an app brief for a developer
- Native app vs web app what should you build first
- Ecommerce website vs mobile app for your store
- How to test a mobile app before launch
- Mobile app development process from idea to launch
Questions and answers
What is mobile app accessibility?
It is building an app so that people with different abilities, and people in difficult conditions, can complete the same tasks. It covers text size, contrast, touch targets, screen reader support, captions, timing and clear errors. Both phone platforms provide settings that a good app respects.
What should I check first in an app?
Start with text size, contrast, touch target size, labels on every button and icon, and the reading order of each screen. These are quick to test on your own phone and catch many of the problems that stop people finishing a task.
How do I test an app with a screen reader?
Switch on VoiceOver on an iPhone or TalkBack on Android, learn the basic gestures, then complete your main task, such as signing in and buying something, without relying on the screen. Note every unnamed control, wrong reading order and lost focus, and report each with the screen and what you heard.
Is accessibility only for people with disabilities?
No. Larger text, clear contrast, big touch targets and captions help people with a temporary injury, people using one hand, people in bright light or noise, and older users. Designing for a wide range of abilities usually makes the app easier for everyone.
Can an automated tool test app accessibility for me?
Automated tools find some problems, such as missing labels and low contrast, but they cannot judge whether a label makes sense or whether a person can finish a task. Use them as a first pass and follow with manual checks and a screen reader test.
Should accessibility be in the first version of an app?
The basics should be. Text that scales, readable contrast, labelled controls and a sensible reading order are much easier to build in from the design stage than to add later. More advanced work can follow in later releases once the main journey works for everyone.
Tell us what you are building.
A short call, a written plan and a fixed quote. No obligation.