Testing accessibility in a fitness app

A scanner will tell you that the pause button has no label and that the rest timer's text does not have enough contrast against the video behind it. Fix both and the report goes green. The app can still be unusable during a workout, because the two failures that define this category are not properties of a screen. They are properties of a screen changing while somebody is moving.

This page is the accessibility-specific pass. General test strategy — environments, device labs, what belongs in CI — is the test cluster and is not restated here.

Google's four approaches, and the word "all"#

Google's testing documentation is unusually direct about not picking one:

"For the best results, use all of the approaches described in this document: Manual testing: interact with your app using Android accessibility services. Testing using analysis tools: use tools to discover opportunities to improve your app's accessibility. Automated testing: use Compose testing APIs to automate UI tests. User testing: get feedback from people who interact with your app."

Most teams do the second one, because it produces a list. The first and the fourth are where a fitness app's real defects live, and both of them cost time rather than money.

On the analysis tools, Google describes the scanner: "The Accessibility Scanner app scans your screen and suggests ways to improve the accessibility of your app. Accessibility Scanner uses the Accessibility Test Framework and provides specific suggestions after looking at content labels, clickable items, contrast, and more." Google's testing page also carries a figure caption reading "UI Check Mode shows previews of the UI with recommendations for how to fix insufficient color contrast." We are attributing that as a figure caption because that is what it is, and we did not read a body paragraph describing the feature further.

Apple's equivalent is Accessibility Inspector: "Use Accessibility Inspector to display, query, and test accessibility information for the elements in your app's view hierarchy. Audit your app to confirm that it addresses accessibility issues such as clipped text and unlabeled elements, and uses appropriate text size and color contrast levels." Apple then adds that the information the inspector provides "supplements accessibility testing by providing some of the raw information you need to debug" — our extraction is truncated at that point, so we stop there. The word to notice is supplements. Apple is not claiming the tool is the test.

The two failures tooling will not report#

A screen reader that will not stop talking. A live rep counter, a pace readout or a heart-rate number changes several times a second. Each change is a legitimate update, and an interface that announces every one produces continuous speech that buries the one announcement that mattered. A static screenshot of that screen passes every automated check ever written, because at the instant of the check nothing was wrong. The defect only exists over time.

A flow that is impossible while moving. Every accessibility tool runs while you are seated at a desk with two hands, good light and full attention. The workout flow runs while someone is holding a plank, cycling, or standing under a loaded bar with their forearms shaking. A control that is perfectly labelled and perfectly sized can still be unreachable in the only context where it is used.

Neither failure is exotic. Both are simply outside what a static analysis of a view hierarchy can express, which is why Google lists manual and user testing alongside the tools rather than beneath them.

The script somebody can run today#

This takes about fifteen minutes and finds more than a scanner run. Do it on a real device, on both platforms if you ship both, with the screen reader the platform provides — Google names TalkBack as an example of a screen reader among Android accessibility services.

1. Turn the screen reader on. Do not turn it off again until step 6, including while you are recovering from mistakes.
2. From the home screen of your app, start a workout without looking at the display. Turn the display off, or put the phone face down on the bench, and leave it there.
3. Complete one set. Everything the app is for happens here: know which exercise it is, know the target, start the set, count it, know when the set ended, know how long the rest is, and know when rest is over.
4. Log the result, if your product asks for one.
5. End the workout and confirm out loud what the app said the result was.
6. Turn the display back on and check whether the saved workout matches what you were told.

Write down four things as you go: every moment you had to look at the screen, every moment the reader talked over its own announcement or over an audio cue, every control you could not find, and every point where you did not know what state the app was in. That list is the actual backlog. Nothing on it will appear in a scanner report.

Then run it again, twice. Once while genuinely moving — walk fast, or do the set for real, not a mimed version at your desk. Once with the volume set to where your users have it, competing with music, so you find out which announcements are inaudible in practice rather than in theory.

Then do it with people#

Google's fourth approach is one sentence — "User testing: get feedback from people who interact with your app" — and it is the one that changes a product. Recruit people who use a screen reader, voice control or a switch every day rather than colleagues doing an impression of one. Give them the same task as the script above, with a real session, and stay quiet while they do it.

You are testing the app, not the person: log every stall as a defect in your flow rather than as something the participant needed help with. And pay people for their time.

We are not going to quantify how many of your users need this, because we could not verify a single population figure for this cluster and an invented statistic is worse than none. The argument stands without one: the failures above are also failures for users who are simply out of breath.

What we are not claiming#

Everything above is what Apple's and Google's documentation says about their tools, plus a test procedure. We have measured nothing about how any assistive technology behaves on any device, and we make no claims about app store or platform accessibility review. Anything in this cluster that touches law or policy belongs to compliance.

Monday morning#

Run the six-step script once, yourself, before you schedule anything. It costs an afternoon and produces a defect list nobody can argue with.

Then split the results. Whatever a scanner or the inspector could have caught goes into the automated pass, alongside the rest of your CI arrangements in device lab and CI. Whatever only appeared because the screen was off and you were moving goes on the roadmap as product work. If you ship a watch app, repeat the script there — the surface is smaller and the failures are sharper, per testing watch apps. Fixtures so you can run a session repeatedly without a real ride are in mock wearable data.