Android QA
An accessibility test that starts with a real task
Test a complete Android journey with TalkBack, large text, and alternative input—with a reusable evidence checklist.
Choose a real task, complete it with different ways of seeing and interacting, and record where the task breaks. A clean automated scan is useful evidence, but it is not proof that the whole journey is usable.
Test a complete task, not a collection of screens
Imagine a fictional appointment app with a beautifully labelled home screen. A person can find a practitioner and choose a time using TalkBack, but the confirmation dialog leaves focus behind it. They cannot reliably finish the booking. A screen-by-screen checklist might miss the problem because the failure occurs between two screens.
Choose a task that represents the app’s main value. For the appointment example: find a practitioner, select a date, review the price, confirm a test booking, and locate its cancellation control. Include an error state, such as an unavailable time. Use a staging service or disposable booking flow so testing does not create real appointments.
Android’s accessibility guidance recommends combining manual use of accessibility services, analysis tools, automated tests, and user feedback. The workflow below is a practical way to organise those approaches for a small release team. It does not establish compliance with any legal or accessibility standard.
Listen to the journey with TalkBack
Enable TalkBack in Android accessibility settings and complete its introduction if you are unfamiliar with the controls. Record the Android and TalkBack versions because the test environment matters. Navigate through the booking flow in sequence, then explore by touch. Judge whether the purpose and state of each control are understandable when read aloud.
A control announced only as ‘button’ gives no task information. Equally, a card that announces the same practitioner name five times can make a short list exhausting. Capture the actual spoken output and the action the tester expected to take. Note duplicated focus stops, inaccessible controls, and feedback that appears visually but is not announced.
When a dialog opens or a validation error occurs, check where focus moves and how the next action is discovered. After dismissing a dialog, confirm that the person can continue from a sensible point. The goal is not a preferred announcement style; it is a predictable path through the task.
- Can the tester identify each action without relying on its visual icon?
- Are selected dates, unavailable slots, and expanded controls distinguishable?
- Does reading order match the task’s logical sequence?
- Can the tester discover and correct a field error?
- Can the full task be completed and its result verified?
Make the layout work harder
Increase font size and display size in the phone’s settings, recording the settings used. Repeat the same booking journey. Look for truncated appointment times, totals that overlap, hidden confirmation buttons, and dialogs that cannot scroll. Do not accept a screenshot of the home screen as evidence that the checkout or confirmation flow is usable.
Test at the largest supported settings and the smallest screen your product supports. Also use long practitioner names and longer translated strings where relevant. A short English label is a forgiving test fixture; realistic content can expose a layout constraint that otherwise stays invisible.
When reporting an issue, include the content and settings that caused it. ‘Large text broken’ is difficult to reproduce. ‘At this font and display size, the review screen’s Continue control is below an unscrollable panel’ identifies the failed task and gives the developer a starting point.
| Condition | Task checkpoint | A useful pass signal |
|---|---|---|
| Large font and display size | Review the chosen slot and total. | All essential text is readable and the next action is reachable. |
| TalkBack enabled | Change a date and confirm a slot. | Purpose, selection, and result can be understood from spoken feedback. |
| Alternative input | Open and dismiss a confirmation dialog. | Controls can be reached and activated without a touch-only gesture. |
| Validation failure | Recover from an unavailable appointment. | The error and the way to correct it are discoverable. |
Try a route that does not depend on a swipe
If the app has swipe-to-delete, drag-to-reorder, or a custom gesture, examine how someone can perform the same task using an alternative input method. Use Switch Access or a supported external keyboard as appropriate to the product. Record the exact setup rather than assuming every Android phone behaves identically.
For the appointment example, cancellation must be discoverable even if a swipe is unavailable. Follow the complete path to the final confirmation. A focusable icon that cannot be activated is still a blocker. When focus enters a panel or dialog, test that the user can also leave it without restarting the app.
Turn the audit into a small, actionable backlog
Use analysis tools to supplement the manual journey. Android’s documentation describes tools such as Accessibility Scanner and Compose UI Check; which one fits depends on the interface and development setup. Record their findings separately from manually observed task failures so the team can distinguish a detected property from an experienced barrier.
For each finding, capture build, device, Android version, accessibility service and version, text settings, starting screen, steps, expected task outcome, and actual result. Add a short recording or a written announcement transcript with test data. Give a booking blocker higher attention than a repeated but understandable label, based on the product’s agreed release criteria.
After a fix, repeat the original accessibility setup and journey, then check ordinary touch interaction for regressions. When possible, invite people who regularly use the relevant assistive technology to evaluate the flow. A tester learning TalkBack can discover defects, but cannot replace the experience and strategies of its everyday users.