Can Someone Finish the Task in Your App?

Start with one task: create a reminder, book a session, save a note, complete a level. Follow it from opening the app to knowing it worked. Three questions turn inclusivity into something you can actually test — information, setup, and outcome.

Before you start

Use a real device and the current build. Write down the task and what counts as success, and include onboarding, permission prompts, and sign-in screens — they stand between someone and that outcome.

Run the task normally first. Then repeat it with one accessibility setting at a time, and record the first barrier and what it does to the task.

1. Can they understand what’s happening?

Imagine a timer that turns a ring from green to red when time runs out. What happens if someone can’t tell those colours apart, or can’t hear the only other signal? Give important states a second signal that carries the same meaning: visible words, a distinct symbol, something assistive technology can report.

• Move through the task with VoiceOver on. Do controls have meaningful names and states, and is the reading order sensible?
• Check icon-only buttons, custom controls, progress indicators, and success or error messages.
• Mute the device. Can you still understand essential alerts?
• Look at selected, failed, and completed states. Does the meaning survive without the colour?

Example: a save icon turns green. Add a visible “Saved” state VoiceOver can report — without interrupting the person repeatedly as they work.

2. Can they adjust the experience before the barrier?

Open your app with accessibility preferences already on. The first screen matters as much as the settings screen. Respect the system preferences first, and add your own controls only where they give real extra flexibility.

• Raise the text size into the large accessibility sizes. Check onboarding, sheets, alerts, and the final action in the task.
• Watch for clipped labels, overlapping rows, or a Continue button pushed out of reach. Let layouts grow or stack.
• Turn on Reduce Motion. Check big zooms, parallax, and automatic movement, and keep what the transition meant.
• If your app needs its own adjustments, put them before the activity that depends on them — and check they stick.

Example: a game offers simplified controls, but only after a gesture-heavy tutorial. Move that choice before the tutorial, and make the choice itself accessible.

3. Can they finish the task their way?

Keep going past the first accessible screen. The review ends when someone can complete the task, recover from a mistake, and recognise the result.

• Complete the whole flow with VoiceOver, including opening and dismissing sheets.
• Check whether a precise drag, swipe, or timed gesture is the only way to do something essential.
• Try Voice Control and Switch Control on your key actions.
• Trigger an error on purpose. Can someone find it, understand it, and fix it without losing their work?
• Check the final confirmation makes sense using the same method that got them there.

Example: a reminder app needs a tiny marker dragged to set a time. Add an accessible time picker as a second route — both should create, edit, and confirm the same reminder.

Copy this review template

One copy per barrier. It keeps a finding specific enough to fix, and to retest.

Task:
Successful outcome:
App build / device / iOS or iPadOS version:
Accessibility setting or interaction method:

Steps to reproduce:
What happened:
What should happen:
Effect on the person: blocked / difficult / unclear
Proposed change:
Owner:
Retest result:

Example: save a reminder. At a large accessibility text size the time label overlaps the Save button, so the reminder can’t be saved. Let the row expand, move the action below it, then repeat the full flow at that size.

What to fix first

Start with barriers that stop completion, then mistakes that are hard to undo, unclear feedback, and repeated friction. Retest the whole task after each fix, then repeat the review on your other common tasks.

This is a focused first pass, not a full assessment. Before declaring support for an App Store accessibility feature, work through its full criteria using Apple’s guidance below — and test with people who use these features every day.

Sources

• Apple — VoiceOver evaluation criteria
• Apple — Larger Text evaluation criteria
• Apple — Reduced Motion evaluation criteria
• Apple — Accessibility Nutrition LabelsThe App Store feature those three criteria belong to.
• WWDC25 — Evaluate your app for Accessibility Nutrition LabelsThe same evaluation, on video.
• Apple — Human Interface Guidelines: Accessibility
• Apple — Accessibility InspectorAudit labels, traits, and contrast from Xcode.
• Apple — Accessibility for developers

Find the moment someone gets stuck. Give them a usable way forward.