Check your Android app for accessibility issues with an AI agent, and what still needs TalkBack.
Thresholds and tools from Google's docs, checked November 6, 2026: Make apps more accessible, Test your app's accessibility, Accessibility Test Framework, Compose accessibility testing, Accessibility Scanner, Play pre-launch report. Also WCAG 2.2, the European Accessibility Act, BrowserStack, Deque, Evinced.
What to check, and who can check it
| Check | Threshold | From the accessibility tree | Needs |
|---|---|---|---|
| Controls a screen reader can't name | Every clickable element has text or a content description | Yes | Nothing more |
| Duplicate or redundant labels | No two controls on a screen share a label; no "button" in a button's label | Yes | Nothing more |
| Touch target size | 48 by 48dp; Google's tools accept 32dp at the screen edge | Yes, from bounds and the screen density | The density, to turn pixels into dp |
| Text and icon contrast | 4.5:1 for small text, 3:1 for large text and icons | No | Screenshot pixels, or Scanner and ATF |
| Focus order | Swiping moves in a logical order | Partly, from reading order | A person with TalkBack |
| Whether the flow works with TalkBack | Every task can be completed by ear | No | A person with TalkBack |
The tools, and where an agent fits
| Tool | How it runs | Cost |
|---|---|---|
| Accessibility Scanner | An app on the device; you scan screens by hand. Its default contrast bar is 3:1, more lenient than 4.5:1 for small text | Free |
| Espresso AccessibilityChecks | Runs Google's Accessibility Test Framework on every view action in your instrumented tests | Free |
| Compose enableAccessibilityChecks() | The same checks in Compose UI tests, from Compose 1.8 | Free |
| Android lint | Static checks such as missing contentDescription, in Studio or ./gradlew lint | Free |
| Play pre-launch report | Google runs your uploaded build on lab devices and lists labels, contrast and touch-target issues | Part of Play Console |
| BrowserStack App Accessibility, Deque axe DevTools Mobile | Scans on real devices, manual or from Appium and Espresso suites | Not public |
| Evinced Mobile MCP | An MCP tool that scans the current screen of an emulator or USB device | Needs an Evinced account |
| AI agent on a Phonebox phone | Walks the screens you name in the build you ship and reads each one's elements | $0.06 a minute |
Keep ATF checks in your Espresso or Compose tests: they catch regressions on every run. The agent covers screens your tests don't reach, the release build, and flows behind a sign-in, without test code.
Have an agent audit what you changed
Every element a Phonebox phone reports has its text, content description, resource ID, bounds and flags, which is what these checks need. Give your coding agent the phone and the scope:
On my Phonebox phone, open each screen I changed in this branch.
On every screen, read it with phonebox look --json and report:
1. Clickable elements with no text and no content description
2. Clickable elements that share a label with another on the screen
3. Labels that repeat the element type, such as "button" or "image"
4. Clickable elements whose bounds overlap
5. The smallest clickable elements, with their size in pixels
Quote each element's #id and the screen it's on. Take a screenshot
of each screen and list text that may be low contrast, marked as
needing a check. Park the phone when you finish.Bounds come in pixels and the phone doesn't report its density, so treat size findings as candidates and confirm them with Accessibility Scanner or an ATF check. The same goes for contrast read from a screenshot.
Why it matters now
The European Accessibility Act has applied since June 28, 2025 to services such as e-commerce and banking, including their mobile apps; microenterprises providing services are exempt. WCAG 2.2, the reference for most audits, adds a minimum target size (24 by 24 CSS pixels at level AA) to the existing contrast, name, role and value, and focus order criteria.
Questions
Can an AI agent check my Android app for accessibility issues?
Yes, for issues visible in the accessibility tree. On a Phonebox cloud Android phone, a coding agent such as Claude Code reads each element's text, content description, resource ID and bounds, and lists clickable controls with no label, duplicate or redundant labels, and small or overlapping targets. Contrast needs a screenshot or Google's Accessibility Scanner, and whether the app works with TalkBack needs a person.
What is the minimum touch target size on Android?
Google recommends at least 48 by 48dp for touch targets. Its Accessibility Test Framework, used by Accessibility Scanner and the Espresso and Compose checks, accepts 32dp for targets at the edge of the screen. WCAG 2.2's level AA minimum is 24 by 24 CSS pixels, roughly 24dp.
How do I add accessibility checks to Android UI tests?
In Espresso, call AccessibilityChecks.enable() from espresso-accessibility, and setRunChecksFromRootView(true) to check the whole screen. In Compose, from version 1.8, add ui-test-junit4-accessibility and call composeTestRule.enableAccessibilityChecks(). Both run Google's Accessibility Test Framework on each action.
Get started with Phonebox. New accounts start with a free 7-day trial, card required.
The Phonebox team