App Store Accessibility Nutrition Labels checklist

This checklist is about those claims in App Store Connect: what they mean, how to test them on a device, and what to do when only some tasks qualify. The work of actually building the support lives in Accessible iOS apps in SwiftUI. The set of features you can declare can change, as can whether the labels are voluntary or required to submit. Confirm the current list and rules in Apple’s overview of Accessibility Nutrition Labels and in the App Store Connect form itself, rather than treating the list below as complete for ever.

Labels are claims about common tasks, not badges

Apple’s own wording is worth taking literally. A label tells a shopper whether they can use a named accessibility feature to complete common tasks in the app. Common tasks are the jobs the app exists for: creating the record, finishing the workout, sending the message, following the recipe. They are not a hidden settings screen, and they are not a demo view you built for screenshots.

That has a few consequences:

• You evaluate the real product, not a sample project, and not “the screens we had time to polish.”
• You evaluate each feature separately. VoiceOver support does not automatically earn you Larger Text or Reduced Motion.
• You can say that you have not indicated support yet, or that you support none of the listed features. An empty or “none” statement is more useful than a guess. As of Apple’s current documentation, providing the labels started as voluntary, with a stated direction that they would become required for new apps and updates after a notice period. Check the current status when you submit; don’t rely on a remembered launch window.
• You can also link to an accessibility URL on your site, on most platforms, for the features and exceptions that do not fit a label. That page should be as honest as the labels, and it is a good place to mention languages, in-app settings, and the corners you do not yet support.

A claim you have not tested is a good way to disappoint the exact people the labels were built for, and it is a claim you may be asked to stand behind. Treat it with the same care as a privacy label or a screenshot: it is part of the launch, not a form you tick on the way to Submit.

The features you can declare, and what they mean

Apple’s overview currently lists these features. I am summarising the official idea of each one; the live form, and the evaluation criteria Apple publishes at the time, are the authority if they differ.

• VoiceOver — a person can navigate and explore the app with VoiceOver (gestures, keyboard, braille and speech output) and complete the common tasks that way.
• Voice Control — a person can navigate and interact using Voice Control (tap, swipe, click, type and similar by voice). Apple currently notes that this label is not applicable on some devices, including Apple TV and Apple Watch; the form will only ask where it applies.
• Larger Text — text in the app can increase to a substantial size. Apple currently describes this as 200% or more, and notes that the label is not supported on Mac. Confirm the current criterion when you test.
• Dark Interface — the app offers a dark colour scheme for screens, menus and controls.
• Differentiate Without Color Alone — key information is not conveyed by colour only; there is also shape, text or another cue.
• Sufficient Contrast — the contrast between text or iconography and the background can meet a sufficient level, or the app adjusts to increase it.
• Reduced Motion — the app modifies or reduces motion that can cause discomfort, typically by honouring the system Reduce Motion setting.
• Captions — spoken dialogue and relevant sounds in audio or video can be followed with time-synchronised text.
• Audio Descriptions — video can be followed with time-synchronised spoken description of what is on screen.

Some labels only appear for some device types. You indicate support per device family you ship (iPhone, iPad, Mac, and so on). The product page shows the labels for the device the shopper is using. If you skip a device, Apple currently says the section can still appear and can show that you have not indicated support yet.

If a new feature appears in App Store Connect that is not in the list above, it is the form that is current, not this paragraph.

VoiceOver, larger text, contrast and captions

These four are where most small apps should start, because they catch a lot of daily use, and because work on VoiceOver often improves other entry points too. Apple even recommends evaluating in an order of that kind; follow the current evaluation guide when you have it open.

VoiceOver. Turn it on, put the screen curtain on if you can bear it, and do each common task without looking. Every control needs a sensible label, a useful hint only where it helps, a correct trait, and a focus order that matches the visual order unless you have a good reason. Custom controls are where this usually fails. Don’t claim VoiceOver if the person can open the app but cannot finish the job. The habits in the SwiftUI accessibility guide are the implementation side of this claim.

Larger Text. Turn Dynamic Type up to the size Apple’s current criterion asks for (the overview describes 200% or more) and complete the tasks. Text should actually enlarge, remain readable, and not be cropped, overlapped, or truncated in a way that hides meaning. Fixed-height rows, truncated titles, and images of text are the usual failures. A settings screen that scales while the main calendar view does not is not enough.

Sufficient Contrast. This is both a design decision and, if you offer it, an Increase Contrast or similar path. Check text and meaningful icons against their backgrounds, in light and dark if you ship both. The Contrast Checker will measure a colour pair; it will not tell you whether a low-contrast chart in the app is still conveying its only meaning by tint. If you claim the label, the common tasks have to remain readable.

Captions. Only relevant if the app has audio or video (or audio-only content) as part of a common task. A talking tutorial without captions is a no. A utility with no media can usually leave this undeclared, rather than claiming it vacuously. If you claim it, the captions should be accurate, time-synchronised, and available for the media people actually have to use.

Sufficient contrast, reduced motion and the rest

Dark Interface means a real dark colour scheme for the screens, menus and controls the person will live in, not a single dark splash followed by a white form. Honour the system appearance if you can, and test the common tasks in dark mode, not only a marketing screenshot.

Differentiate Without Color Alone is about meaning, not decoration. A status that is only red or green, a chart series that is only a hue, or an error that is only a coloured border, will fail a person who cannot use that colour. Add words, icons, or patterns. The Colour Blindness Simulator is a useful first look; it is not a substitute for also checking the design without relying on colour at all.

