A blank accessibility label still says something

Since iOS 26, every App Store product page has an Accessibility section, whether or not the developer has touched it. If you never filled yours in, it doesn't disappear. It tells every visitor that you haven't indicated support yet. Here is what Apple's Accessibility Nutrition Labels actually ask, what each of the nine claims commits you to, and how to audit an app against them in an afternoon.

What shows up, and where

The labels were announced at WWDC25 and appear on product pages for people browsing on iOS 26, iPadOS 26, macOS 26, tvOS 26, visionOS 26 and watchOS 26 or later. You answer in App Store Connect, once per device type your app supports, and the store shows the answers for the device the visitor is holding. An iPhone shopper sees your iPhone answers; a Mac shopper sees your Mac answers. Labels show in every country or region where the app is sold.

Apple's wording on the empty case is blunt: if you don't provide information for a device, "the section will still appear on your product page and show that you haven't indicated support yet." There is no way to opt out of having the section. The only choice is what it says.

There is a search angle too: Apple says people can search for features ("running apps with Larger Text") and that apps which indicate support "will be considered more relevant in search results."

Voluntary today, required later

Filling the labels in is voluntary for now. Apple's documentation says that over time you'll be required to share accessibility support details to submit new apps and app updates, with "ample time and evaluation resources" before that happens. As of this writing Apple hasn't published a date. Waiting for the deadline means letting the blank label speak for you until then.

The labels aren't tied to a build: Apple confirmed in a WWDC25 group lab that you can edit them at any time without a new app submission.

The nine features, and the trap in each

Apple's test for every label is the same: "users must be able to complete all of the common tasks of your app using that feature." Here is what each claim means, and where indie apps most often fall short.

VoiceOver. Every common task can be done by gesture, keyboard or braille with speech output. The usual failure is a custom control, like an icon-only button, a chart or a canvas, that announces itself as "button" or nothing at all.

Voice Control. Users can tap, swipe and type by voice. It depends on the same labels as VoiceOver, so unlabeled buttons break it too: nobody can say "tap" on something with no name. Apple notes it isn't offered on Apple TV or Apple Watch.

Larger Text. Text can grow to at least 200% or the system maximum. Dynamic Type passes 200% at the AX3 size and takes body text past 300% at AX5. Apple specifically rules out leaning on Zoom or Hover Text, and asks that primary body text grow "without affecting readability through overlapping layouts or severe truncation." This label isn't offered on Mac.

Dark Interface. The interface can be kept dark, through system Dark Mode, your own dark scheme, or as a last resort Smart Invert. An app that's dark by default qualifies. The trap is the flash: Apple's criteria say even "temporary flashes of bright content" defeat the point. A white launch screen, web view or sheet in an otherwise dark app counts against you.

Differentiate Without Color Alone. Shapes, icons or text carry meaning alongside color. Red-for-error borders, green-dot status indicators and colored chart lines without labels are the usual offenders.

Sufficient Contrast. The default interface meets contrast guidelines: Apple cites 4.5:1 for most text and 3:1 for non-text elements like a checkbox's checked state. It asks you to check light and dark appearances, and singles out grey-on-black dark themes as a common miss.

Reduced Motion. Animations that can cause motion sickness are toned down or replaced when the system setting is on. Parallax, zooming transitions and auto-playing motion are what to look for.

Captions and Audio Descriptions. These only apply if your app plays video or audio as part of a common task. Captions need time-synced text for dialogue and relevant sounds; audio descriptions need narration of what's on screen. If your app has no media, you won't be asked about them.

Define "common tasks" before you test anything

The label lives or dies on what counts as a common task, and Apple defines it more widely than most teams expect. It's the primary thing people download the app for, plus four tasks every app has: the first-launch experience, login or account creation, purchase if you sell anything, and settings. Apple adds that you should consider empty and loading screens, and actions taken outside the app, such as completing a task from a notification or a widget.

Apple's test for the borderline cases: would you ship an urgent fix if users were blocked from completing this task? If yes, it's common.

Write the list down. For a to-do app it might be seven rows: onboarding, sign in, see the list, add a task, edit a task, upgrade to the paid plan, change a setting. That list is your test plan.

The afternoon audit

Apple recommends a matrix, with common tasks as rows and the nine features as columns, one matrix per device. For a small app that's under a hundred cells, and most are fast to fill.

Start with the cheap columns. Walk every row in Dark Mode, watching for anything that flashes white. Walk them again at the largest accessibility text size, looking for overlap and unreadable truncation. Then do a pass with Increase Contrast and Reduce Motion both on.

VoiceOver is the slow one. Turn it on, cover the screen, and try to complete each row by swiping. Note every element that stops you and what it announced. Test Voice Control after fixing those, since it shares the same labels.

If you build with a cross-platform toolkit, check what it does by default before you assume. Flutter, for example, scales text with the system setting out of the box, but plenty of apps pin the text scale to 1.0 in a MediaQuery override to protect a tight layout, and one line like that silently costs the whole Larger Text column. Custom-painted widgets need explicit Semantics for VoiceOver to read them at all.

Then fill in only the cells that passed every row. Where a feature mostly works, leave it unclaimed and say so on an accessibility page: App Store Connect lets you add an accessibility URL that appears on the product page on every device except Apple TV. It's the place for "VoiceOver works everywhere except the chart editor; fix coming in 2.4."

Why under-claiming beats over-claiming

The labels are self-declared, but App Review can ask you to update one that looks misleading, and the accurate-metadata guideline (2.3) applies. The bigger cost is human: someone who relies on VoiceOver installs because the label said it works, hits an unlabeled paywall button, and can't subscribe. That's a lost customer and probably a review that names the problem.

Three honest ticks and a clear note about the rest read as a developer who tested. That beats both a blank section and nine ticks the app can't live up to.

Apple's criteria say to re-evaluate support with every update, so put the matrix on your release checklist and re-walk the rows a change could have touched.

Where to start

If you only have an hour this week, do the Dark Interface and Sufficient Contrast passes. They need no tooling beyond the settings app, and contrast is the one most worth getting right everywhere, including your store screenshots. We've written about the parts of colour that catch people out, from why HSL lightness misleads to setting white type on dark.