Mobile App Accessibility: How to Test with VoiceOver and TalkBack

In this guide, Talha Aslan and team skip the general accessibility overview. We focus on one question: can someone actually use your app with a screen reader? So every section ends with a checklist, a decision table, or numbered test steps. We leave out code on purpose. That way, a product owner, a designer, and a QA tester can all work from the same list. If you want the web side of the standards, our article on web accessibility and WCAG covers it separately.

How does a screen reader read an app?

A screen reader is a system service that speaks each element on screen in order. On iPhone and iPad, it is VoiceOver. On Android, it is TalkBack. The user swipes right or left to move to the next element and double taps to activate the selected one. The Android developer docs call these two paths linear navigation and explore by touch.

For each element, a screen reader speaks three things: its name (the label), its type (button, switch, heading), and its state (selected, off) when there is one. Therefore, your app has to supply all three correctly. An icon that looks perfectly clear on screen reads as just "button" if it has no label. The user then has to guess what it does. That is the core of accessibility testing: you use the app with your ears, not your eyes.

How do you turn on VoiceOver for testing?

You turn on VoiceOver in the Accessibility section of the iPhone Settings app. The gestures feel different at first, so practice for a few minutes before you test. These steps make testing easier:

1. Set the Accessibility Shortcut to VoiceOver, so you can toggle it with a triple press of the side button.
2. Swipe right with one finger to hear every element on a screen in order.
3. Double tap to activate the selected element, and listen for whether the result gets announced.
4. Try the rotor gesture to jump between headings. If headings are not marked as headings, this jump fails.
5. Turn on Screen Curtain to black out the display, so you test without seeing anything.

The last step teaches the most. When you can see the screen, your eyes fill in what the audio leaves out. Once the screen goes dark, you feel the same uncertainty your users feel. Apple's Human Interface Guidelines on accessibility cover the design side of this, including labels, text size, and color.

How do you turn on TalkBack for testing?

According to the Android accessibility testing guide, you open the device Settings app, go to Accessibility, select TalkBack, and switch it on. A tutorial starts the first time. Do not skip it, because a test you run without knowing the gestures will mislead you.

The docs also describe two helper settings for testers. In TalkBack's developer settings, you can set the log output level to verbose and turn on the option to display speech output on screen. As a result, you both hear and read what TalkBack says. This helps a lot when you write bug reports. Instead of "the button reads wrong," you write exactly what you heard.

During a TalkBack pass, ask the questions the docs suggest. Does the spoken feedback for each element convey its content or purpose? Are announcements short, or needlessly long? Can you finish the main workflows easily? Can you reach every element by swiping? Do alerts and temporary messages get read aloud?

How do you write screen reader labels for mobile app accessibility?

A label is the name a screen reader speaks for an element. A good label is short, unique, and focused on purpose. The Android docs set a few clear rules. Describe the purpose and result of the interaction, not the visual details. Also, do not put the element type in the label, because the system already announces it. For example, a submit button's label should be "Submit," not "Submit button."

In addition, each label should be unique. If a list has ten "Delete" buttons, users cannot tell which one deletes which item. So add the item name: "Delete Chicago address." Also, hide purely decorative images from the screen reader. Otherwise, users waste time on elements that mean nothing. Use this checklist to review labels:

• Does every icon button have a label?
• Do labels describe the action rather than the picture?
• Do labels repeat type words like "button" or "icon"?
• Are repeated buttons in list items unique?
• Are decorative images hidden from the screen reader?
• Does each form field label match the meaning of the visible text above it?

Why do reading order and focus matter so much?

A screen reader reads elements in a set order. If that order does not match the visual layout, users cannot build a picture of the screen. For instance, if a product card reads the price first, then the name, and the image last, the user cannot tell what the price belongs to. The Android docs note that the Play Console pre-launch report lists this kind of issue under "Implementation," as a traversal order that does not match the logical layout.

Focus management matters just as much. When a dialog opens, focus should move into it. When it closes, focus should return to where the user came from. Also, when an error message appears, the screen reader should announce it. If it does not, the user never learns why the form will not submit. Here is an example scenario. A user opens a date picker in a booking form, but focus stays stuck on the form behind it. They never hear that the picker opened, so they cannot finish the booking.

To test this, ask three questions. Does the reading order follow the screen top to bottom in a logical way? Also, does new content take focus when it opens? Does closing content hand focus back to the right place?

How large should touch targets be?

A touch target is the area of a button or link that a finger can hit. However, small targets do not only hurt people with motor disabilities. They hurt anyone who uses a phone while walking. Android's guide to making apps more accessible recommends a touch target of at least 48dp by 48dp for each interactive element, and it adds that larger is better. Most built-in components already meet this size. For custom elements, however, you have to set it yourself.

On the Apple side, the Human Interface Guidelines also ask for controls that are large enough and spaced enough to tap comfortably. Check the current size in the guidelines themselves. That said, a small visual icon is fine. You can keep the icon small and enlarge the tappable area around it. Also, do not place two targets too close together. Hitting the wrong one causes real trouble with actions like delete or pay. For placement, our guide to the thumb zone covers where thumbs reach easily.

