Accessibility Nutrition Labels App Review checklist
Accessibility labels are product-page promises. They need evidence that real users can complete common tasks with the features you claim, not only that a setting exists in the app.
Before selecting Accessibility Nutrition Label answers, define the app's common tasks and test them with the assistive technologies or accessibility features you intend to claim. Apple says these labels help users understand whether they can use features like VoiceOver or Larger Text to complete common tasks. AppReviewReady interpretation: label only what the submitted build can prove through task completion.
Define common tasks before labels
Start with the jobs users actually perform: sign up, browse, search, create, edit, purchase, share, cancel, delete, or contact support. An accessibility label should be judged against those tasks, not against an isolated settings screen.
If a user can open the app with VoiceOver but cannot complete the primary workflow, the label is too broad. Write the supported task list before answering App Store Connect so product, QA, and marketing agree on what is being claimed.
Test each claimed feature directly
- VoiceOver: controls, labels, order, hints, modal focus, errors, and dynamic updates.
- Larger Text: layout, truncation, buttons, tab bars, forms, and purchase screens.
- Contrast and color: state indicators should not depend only on color.
- Captions and transcripts: media should remain understandable without audio.
- Reduced Motion: essential actions should not depend on animation timing or parallax.
Treat mismatches as release blockers
A mismatch between label and behavior creates user-trust risk even if review does not stop the build. Accessibility claims are especially sensitive because people may download the app based on whether they can complete a required task.
AppReviewReady interpretation: fix the app or narrow the claim. Do not select a label because a framework supports a feature somewhere in the codebase. The submitted build, in the shipped locale and current design, is the evidence.
Create an accessibility proof packet
- List common tasks and supported accessibility features for each.
- Run the tasks on a clean device with realistic account, data, and permission states.
- Capture defects by user impact, not by implementation component.
- Retest after copy, layout, paywall, onboarding, or navigation changes.
- Keep screenshots or short notes for any feature claimed on the product page.
Use Review Notes only for non-obvious paths
Most accessibility evidence can stay internal. Include a note only when the reviewer needs sample data, a paid state, or a specific route to see the feature. Keep the note factual and do not imply Apple has certified the app's accessibility.
Re-run the packet after any redesign, localization, pricing-page change, onboarding experiment, or navigation update. Accessibility regressions often come from growth and layout changes rather than from the original feature implementation.
Accessibility label evidence: Common tasks tested: [list] Features claimed: [VoiceOver, Larger Text] Known unsupported areas: [none or list] Test account/data: [if needed] Where to verify: [screens] Last retest: [date]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check accessibility claims
Compare product-page accessibility claims with task-level evidence before submission.
Open the tool