App Store Accessibility Nutrition Labels: A Practical Audit Guide

The label is a promise about a complete journey

An app can look accessible in a design review and still fail at the one moment that matters. VoiceOver may read the catalogue perfectly but lose focus in checkout. Larger Text may work on the home screen and hide the confirmation button in account recovery. Captions may exist for promotional videos but not for the lesson a paying learner actually needs.

Apple's Accessibility Nutrition Labels are designed around this difference. They do not ask whether a team added an accessibility API somewhere. They tell a person whether a supported feature can carry them through the app's common tasks. Apple includes first launch, login, purchase and settings alongside the product's primary purpose. If any essential step blocks the user, the honest answer may still be “not supported” until the journey is fixed.

That makes the label useful well beyond App Store metadata. It turns an abstract accessibility goal into a release decision with named tasks, devices, evidence and owners. The best starting point is the broader mobile app accessibility checklist; the label audit then applies those principles to the exact version being published.

What appears on the App Store product page

On supported Apple operating systems, the product page can show accessibility information for the device a person is viewing. A developer supplies the answers separately for relevant devices in App Store Connect. Apple currently lets teams indicate nine features:

Not every feature applies to every device or product. Larger Text, for example, is not a Mac label, while Voice Control is not offered as a label for Apple TV or Apple Watch. Media labels may be irrelevant to an app with no meaningful audio or video. “Not applicable” should come from the published criteria, not from a desire to finish the form quickly.

Apple says the information is voluntary at first but is expected to become required over time for new apps and updates. The section is already visible on product pages running iOS 26 and the corresponding generation of Apple's other operating systems. An unfilled device can therefore show that support has not yet been indicated. Waiting is not neutral from the user's point of view.

Build the common-task list before testing features

Do not start inside App Store Connect. Start with a short map of what would make the app feel broken if it stopped working today.

For an online school, that may be registration, choosing a course, starting a lesson, playing required media, completing an exercise, paying for access and changing account settings. For a booking app, it could be finding a service, selecting a time, entering details, paying, rescheduling and contacting the provider. Add universal tasks such as onboarding, authentication, consent, password recovery, purchase restoration and support.

A useful test is Apple's own practical question: would the team ship an urgent fix if users could not complete this task? If yes, it belongs in the common-task set. A link to a social profile probably does not. A hidden “delete account” action may be used less often, but it is still important enough to include because a user must be able to control the account.

Keep the list to meaningful end-to-end journeys rather than every screen. “Buy a subscription” is a task. “Open screen 14” is not. This gives QA room to follow redirects, sheets, permission prompts and error recovery instead of passing isolated layouts.

*A label is credible only when every relevant route reaches its destination, not when one polished screen passes inspection.*

Turn the list into a device-by-device matrix

Create one matrix for each device family you intend to describe. Put common tasks in rows and the relevant accessibility features in columns. A cell should contain more than a green tick: record the build, device, tester, outcome and a link to evidence or an issue.

In this example, the app cannot yet claim VoiceOver or Larger Text support even though most cells pass. That may feel strict, but it prevents a user from downloading an app on the strength of a label and becoming trapped at account recovery or payment.

Test iPhone and iPad separately when layouts and capabilities differ. Do the same for watchOS, tvOS, visionOS or a native Mac app. An iPhone app that merely runs on an Apple silicon Mac follows Apple's special compatibility guidance; it does not automatically need a separate Mac response. The current App Store Connect documentation should be the final reference when the device setup is unusual.

Manual use matters more than a scanner result

Accessibility Inspector and automated audits are valuable. They find missing labels, contrast problems and some target or hierarchy issues quickly. They do not know that a screen reader announced the correct elements in a confusing order, that a custom gesture has no alternative, or that the user can enter a card number but cannot hear why it was rejected.

Run VoiceOver with the screen curtain when possible so the tester cannot rely on the visual layout. Move through controls in sequence, use the rotor, edit text, trigger validation and return from modal screens. For Voice Control, complete the task without touching the screen; ambiguous control names usually become obvious. For Larger Text, do not stop when letters become bigger. Check wrapping, scrolling, keyboard states, landscape layouts and the largest content size the criteria require.