How do you test dynamic text size?

Many people enlarge the text size on their phones. On iOS, this feature is Dynamic Type. On Android, it lives in the font size and display size settings. If your app uses system text styles, text grows with the setting. If you hard coded text sizes, the setting changes nothing, and the user is stuck with small text.

Run the test with these steps:

1. Set the device text size to the largest value.
2. Open every main screen and confirm the text grows.
3. Look for text that gets cut off, overlaps, or spills out of buttons.
4. Check that long text scrolls and stays fully readable.
5. Repeat the check in landscape.

The most common issue we see is text clipping inside buttons with a fixed height. So plan buttons and cards that can grow with their text during design, not after launch.

What color contrast ratio should you use?

Contrast is the difference in perceived brightness between text color and background color. The Android guide gives a clear threshold. Text smaller than 18sp, or bold text smaller than 14sp, should reach a contrast ratio of at least 4.5:1. All other text should reach at least 3:1. These ratios line up with the WCAG thresholds on the web side as well.

In addition, contrast matters for meaningful icons and form field borders too, not only text. Also, never convey information through color alone. For example, painting an invalid field red tells nothing to someone who has trouble telling colors apart. Instead, pair the color with an icon and a short error message. Use this checklist:

• Do body text and small labels reach at least 4.5:1?
• Do large headings and large text reach at least 3:1?
• Can people still read disabled buttons?
• Do error, warning, and success states carry a signal besides color?
• Does dark mode keep the same ratios?

Which tools help with mobile app accessibility testing?

Manual testing always comes first, but tools catch what slips past you. This decision table sums up what each tool is good for:

The Android docs explain that the pre-launch report for a build you upload to Play Console groups accessibility findings into touch target size, low contrast, content labeling, and implementation. Think of it as a free second pair of eyes. Still, it does not replace manual testing.

Which screens should you test first?

For example, your app may have dozens of screens. Trying to test them all at once wears the team out and leaves the job half done. Instead, start with the flows that make people open the app. In most apps, the order looks like this:

1. Sign up and sign in, because if users cannot get past these, nothing else is reachable.
2. The home screen and main navigation.
3. Search and list screens.
4. The product, service, or content detail screen.
5. Cart, checkout, or form submission steps.
6. Settings, profile, and support screens.

Testing the first four items within a week usually surfaces most of the critical issues. Then, if you fix shared problems at the design system level, the remaining screens improve on their own. For instance, fixing the reading order of one card component fixes every list that uses that card.

How do you test one screen step by step?

In practice, following the same order on every screen makes the test repeatable. Our team uses this sequence:

1. Turn on the screen reader and confirm the screen title is the first thing it reads.
2. Swipe right through every element. Note any element that has no label, makes no sense, or repeats.
3. Finish the main task by sound alone. For example, fill in a form and submit it.
4. Enter an invalid value and check that the error message gets announced.
5. Open a dialog or bottom sheet, and check whether focus moves into it.
6. Set text size to the largest value and check the screen again.
7. Measure contrast with a tool and review touch targets.
8. Log each issue with the screen name, element, expected announcement, and heard announcement.

If you turn this sequence into a test template, you can check the same screens in a few minutes on every release. That way, accessibility stops being a one time project and becomes part of shipping. Also, use the same device and the same settings each time, so differences between releases stand out.

What should you do if your team cannot fix the issues alone?

You ran the test and got a long list of issues. At this point, most teams face the same pattern. Some issues come from the design system, some from custom components, and some from the app's overall structure. Adding labels is easy, because it is local work. However, adapting a fixed height design system to dynamic text, or rebuilding focus management, is architecture work.

To set priorities, fix the main workflows first: sign in, search, add to cart, checkout, and form submission. If users cannot finish those, other fixes lose their value. If this goes beyond your team's capacity, our mobile app development projects build accessibility in from the design system to the test template, so every new screen starts with the same rules. Also, if your app runs on a cross platform stack, our article on React Native explains what the two platforms share and where they differ.

How do gestures, animation, and time limits affect accessibility?

If some actions only work through complex gestures, people who use a screen reader or Switch Access cannot reach them. For example, if a list only allows delete through a left swipe, offer the same action through a menu or a custom action too. The Android docs suggest asking, during Switch Access testing, whether every touch gesture function is also available as a selectable control or custom action.

For animation, do not show large transition effects to users who turned on the system's reduce motion setting. In addition, notifications that vanish on their own may disappear before a screen reader user hears them. Keep important messages on screen, or give them enough time. For time limited actions, such as a verification code, let users extend the time. In short, every interaction needs a path that does not depend on fast, precise finger movement.

How do you make forms and error messages accessible?

Forms are where most mobile accessibility issues pile up. First, every field needs a visible, persistent label. Do not rely on faint placeholder text inside the field alone. It disappears once the user starts typing, and screen readers do not always read it reliably.

