Accessibility is both the right thing to do and a mark of quality, and an app that works well with TalkBack, large fonts, and sufficient contrast reaches a wider audience while feeling more polished to everyone. Many developers treat accessibility as an afterthought, but the fixes are usually straightforward once you find the problems — and the best time to find them is during a period when real people are already using your app. Like any app published from a new personal account, yours must complete a closed test with at least 12 testers opted in for 14 continuous days before production access. This guide covers accessibility testing to run before your Play Store launch.
The closed-testing process is the same as for any app, but accessibility issues only reveal themselves when the app is actually operated with assistive technologies and varied settings, so real-device testing matters. Using your window to run accessibility checks turns the mandatory wait into a more inclusive, higher-quality app.
The requirement and accessibility
The closed-testing requirement is tied to your developer account type, so any app on a new personal account must complete a closed test with 12+ testers for 14 continuous days before production access, regardless of accessibility. See the closed testing guide. The window is a natural opportunity to run accessibility checks and, ideally, get feedback from testers who rely on assistive technology.
Standard advice applies: recruit committed, device-diverse testers, keep your count above 12, and prepare your listing in parallel. If any of your testers use TalkBack or large fonts by default, their feedback on accessibility is especially valuable.
Screen reader (TalkBack) support
The most important accessibility test is operating your app entirely with TalkBack, Android's screen reader, using only spoken feedback and gestures. Every interactive element must have a meaningful content description, the reading order must be logical, focus must move sensibly, and actions must be announced and operable. Turn on TalkBack and try to complete your app's core tasks without looking at the screen — you will quickly find unlabeled buttons ("button, button, button"), images without descriptions, and controls that cannot be reached. Follow Google's accessibility guidance.
Fixing TalkBack support is usually a matter of adding content descriptions, marking decorative elements to be skipped, grouping related content, and ensuring custom views expose their state. Test that dynamic content changes are announced and that no functionality is reachable only by sight or precise touch. Because TalkBack is how blind and low-vision users operate your app, getting it right is the single highest-impact accessibility improvement you can make. See theme and contrast testing.
Text scaling, contrast, and touch targets
Beyond screen readers, several visual and motor accessibility settings must be respected. Users can increase system font size, and your layouts must accommodate large text without clipping, overlapping, or cutting off content — a common failure when text is assumed to be a fixed size. Color contrast must be sufficient for low-vision users in both light and dark themes, and you should not rely on color alone to convey meaning. Touch targets must be large enough to hit reliably, which also helps users with motor impairments.
| Accessibility setting | What to verify |
|---|---|
| Largest font size | No clipping or overlap; content reachable |
| Color contrast | Meets ratios in both themes |
| Color-only meaning | Also conveyed by text or icon |
| Touch target size | Large enough to hit reliably |
| Display scaling | Layout holds at larger scale |
Test at the largest font and display scale, where most layouts break. See layout testing.
Using accessibility tools and real users
Google provides the Accessibility Scanner app, which analyzes your screens and flags issues like small touch targets, low contrast, and missing labels, giving you a fast, systematic first pass. Run it across your app during your window and fix what it finds. But automated tools catch only part of the picture — they cannot judge whether your reading order makes sense or whether a task is genuinely completable with TalkBack — so combine the scanner with hands-on testing and, where possible, feedback from real users of assistive technology.
If any of your closed testers rely on accessibility features, their real-world feedback is invaluable, revealing friction that neither you nor an automated tool would notice. Even testers who do not normally use these features can help by attempting tasks with TalkBack on or at the largest font size. Because accessibility is ultimately about real people accomplishing real tasks, combining tooling with human testing during your window produces the most inclusive result. See the testing checklist.
Setting up your closed-testing track
Once your signed release build is ready, create a closed-testing track in the Play Console and upload it, add testers by email or Google Group, and share the opt-in link each tester must use before installing. Correct configuration matters because the 14-day clock counts only opted-in testers, and a misconfigured track is a common reason developers realize late that their timer never started. Install on a real device, run the Accessibility Scanner, and try TalkBack before inviting your full group. See how to create a closed testing track.
Give testers clear onboarding instructions and ask them to try the app with TalkBack on or at a large font size, reporting anything they cannot read, reach, or operate. Every failed opt-in is a tester who does not count toward your 12, so smooth guidance maximizes active testers from day one and gives you accessibility coverage across devices.
Recruiting and managing the window
You need 12+ committed, device-diverse testers for 14 continuous days, and testers who use assistive technology are especially valuable for this work. Recruit a buffer above 12, keep testers engaged with clear tasks and quick responses, and ask them to exercise accessibility scenarios. Monitor your active count in the Play Console and recruit replacements early if it slips.
If assembling a diverse group, including testers who rely on accessibility features, is your bottleneck, a service that supplies verified real testers can help. You can submit your app to get started, and read where to find real testers and how to keep testers engaged.
Why real-device testing matters here
Accessibility can only be truly validated by operating the app with real assistive technologies and settings on real devices, because the experience of navigating with TalkBack or at the largest font size is not something a code review or a single mockup captures. The failures that exclude users — unlabeled controls, illogical focus order, clipped text at large sizes — appear only when the app is actually operated this way. Only hands-on testing, ideally with real assistive-technology users, reveals whether your app is genuinely usable.
This is why the closed-testing window is a good opportunity for accessibility work: you have real people using your app, and you can ask them to exercise accessibility scenarios and report friction. The window is your structured chance to make your app inclusive before launch, and involving testers with varied needs and devices is what makes that effort meaningful rather than a checkbox. See device testing.
Common accessibility pitfalls
The most common accessibility pitfalls are: unlabeled buttons and images that TalkBack announces meaninglessly; layouts that clip or overlap at large font sizes; insufficient contrast; meaning conveyed by color alone; touch targets that are too small; and custom controls that do not expose their state to assistive technology. Each is usually easy to fix once found, and each is far cheaper to catch during your window than after excluding real users at launch.
Use the 14 days to audit against these pitfalls with the scanner and hands-on TalkBack testing: confirm every control is labeled, layouts survive large text, contrast is sufficient, and tasks are completable without sight. Catching these before production is what makes your app inclusive and higher-quality for everyone. See UI testing before publishing.
Making the 14-day window count
Because the requirement forces you to test anyway, use the window to run a genuine accessibility pass rather than treating it as an afterthought. Run the Accessibility Scanner, operate your core flows with TalkBack, test at the largest font, and gather feedback from any testers who use assistive technology. A well-run window turns a mandatory delay into an app that welcomes a wider audience and feels more polished to all users.
Enter production having confirmed your app is operable with a screen reader, holds up at large text, and meets contrast standards, and you deliver both inclusivity and quality. The 14 days are an investment in reaching every user and in the craftsmanship of your app. See the Play Console beginner guide.
Turning tester feedback into fixes
Give testers a frictionless way to report problems and ask specific questions: could you complete tasks with TalkBack, was anything unlabeled or unreachable, did text clip at large sizes, was anything hard to read or tap? Concrete questions produce the actionable reports that let you fix the accessibility issues most likely to exclude users.
Then close the loop: when you ship a build addressing reported issues, tell testers what changed and ask them to reconfirm with the relevant assistive settings. This validates fixes and keeps testers engaged. An app that enters production having already addressed its accessibility gaps launches inclusive and polished rather than inadvertently excluding part of its audience. See fixing crashes before production.
Use internal testing before your closed test
The Play Console's internal testing track is faster than the closed track and ideal for a first pass. For accessibility, use it to run the Accessibility Scanner and a quick TalkBack sweep on a couple of devices before your counted 14-day window begins. Catching glaring issues like unlabeled primary buttons privately, rather than during your closed test, lets your window focus on the deeper, task-level accessibility feedback that real users provide.
A practical rhythm is to validate each release candidate on the internal track, fix the obvious scanner findings, then promote it to the closed track where testers, ideally including assistive-technology users, exercise real tasks. This staging discipline keeps the closed track stable and your feedback focused on genuine usability rather than basic labeling errors. See internal vs closed testing.
After launch: keeping the app inclusive
Your closed test is the start of quality assurance, not the end. After launch, keep accessibility in mind as you add features, since a new screen with unlabeled controls or a redesign that shrinks touch targets can quietly reintroduce exclusion. Re-run the scanner and a TalkBack check with each significant update, and take accessibility feedback in reviews seriously. An app that sustains its accessibility as it grows keeps welcoming every user; one that neglects it with each new feature slowly shuts people out. See post-launch monitoring.
Key takeaways
- The 12-tester, 14-day requirement applies regardless of accessibility.
- Operate your app entirely with TalkBack and fix unlabeled or unreachable elements.
- Test at the largest font and display scale where layouts often break.
- Meet contrast standards and never rely on color alone.
- Combine the Accessibility Scanner with hands-on and real-user testing.
Frequently asked questions
Is accessibility required for Google Play?
Closed testing is required regardless. Accessibility is not strictly mandatory but is a quality signal, expands your audience, and is the right thing to do.
What is the most important accessibility test?
Operating your app entirely with TalkBack, completing core tasks using only spoken feedback and gestures.
What tool helps find accessibility issues?
Google's Accessibility Scanner flags small touch targets, low contrast, and missing labels, giving a fast first pass to complement hands-on testing.
Why does my layout break at large font sizes?
Because it assumes fixed text sizes. Test at the largest system font and ensure content scales without clipping or overlapping.
How do I test with real assistive-technology users?
Recruit testers who use TalkBack or large fonts, through your network or a service, and gather their feedback during your window.
Should I use internal testing first?
Yes. Run the scanner and a TalkBack sweep on the faster internal track before your counted closed-testing window begins.
Are accessibility fixes hard?
Usually not — most are adding content descriptions, fixing focus order, improving contrast, and enlarging touch targets once you find the problems.