Android Accessibility Testing: A Task-Based Release Checklist

Define representative journeys

Select onboarding, authentication, the core task, settings and any purchase or deletion flow. Include tasks that use custom gestures, charts, drag-and-drop or time limits, because their alternatives need deliberate design.

For each journey, document the expected result and the accessible means of reaching it. A gesture-only action should have an appropriate non-gesture alternative where required.

Exercise multiple interaction modes

Test dialogs, error messages and loading completion. Focus should move deliberately and return sensibly when an overlay closes.

Automate stable assertions

Use the appropriate Compose or Views testing tools to assert labels, state and important actions. Automated checks help prevent regressions, but they cannot assess every meaningful reading order or task explanation.

Keep manual findings alongside automated results. A passing semantics test does not prove a custom control is comfortable to use with a real assistive technology.

Fix the product, not the report

Avoid removing focusability from a necessary control merely to suppress duplicate-focus warnings. Correct the grouping, labeling and interaction model. Test the fix using the same journey that revealed the problem.

APKLint's accessibility review tool can organize checks; it does not run a complete device audit. Android's testing methods and implementation guidance should be combined with user feedback.

WCAG 2.2 is a web-content standard; applying its principles to native apps requires context and may involve other standards or local obligations. Do not claim native-app certification solely because a website scanner reports no errors. Describe the actual test scope and remaining limitations using the WCAG reference where relevant.