1. Overview

Android has good accessibility tools, and most of them share one engine. Google's Accessibility Test Framework (ATF) runs inside Accessibility Scanner, the Espresso and Compose test checks and the Play Console pre-launch report. It finds missing labels, small touch targets, low contrast and some ordering problems. Those are real failures, and finding them early is cheap.

But an engine cannot tell whether a label makes sense. It cannot tell if a screen reader user can finish a task. It does not know if a gesture has an alternative, or if an error is announced. Those need a person. So a good plan has three layers:

  • automated checks that run in every build
  • scans and manual tests on a device before each release
  • sessions with disabled people, at least for your key tasks.

The last part of the lesson turns your results into an EN 301 549 record. The European Accessibility Act relies on that record. So do public sector buyers.

Standards covered: EN 301 549 V4.1.1 clause 11 (all of it) and clause 12 (documentation and support) · Annex A.2 Table A.3 (non-web software) with Table A.5 (all ICT) · Annex C test results · WCAG 2.2 Level A and AA through WCAG2ICT · European Accessibility Act Annex I Section III(c), mobile applications.

Unlock the rest of this lesson

You have read the free preview of Testing and shipping an accessible Android app in Module 6: Android accessibility. The full lesson, its knowledge check and the module certificate come with a plan, bought here on the web.

Buy a plan here with a card and the rest of the course unlocks. You will sign in first, with Apple or Google, which is what the plan is attached to. No iPhone or Mac needed.

Buy a plan Already bought? Sign in

Free with no account: the first lesson, Why accessibility, and who it is for, the European Accessibility Act flashcards and the overview of every lesson.

Sources