Reduced Motion means you honour the system’s Reduce Motion setting, or you otherwise provide a reduced-motion path, for the motion that can cause discomfort: large zooms, parallax, looping decorative animation, sudden full-screen transitions. If Reduce Motion is on and the app still plays the same looping hero animation, don’t claim the label. The Motion & Animation Safety Auditor is built for web motion, but the question is the same: what still moves when the person has asked for less?

Voice Control needs visible, unique names that match what a person would say, and custom controls that can be tapped by a spoken command. It often comes along once VoiceOver labels are in good shape, but it is not automatic. Test by doing the common tasks with Voice Control on, and with the item names shown.

Audio Descriptions apply when video is part of a common task and the picture carries meaning that is not in the soundtrack. A talking-head video may need little; a silent demonstration may need a lot. If you don’t have video, skip the claim.

If the app has forms, the same discipline as the accessible web forms checklist applies: a visible label, a reachable control, an error in text. The Form Accessibility & Autocomplete Auditor is a web tool, but it is a reminder of the failure modes that also appear in SwiftUI forms.

How to test each claim on a real device

Do this on a physical device, with a release-like build, not only in a simulator preview. Simulator support for some features is useful for development; it is not the thing a shopper will run.

A workable method:

1. Write down the common tasks, in the order a new user would attempt them. If you cannot list them, you are not ready to label the app.
2. For each feature you might claim, turn that feature on (and, for VoiceOver and Voice Control, use it as the primary way of interacting). Complete every common task, or stop when you cannot.
3. Note the first failure with a screen, a step, and a cause (missing label, cropped text, colour-only error, motion that cannot be reduced, missing captions).
4. Fix or narrow the claim. Don’t record a pass with a list of exceptions in your head and then tick “supports” on the form.
5. Repeat when the UI changes, especially around new custom controls, new video, or a new dark palette.

Automated tests can catch regressions in labels and in some Dynamic Type layouts; they cannot complete this checklist on their own. Use them as the safety net described in testing with Swift Testing, then still do the device pass.

Invite, if you can, someone who uses the feature daily. A single session with a VoiceOver user will teach you more than a week of guessing at rotor behaviour. If you cannot, be more conservative about the claim, not less.

What to do if only some tasks qualify

This is the honest, awkward case, and it is common.

If the main job of the app cannot be completed with VoiceOver, you should not claim VoiceOver, even if the settings screen is a model of courtesy. If four of five common tasks work and the fifth is a rarely used export that fails, Apple’s current evaluation materials are the place to look for how they want that judged — I will not invent a percentage that lets you tick yes. In the meantime, the conservative path is: don’t claim the feature, fix the fifth task, or describe the limitation clearly on your accessibility URL if you publish one.

Partial support can still be useful to talk about in prose. A page on your site can say: “You can complete the daily log with VoiceOver. Exporting a PDF is not yet ready; we are working on it.” That sentence, on a URL you link from App Store Connect, is more help than a label that implies the PDF works.

Don’t invent a fourth state on the form (“sort of”). Use the states the form actually offers, per feature and per device, and keep your own notes of what you tested.

Updating labels when the app changes

Labels go stale in the same ways screenshots do. A new custom chart, a new video tutorial, a new colour palette, or a removed dark mode can make last year’s claims false. Put a labels pass on the same release checklist as the privacy labels and the screenshots.

When you change a claim:

• update App Store Connect for each device family you ship
• update the accessibility URL, if you have one, in the same release
• keep a short record of the date, the version, and the tasks you retested

If you remove support (for example you drop dark mode), remove the claim. A leftover yes is worse than a narrower page. If Apple later makes the labels mandatory for updates, you will want this habit already in place rather than inventing it under a deadline.

A section-by-section checklist

Use this as a review list before you publish or update the labels. Confirm each line against the current App Store Connect form and Apple’s evaluation criteria.

• You have written down the app’s common tasks, and they match what a shopper would expect from the product page.
• You have opened Apple’s current overview and the live form, and you are declaring only features that still exist there.
• Each claimed feature has been tested on a real device, for each device family you indicate, by completing those tasks with the feature enabled.
• VoiceOver: every control on the task path has a sensible name and a usable focus order.
• Voice Control, if claimed: common tasks can be completed by voice, on devices where the label applies.
• Larger Text, if claimed: the current size criterion is met on the task path, without hidden or overlapping meaning.
• Dark Interface, if claimed: the actual task path has a dark scheme, not only a splash screen.
• Differentiate Without Color Alone, if claimed: no critical meaning on the task path is colour-only.
• Sufficient Contrast, if claimed: text and meaningful icons on the task path remain readable, including in the appearances you ship.
• Reduced Motion, if claimed: the system setting (or an equivalent in-app control) actually reduces the motion that would otherwise play.
• Captions and Audio Descriptions, if claimed, cover the media a person has to use to finish a common task.
• You have not claimed a feature you have only tested on a settings screen, a demo, or a simulator preview.
• Limitations that you are willing to admit are on the accessibility URL, and that URL works.
• The labels will be reviewed again when the next UI or media change ships.

If a line fails, the label is no. The work then goes back to the SwiftUI accessibility side, which is where it should have started.

Key takeaways

• Accessibility Nutrition Labels are claims that common tasks can be completed with a named feature, not badges for having a setting.
• Confirm the current feature list, device scope, and whether the labels are required, in Apple’s overview and in App Store Connect.
• Test each claim on a real device, with the feature on, against a written list of tasks; don’t generalise from a settings screen.
• If only some tasks qualify, stay conservative on the form and, if you need to, explain the limits on an accessibility URL.
• Retest and update the labels when the app changes, in the same release as the thing that changed.

If you want a second pair of eyes on an accessibility pass, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.