Food has had nutrition labels for decades. You can turn a packet over and see, before you buy, what is actually inside. Apple has now brought the same idea to software. Open almost any product page on the App Store and you will find a new section, Accessibility Nutrition Labels, telling people which accessibility features an app supports before they download it. For the millions of people who rely on a screen reader, captions or large text, that is a quietly significant change: they no longer have to gamble, install and hope.
Apple introduced the labels at WWDC25 and they began rolling out across the App Store through 2025. This post explains what the labels cover, how Apple expects you to earn each one, and the part that matters most to anyone responsible for compliance: a label is a public claim about your product, and a claim is only as good as your ability to back it up.
What an Accessibility Nutrition Label actually shows
The label is a list of the accessibility features your app supports, displayed in the Information section of your App Store product page. A developer can indicate support for the following, where they apply to the app:
- VoiceOver - Apple's built-in screen reader, used by people who are blind or have low vision to navigate and operate the app without sight.
- Voice Control - full operation of the app by voice alone, for people who cannot or prefer not to use touch.
- Larger Text - content respects the system text-size setting (Dynamic Type) so it can be enlarged without breaking the layout.
- Sufficient Contrast - text and meaningful interface elements meet a minimum colour-contrast threshold.
- Differentiate Without Color Alone - information is never conveyed by colour on its own, so it still reads for colour-blind users.
- Reduced Motion - animations and motion effects are minimised when the user turns on Reduce Motion.
- Dark Interface - a genuine dark appearance, not just an inverted screenshot.
- Captions - dialogue and relevant sounds in video or audio content are shown as synchronised text.
- Audio Descriptions - narrated description of important visual information in video content.
If you have spent any time with the WCAG success criteria, that list will feel familiar. Apple has, in effect, taken the access needs that matter most on a phone and turned them into plain-language checkboxes that an ordinary buyer can understand. That translation work is the real achievement here: it moves accessibility out of a specification and onto the shelf, where people make decisions.
You do not tick the box. You earn it.
The most important thing to understand is that the labels are not a marketing field you fill in optimistically. To indicate that your app supports a feature, Apple requires you to meet a defined set of evaluation criteria for that feature, and to have verified that all of the app's common tasks can be completed using that feature alone.
That phrase, "common tasks", is doing a lot of work. For VoiceOver, it means a blind user must be able to complete every core journey in your app, signing up, finding the thing they came for, paying, getting confirmation, using only the screen reader and no sighted assistance. For Voice Control, someone using only voice commands must reach the same outcomes without ever touching the screen or moving a cursor. A single button with no label, one custom control that traps focus, or a checkout step that only responds to a swipe, and the claim is no longer true.
This is the same principle we keep returning to in our own work: accessibility is about whether a real person can finish the task, not whether a feature technically exists somewhere in the build. We made the broader version of that argument in accessibility isn't a button or an add-on, and the labels enforce it neatly, because a half-supported feature fails the "all common tasks" test and should not be claimed at all.
Voluntary now, expected later
Completing the labels is optional to start with. But Apple has signalled that, over time, developers will be required to provide accessibility support details in order to submit new apps and app updates. So the practical timeline for most teams is: optional today, expected tomorrow, and visible to your users and your competitors the entire time.
That visibility is the quiet pressure. A blank accessibility section, or one that claims far less than a rival app, is now something a procurement officer, a government buyer or an individual with a disability can see at a glance. In sectors where accessibility is already a legal obligation, an honest, well-populated label becomes a baseline expectation rather than a differentiator.
The trap: a label is a claim, and claims carry risk
Here is where we want to be direct. An Accessibility Nutrition Label is self-declared. Apple does not independently certify it. That makes it powerful, because you control it, and risky, for exactly the same reason. If you claim VoiceOver support and a blind user cannot complete checkout, you have not just disappointed someone, you have published an inaccurate accessibility claim on a public storefront.
We have seen what happens when accessibility claims outrun reality. The 2025 US Federal Trade Commission action against an overlay vendor turned on exactly this: telling the market a product was accessible when it was not. We wrote about that in why accessibility overlays won't make your website compliant. The Nutrition Labels are a far more honest mechanism than an overlay, but they sit on the same fault line. Apple is explicit that the labels are based on support for common tasks and may not reflect every interaction, which means the responsibility for accuracy, and the consequences of getting it wrong, sit with you.
What the labels are not
It is worth being equally clear about the limits, so no one over-reads the badge:
- They are not a WCAG conformance assessment. The labels confirm a feature works for common tasks; they do not test your app against the 87 success criteria of WCAG 2.2, or against EN 301 549 or Section 508.
- They are not a legal defence on their own. A populated label is good evidence of intent and effort, but under the Disability Discrimination Act and equivalents abroad, the test is whether a person was actually excluded, not whether a checkbox was ticked.
- They are not user testing. Meeting Apple's criteria in the lab is not the same as watching a screen-reader or switch user move through your app. Automation and self-assessment find the obvious gaps; people find the ones that matter.
None of that diminishes the labels. It just places them correctly: a genuinely useful, user-facing summary that raises the floor for mobile accessibility, sitting alongside, not instead of, the deeper work.
How to earn your labels honestly
If you want labels you can stand behind, the path is the same disciplined one we recommend for any accessibility claim:
- Map your common tasks first. List the core journeys a user must complete, then treat each as a pass/fail test for every feature you intend to claim.
- Build to Apple's evaluation criteria, then verify. Apple publishes per-feature criteria for VoiceOver, Voice Control and the rest in App Store Connect. Develop against them, but confirm with real assistive technology, not just a code review. Our guide to screen readers compared is a useful starting point for the testing pass.
- Put real users in the loop. An independent accessibility audit and assistive-technology user testing turn a hopeful claim into a verified one, and give you a defensible record if it is ever questioned.
- Keep the label current. Apple expects labels to stay accurate. Tie a quick accessibility re-check to your release process so a redesign never silently breaks a claim you are still advertising. That is exactly the habit we describe in from reactive to resilient.
The bigger picture
Accessibility Nutrition Labels are a genuinely good development. They give disabled users information they have never reliably had, they reward teams who do the work properly, and they make a missing effort visible. For an industry that has spent years treating accessibility as an internal compliance chore, putting it on the product page where customers can read it is a meaningful shift.
But the label is the summary on the packet, not the food inside. The work that makes it true, designing for assistive technology, building to standard, and testing with real people, is the same work it always was. Get that right and the label takes care of itself. Skip it and you have simply published a claim you cannot keep.
If you are preparing labels for your app, or you want to be certain the ones you have already published are accurate, we can help you verify them against both Apple's criteria and WCAG.