Rule two: error messages must be both visual and audible. When the user submits a form with errors, focus should move to the first invalid field, and the message should get announced. The message itself should also explain the fix. Instead of "Invalid input," write something like "Phone number must have 10 digits." Rule three: match the keyboard type to the field. An email field should open the email keyboard, and a phone field should open the number pad. Moreover, autofill support cuts typing effort a lot for users with motor disabilities.

How do you announce offline and status messages to a screen reader?

In general, every status change that shows up visually should also be audible to screen reader users. If messages like a progress indicator, a "saved" notice, or a connection lost warning stay silent, users may think the app froze. The Android docs specifically suggest checking during TalkBack testing that temporary alerts get read aloud. For short status messages, our guide on toast notification design covers wording and timing.

This matters most in apps where the connection comes and goes. Status labels that show whether a record stays on the device or reached the server should be readable by screen readers too. Our sibling article on offline mode in mobile apps explains how to design those labels. On the accessibility side, the rule is simple. Every important change you can see should also be something you can hear.

How do you make images, charts, and video accessible?

First, every image that carries information needs a text equivalent. A short description works for a product photo. However, if a chart or a table image conveys data, screen reader users need the same data. So state the main takeaway in text next to the chart, or offer the data as a readable list. For example, one sentence like "Sales rose compared to last month" is worth more to a screen reader user than the whole chart.

For video and audio, captions are a basic requirement for deaf and hard of hearing users. Also, autoplaying video with sound talks over the screen reader and puts the user in a tough spot. Therefore, let the user start videos, and label the playback controls. For alt text and caption habits on social platforms, our guide on social media accessibility covers similar principles.

Is accessibility testing different on iOS and Android?

In principle, the rules are the same on both platforms. Every element needs a name, a type, and a state. Text should scale. Contrast should be enough. However, the details differ. Gestures look alike but are not identical. For example, the VoiceOver rotor and TalkBack's reading controls work differently. So the person who tests on your team needs to learn both screen readers separately.

Moreover, an app built from one codebase can still announce things differently on each platform. A cross platform framework may pass a label correctly on one platform and drop it on the other. As a result, "we tested on Android, so iOS is fine" is not a safe assumption. On every release, finish the main workflows by sound at least once on both platforms. Also, remember that text size settings use different names and ranges on each system. Testing at the largest value is the scenario that breaks the most on both.

How do you report accessibility issues so they get fixed?

Put simply, a good bug report lets a developer reproduce the issue and fix it fast. For accessibility bugs, a vague note like "the screen reader doesn't work" does not help. Instead, fill in these fields on every ticket: platform and screen reader, screen name, element, expected announcement, heard announcement, user impact, and suggested fix. For example: "Android, TalkBack, cart screen, trash icon. Expected 'Remove item from cart.' Heard 'Button.' User cannot remove the item."

Next, sort issues by impact. A bug that blocks a whole workflow goes to the top, while cosmetic issues can wait. That way, you spend limited development time on what affects the most users. TalkBack's option to display speech output on screen makes writing these reports much easier.

Does the European Accessibility Act apply to mobile apps?

The European Union's European Accessibility Act (EAA) sets accessibility requirements for certain products and services. The services in scope include consumer services such as e-commerce and banking, and the mobile apps that deliver those services fall under the scope as well. So if your company serves consumers in the EU through an app, treat mobile app accessibility as a possible legal duty, not only a good practice. This applies even if your business sits in the United States.

Scope, exemptions, and national enforcement details can change, so check the current status in official sources. We cover how the law affects websites and how to assess scope in our article on whether the European Accessibility Act applies to you. This section is not legal advice, so work with your legal counsel on your own situation.

Why does accessibility cost more when you add it later?

Teams that try to add accessibility after launch hit the same wall. Most issues do not live on a single screen. They live in the design system itself. Fixed height buttons, the color palette, custom components, and reading order repeat across every screen. Therefore, fixing one bug often means changing dozens of screens at once.

In other words, this buildup is a kind of technical debt. Our sibling article on technical debt in software projects explains the concept and how to manage it. In accessibility, the way to reduce that debt is simple. Write contrast, text size, and touch target rules into the design system from the start, and do not accept any new component until someone tests it with a screen reader. Moreover, these rules help everyone, from people using a phone in bright sun to people tapping with one hand.

What is the final mobile app accessibility checklist?

We turned this guide into a list you can tick off before every release:

• Can users finish the main workflows by sound alone with VoiceOver and TalkBack?
• Does every interactive element have a short, unique, purpose focused label?
• Does reading order match the visual layout, and does focus move into new content?
• Do touch targets meet platform recommendations?
• Does any text clip or overflow at the largest text size?
• Do contrast ratios meet the thresholds, and does any information rely on color alone?
• Do gestures like swipe have an alternative path?
• Does the screen reader announce error and status messages?
• Did you review warnings from the pre-launch report and scanner tools?

If you use this list before every release, accessibility becomes a habit rather than a campaign. If you want to build your app accessible from day one, or bring an existing app up to this list, our custom mobile app development page explains how we work.