Making your app usable with larger text and screen readers

Short answer: You can find most of the serious accessibility problems in your app in about 20 minutes with your own phone: turn text size up to the maximum, switch on the screen reader, and try to complete your app's main task. Apple suggests letting people enlarge text by at least 200 percent and recommends 44 by 44 point controls; Android recommends 48 by 48 dp touch targets and supports font scaling up to 200 percent. Whatever breaks becomes a short, specific list for your developer.

Many people use their phone with larger text, and some navigate entirely by voice output. They may never mention it; they just quietly give up on an app where the "Book" button disappears off the screen. This is a practical test, not an audit. A full review against standards is worth doing for bigger apps, but this will catch the problems that stop people completing a task.

Before you start

Pick the one task that matters most in your app: booking an appointment, placing an order, checking a balance. Test that task from start to finish on each device. Use the live app from the store, not a demo.

You need an iPhone and an Android phone if your app is on both. Borrow one if necessary; the two behave differently.

The 20-minute self-test script

Minutes 0–6: largest text

iPhone: in the accessibility settings, find the larger text option and drag the slider to the largest size. Apple's accessibility guidance describes Dynamic Type as a system-wide setting for text size and says apps should ideally let people enlarge text by at least 200 percent.

Android: set font size to the maximum in the display or accessibility settings. Google's Android 14 features page explains that the system supports font scaling up to 200 percent, using a non-linear curve so large headings grow less than body text, and suggests testing with the maximum font size enabled.

Now open your app and complete the task. Write down:

Text that stays small while the rest of the phone grew. That means the app ignores the setting.
Text that is cut off with "…" or clipped mid-word, especially on buttons and prices.
Overlapping elements, or labels running into icons.
Buttons that move off screen and cannot be scrolled to.
Screens where the layout breaks so badly the task cannot be finished.

Then return text size to normal.

Minutes 6–14: screen reader

iPhone: VoiceOver. Android: TalkBack. Before turning it on, read how to turn it off again, because gestures change: a single tap selects an item and a double tap activates it. Setting up the accessibility shortcut (for example, triple-clicking the side button on iPhone) makes switching quick.

Swipe right to move through each element on screen in order, and listen. Note:

Unlabelled buttons. You hear "button" or a file name like "icon_cart_2" instead of "Basket". Android's accessibility guide says each interactive element needs a description of its purpose, normally in its content description, and that plain text elements are read automatically.
Images that matter with no description, such as a photo that is the only way to tell two products apart. Decorative images should be silent.
Wrong reading order, where the price is read before the product name or the focus jumps around.
Things you cannot reach by swiping, such as content in a custom slider or a pop-up that the screen reader does not focus.
No feedback after actions. You tap "Add" and hear nothing to confirm it worked.
Forms where fields are read without their labels, or errors appear only in red text.

Try to complete the task without looking. If you cannot, neither can a customer who relies on it.

Minutes 14–17: tap targets and spacing

With normal settings, use the app with your thumb, one-handed, on the move if you can. Apple's guidance gives a default control size of 44 by 44 points on iPhone and suggests padding between controls; Android recommends a touch target of at least 48 by 48 dp. Note any small icons, close buttons, checkboxes and links that you miss or hit by accident.

Minutes 17–20: contrast and colour

Look at light grey text on white, text over photos, and disabled-looking buttons that are actually active. Both platforms reference the same contrast levels: Apple and Android cite a minimum ratio of 4.5:1 for normal-sized text and 3:1 for larger or bold text. Android's guide suggests a contrast checker or Google's Accessibility Scanner app to measure it. Also check that nothing relies on colour alone, such as a red outline as the only sign of an error, or green and red dots as the only way to tell available from booked.

Fixes to ask your developer for

Turn your notes into a list like this, with a screenshot for each:

Support system text size. On iOS, use Dynamic Type text styles; on Android, set text in scalable units and let layouts grow. Let buttons and rows expand vertically rather than truncating.
Make layouts reflow. At large sizes, side-by-side elements should stack, and every screen should scroll.
Label every control with its purpose ("Remove item", "Open menu"), not its look ("red X").
Describe meaningful images, and hide decorative ones from screen readers.
Fix reading and focus order so it follows the visual order, and move focus to pop-ups when they appear.
Announce results of actions, such as "Added to basket" or a form error, to the screen reader.
Enlarge tap targets to at least 44 by 44 points on iOS and 48 by 48 dp on Android, with spacing between them.
Raise contrast to at least 4.5:1 for body text, and add icons or text alongside colour cues.
Respect Reduce Motion, which Apple's guidance asks apps to honour by toning down automatic animations.

Ask for these to be checked with the same script before each release. Most are cheap to fix while a screen is being built and more expensive to retrofit.

FAQ

Is this the same as a formal accessibility audit?

No. It catches the most disruptive issues quickly. A formal review against WCAG criteria covers much more and is worth doing for apps with many users or public-sector customers.

Do cross-platform apps (Flutter, React Native) support these settings?

They can, but it depends on how the app was built. Test the actual app rather than assuming the framework handles it.

Will larger text make my app look worse?

If layouts are built to adapt, it will look different but still work. Design with large text in mind from the start, rather than treating it as an edge case.

How often should we repeat the test?

Before every significant release, and whenever a new screen is added.

If your app fails the large-text or screen reader test and you want help prioritising fixes, share what you found.