Accessible Mobile Apps: VoiceOver and TalkBack
By CodexierPublished 5 min read
Accessibility in apps is often treated as a late checklist item, but it affects a large group of real users: people with low vision, motor impairments, dyslexia or simply a cracked screen in bright sunlight. Since June 2025 the Swedish accessibility act also covers apps for e-commerce and several consumer services, so for many companies it is a legal requirement too. The good news is that the most common failures are easy to find and cheap to fix if you test early. This guide shows how.
Screen readers: VoiceOver and TalkBack
A screen reader reads out each element as the user swipes through the screen. It depends on the app telling it what each element is. The most common failures are buttons read as button with no name, icons without labels, images of text, a reading order that jumps around, and custom components that the screen reader cannot activate at all.
- Give every icon button an accessible label that says what it does, such as add to cart, not plus.
- Mark decorative images so they are skipped.
- Check that swiping moves through the screen in a logical order.
- Announce changes: when an error appears or content loads, the screen reader user must be told.
- Make sure modals trap focus, and that closing them returns focus to where the user was.
Dynamic text size
Many users, not just older ones, increase the system text size. Apps that use fixed font sizes ignore that setting, and apps that respect it but have fixed-height containers end up with truncated buttons and overlapping text. Use the platform's text styles, let containers grow, allow text to wrap onto several lines and test at the largest setting. Screens that scroll at large sizes are fine; screens that hide content are not.
Touch targets and gestures
- Apple recommends touch targets of at least 44 by 44 points, Google at least 48 by 48 dp. Small icons can keep their look but need a larger tappable area.
- Leave space between targets so users do not hit the wrong one.
- Every swipe, long-press or multi-finger gesture needs a visible alternative, such as a button or menu item.
- Avoid timeouts that close a screen before a slower user has finished, or let the user extend them.
Contrast and colour
Text needs enough contrast against its background, which under WCAG level AA means a ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text and interface components. Check both light and dark mode, since a palette that works in one often fails in the other. Never use colour alone to show meaning: an error field needs an icon or text as well as red, and a selected tab needs more than a colour change.
The same principles apply on the web; our guide to designing for WCAG 2.2 goes deeper, and the accessibility law for company websites explains who the Swedish act covers.
Testing routine before each release
| Check | Time | How |
|---|---|---|
| Main flow with VoiceOver | 10 minutes | Complete the core task on an iPhone without looking |
| Main flow with TalkBack | 10 minutes | Same on an Android device |
| Largest text size | 5 minutes | Open every changed screen |
| Contrast of new colours | 5 minutes | Contrast checker on new or changed components |
| Automated scan | Minutes | Xcode Accessibility Inspector and Android Accessibility Scanner |
Automated tools catch missing labels and small targets but not whether the flow makes sense. The manual pass is the important part.
The cheapest time to get accessibility right is the design phase. An app prototype and UX design that defines labels, text styles, touch targets and contrast from the start avoids costly fixes later; prices are on the pricing page. When not to buy from us: if your app is already built and you only need a quick audit, start with the routine above yourself. If you find more than you can fix, book a free call.
Frequently asked questions
Does the Swedish accessibility act apply to our app?
It applies to apps used for e-commerce and several consumer services, such as banking and passenger transport, offered by companies that are not microenterprises. Check the act and PTS guidance for your specific service, since the scope has details.
Are cross-platform apps worse for accessibility?
Not inherently. React Native, Flutter and Capacitor all support screen readers, but custom components need labels and roles set correctly. The testing routine is the same.
Can automated tools make an app accessible?
They find a useful share of technical issues quickly, but not whether the flow works for a screen reader user. Always combine them with a manual test.
Should we involve users with disabilities in testing?
Yes, when you can. Even one or two sessions with experienced screen reader users reveal problems no checklist catches. Organisations for people with disabilities can often help you find testers.
Want your next app to work for everyone?
Tell us about your app or idea and who your users are. In fifteen minutes we can point out the biggest accessibility risks and how to design them out from the start.
Book a free 15-minute call