Testing Accessibility in a Google Play Closed Test: Font Size, TalkBack and Touch Targets

Most closed-test feedback is about crashes and confusing screens. Very little of it is about what happens when someone sets their phone to a larger font, uses a screen reader, or has trouble tapping a small button. Those problems stay hidden unless you ask testers to look for them.

The fix is simple. Give testers a short accessibility script and spread it across the 14 days. Each task takes a few minutes, and each one can reveal layout bugs that normal use never triggers.

Why a closed test suits this kind of check

On your own phone you test with your own settings. Real testers bring different devices, manufacturer skins, font scales and language settings. That variety is hard to reproduce alone, and it is where text gets clipped and buttons overlap.

It is also cheap to do. Testers are already opening the app daily, so changing one system setting before a session adds almost no effort.

One caveat: your testers are ordinary phone users, not accessibility auditors. They can tell you what looks broken or unusable. They cannot certify that your app meets any standard. Treat this as a practical sanity check, not a compliance audit.

Check 1: Font size and display size

This is the highest-value check because it breaks layouts so often. Android lets users scale text and, separately, scale the size of everything on screen. Both settings are in the system Settings app, usually under Accessibility or Display. Exact menu names vary by device and Android version.

Ask testers to set the font size to the largest option, then open your main screens. What to look for:

• Text cut off, overlapping other text, or hidden behind a button
• Buttons whose labels no longer fit
• Screens that cannot be scrolled when content grows
• Dialogs where the confirm button is pushed off screen

Then repeat with a larger display size. This combination is the usual culprit for forms and settings screens.

On your side, the usual causes are text sized in dp instead of sp, fixed-height containers, and layouts that assume a short label stays short.

Check 2: TalkBack basics

TalkBack is Android's screen reader. Testers who have never used it may find it awkward, and that is fine. You only need a basic pass, not expert use.

Ask one or two willing testers to turn TalkBack on, then try to complete your app's core action, such as creating an item or finishing onboarding. Ask them to note:

1. Any button or icon that is read out as just "button" or "unlabeled"
2. Places where focus gets stuck or jumps in a confusing order
3. Anything important that is never announced, such as an error message or a loading state
4. Any screen they could not get past at all

Unlabeled icon buttons are the most common finding. The fix is usually a contentDescription on the view, or the equivalent in your UI toolkit.

Tell testers how to turn TalkBack off before they start. A first-time user can get stuck in it, and the steps differ between manufacturers. A line like "if you get stuck, check your phone's accessibility settings or search for how to turn off TalkBack on your model" is enough.

Check 3: Contrast, color and dark mode

These checks need no special setup. Ask testers to use the app outdoors or at low screen brightness, and to switch the system between light and dark theme if your app supports both.

• Is any text hard to read against its background?
• Are disabled and enabled states clearly different?
• Does the app rely on color alone, for example red for error and green for success, with no icon or text?
• In dark mode, is any text or icon invisible, or is there a bright white panel left over?

Screenshots are especially useful here, because "hard to read" means different things to different people.

Check 4: Touch targets

Small tap areas frustrate everyone, not only users with motor difficulties. Android's accessibility guidance recommends a minimum touch target of about 48dp. Ask testers a plain question: Was there anything you had to tap more than once to hit?

Typical offenders are close icons on banners, small checkboxes, links inside paragraphs, and items placed close together in a list. You can usually fix them by increasing padding without changing how the screen looks.

A 14-day schedule that doesn't overload testers

Do not send all of this on day one. Testers have about 20 minutes a day with your app, and a long checklist will crowd out normal use. Spread the checks out:

• Days 1–3: normal use, no special settings. You need a baseline first.
• Days 4–6: largest font size, then larger display size.
• Days 7–9: dark mode and contrast checks.
• Days 10–11: touch target question during normal use.
• Days 12–14: optional TalkBack pass for volunteers, then back to normal use to confirm your fixes.

Adjust the order to your app. If your layout is form-heavy, move font scaling earlier so you have time to ship a fix and let testers verify it.

How to ask for the feedback

Vague questions get vague answers. A template like this works better:

Setting you changed:
Screen where you noticed a problem:
What you expected vs. what happened:
Screenshot (if possible):
Phone model and Android version:

That last line matters. If three people report clipped text and all three use the same phone, the cause may be a manufacturer font setting rather than your layout. For more on gathering structured input, see our other posts in the blog.

If you use TesterMob, testers submit written feedback as part of each completed test, so you can put these questions in your test instructions. The optional Android SDK also shows daily tester activity in your dashboard, which helps you see whether people actually opened the app on the days you asked them to try a setting. How it works for developers is covered on the developer page.

Turning findings into fixes

Sort what you receive into three groups:

1. Blocks the core flow: a button unreachable at large font, a screen TalkBack cannot get past. Fix first.
2. Hurts readability: clipped labels, low contrast, missing dark-mode colors. Fix in the same update if you can.
3. Polish: awkward focus order, slightly small targets. Schedule it.

Ship the fixes as a new build during the test and say so in your release notes, so testers know what to re-check. Whether a build change affects the closed-test counter or review depends on current Play Console rules, so check Play Console Help if you are unsure.

For a deeper technical reference on building and testing accessible apps, see the official Android accessibility documentation.

What this won't do

A tester script will not replace proper accessibility testing, and it will not make an app approved for production. Google Play decides access based on its own review, and no outside service can guarantee the outcome. TesterMob cannot either. What this exercise does is catch the problems real users hit first, and give your testers something more useful to report than "looks fine."

If you have questions about how testing on TesterMob works, the FAQ is a good place to start.