Then include people who regularly use these features. A sighted engineer who learned VoiceOver yesterday can catch technical defects, but may not notice inefficient navigation or announcements that are technically complete and exhausting in practice. Apple's WWDC session makes this point directly: involving the people affected by the decisions is one of the strongest ways to understand whether the experience works.

The goal is not to replace the mobile app QA checklist. It is to add a dedicated acceptance pass in which accessibility settings remain on for the whole journey.

The nine claims need different evidence

VoiceOver and Voice Control share useful accessibility metadata, but passing one does not guarantee the other. VoiceOver needs a sensible focus order, accurate names, roles, values and announcements. Voice Control also needs controls that can be identified and activated with language a person can reasonably speak. A row of identical “More” buttons may be technically labelled and still be difficult to command.

Larger Text is a layout test. Apple defines the label around text increasing to at least 200%. Fixed-height cards, one-line buttons, custom charts and bottom sheets are common weak points. When a control cannot expand, give content room to wrap or provide a different presentation instead of shrinking the font back down.

Color and motion claims are stateful. Check light and dark appearance, increased contrast, errors, selected and disabled controls, charts and maps. Turn on Reduce Motion before launching the app and watch transitions, loading states, celebrations and looping media. Removing one parallax effect is not enough if a core flow still uses large automatic zooms.

Captions and Audio Descriptions are content operations as much as engineering features. A player may support caption tracks while the catalogue contains videos without them. Record which languages are available, how new media is checked and what happens with live or partner-supplied content. If support is partial, explain the boundary on the accessibility page rather than overclaiming in the label.

Publish in App Store Connect only after the audit

In App Store Connect, open the app, choose App Accessibility and start the device-specific questionnaire. Select the verified features, save the draft and publish the chosen device responses. Apple states that published information appears immediately but can take up to 24 hours to become visible everywhere. The responses can be updated later, but published accessibility information cannot simply be made as if it never existed.

Access is role-controlled. Account Holder, Admin, Finance, App Manager and Marketing roles are among those Apple lists for managing these details. That does not mean marketing should guess the answers. A practical ownership chain is: product defines common tasks, QA keeps the matrix, design and engineering fix gaps, a release owner approves the evidence, and the authorized App Store Connect user publishes exactly that result.

Treat the answers as release metadata. Add a check when navigation, authentication, purchase, media, design system components or supported devices change. A server-side experiment can break a journey without a new binary, so major remote configuration changes also deserve review.

Use the accessibility URL to be specific, not defensive

App Store Connect also accepts an accessibility URL unique to the app. It can explain features beyond the nine labels, show how to enable an in-app setting, list caption languages and name areas that are still limited. The page should help a prospective user decide whether the app fits their needs and help an existing user find support.

Keep it current and easy to navigate. Include the app and version scope, supported devices, known limitations, contact route and the date of the latest review. Do not bury an incomplete core journey under general language such as “we care deeply about inclusion.” A clear limitation with a support contact is more useful than a polished promise the build cannot keep.

Because Apple says people can search for combinations such as an app type plus VoiceOver or Larger Text, accurate labels may also improve discovery for highly qualified searches. That is a welcome ASO benefit, but it should follow product truth. The App Store localization checklist can then make the surrounding metadata and screenshots understandable in each market.

Where Appfyl fits in the work

When Appfyl prepares an iOS release, the useful unit of work is not “add accessibility labels.” It is a verified path through the product: account creation, the main customer action, purchase where relevant, settings, recovery and support. We can help turn those journeys into acceptance criteria, identify where design-system or custom-control changes are required, implement the fixes and leave a matrix the team can repeat after future releases.

That approach also avoids an awkward handoff in which a store manager owns the form but nobody owns the evidence. If you are planning a new app or repairing an existing one, talk to Appfyl about the product and release scope. The first useful question is simple: which essential task should every customer be able to finish, regardless of how they interact with the device?

Want to see how Appfyl turns scope into shipped products? View Appfyl cases.

Questions people ask