Apple’s current guidance evaluates Accessibility Nutrition Labels across common tasks and supported device families, not merely across APIs in the codebase. That gives this week’s decision a clear outcome: do not tick a label because a modifier, property, or framework is present. Keep an unverified capability unclaimed until users can complete sign-in, purchase, settings, and the app’s core business tasks with that feature enabled. Apple’s overview explains the task-based assessment model and testing scope.
A project can already include VoiceOver labels while a custom purchase control remains impossible to operate. That failure is enough to block a broad support claim for the affected path.
Who should use this checklist
This guide is for independent developers preparing their first Accessibility Nutrition Labels submission and for small teams unsure about Apple’s evaluation criteria.
It also fits teams supporting iPhone, iPad, or Mac builds separately, especially when a local Mac cannot retain every simulator, test account, and accessibility state needed for repeatable regression testing.
The acceptance rule: complete the task before declaring support
Filling out Accessibility Nutrition Labels is an outcome assessment. It is not a source-code inventory.
Apple’s model starts with the actions a user must complete after downloading the app. Those actions normally include first launch, onboarding or sign-in, the main product workflow, settings, and purchase or subscription flows when the app uses them. The exact list depends on the app, so a developer should define it before opening the declaration form.
A support claim is defensible only when all of these conditions are true:
- The task can be started with the relevant accessibility feature enabled.
- Every required control has an understandable name.
- Focus, selection, state, and value changes are announced correctly.
- The user can complete the task without an undocumented workaround.
- Errors can be understood and corrected.
- The result remains valid on the device family being declared.
- The tested build is the same build, or the same released capability, represented in App Store Connect.
A screen that looks correct in a demo is not evidence that the entire app supports the feature. Likewise, a SwiftUI modifier, UIKit accessibility property, or framework integration proves only that an implementation exists. It does not prove that a user can finish a complete task.
Release reminder: Keep three separate statements in the evidence pack: “the code exposes an accessibility property,” “one screen passed,” and “the user completed a required task.” Only the third statement supports a full task-based declaration.
Build the task matrix before opening App Store Connect
The most reliable starting point is a task matrix. It prevents the common mistake of testing whichever screen is easiest and ignoring the path that generates revenue or support requests.
For each device family, list:
- First launch and permission prompts.
- Account creation, sign-in, sign-out, and password recovery.
- The primary user goal, such as creating content, booking a service, or completing a search.
- Purchase, subscription, restore, and cancellation entry points when applicable.
- Settings that affect the main workflow.
- Empty states, loading states, validation errors, network failures, and recovery.
- Destructive actions, confirmation dialogs, and success messages.
- Media playback or other content required to complete the primary task.
Then add a result for every accessibility capability under review. “Not tested” must not become “supported.” “Not applicable” needs a reason, such as the app having no video or audio that is necessary for a common task.
A useful evidence record contains:
App build: 1.0.0 (released build)
Device family: iPhone
Task: Sign in and open the saved project
Feature: VoiceOver
Result: Pass
Failure path: Invalid password message was not announced
Evidence: Screen recording, screenshot, issue ID
Declaration decision: Do not claim full support until fixed
Apple’s overview of Accessibility Nutrition Labels describes the relationship between common tasks, supported capabilities, and the assessment process. Use that page as the source of the task definition rather than copying a generic checklist from another app.
VoiceOver and Voice Control need separate end-to-end results
VoiceOver and Voice Control are different interaction models. Passing one does not justify declaring the other.
For VoiceOver, verify the complete focus and announcement experience:
- Focus enters the page in a logical order.
- Each actionable element has a meaningful name.
- The role tells the user whether an element is a button, switch, tab, slider, text field, or other control.
- State and value changes are announced.
- Custom controls expose the actions needed to operate them.
- Alerts, sheets, menus, and keyboard input do not trap or lose focus.
- Validation errors and successful completion are announced.
- A user can recover after an interrupted network request or invalid input.
The Apple VoiceOver evaluation criteria should control the pass decision. Do not replace those criteria with a visual inspection of accessibility identifiers.
Voice Control needs a different test pass. Check whether a user can discover and activate controls through spoken commands, whether labels are distinguishable, and whether custom gestures or controls provide an operable alternative. Test the app’s real purchase and settings paths, not only standard navigation bars. Record Voice Control results separately using Apple’s Voice Control evaluation criteria.
This distinction matters particularly in SwiftUI and UIKit interfaces that combine standard controls with custom gestures. A custom card may respond to a tap in a normal touch test but expose no usable command or action name through an assistive interaction.
A repeatable test command for simulator evidence
A remote or local Mac can make simulator state easier to reproduce. The command below launches a simulator with a known device identifier; the identifier must be replaced with one available in the test environment.
xcrun simctl boot "SIMULATOR-UDID"
xcrun simctl bootstatus "SIMULATOR-UDID" -b
xcrun simctl launch "SIMULATOR-UDID" "com.example.app"
Expected output should confirm that the simulator reaches a booted state and that the app process launches:
An error was encountered processing the command (domain=io error code=60)
The error above is not a pass result. It means the environment needs investigation, such as a stale simulator state or an unavailable device identifier. The evidence pack should retain the failed command, the corrected run, and the final task result. A green build or successful launch alone says nothing about VoiceOver task completion.
Visual settings are separate acceptance dimensions
Large text, color contrast, dark appearance, and reduced motion should be judged in the tasks defined earlier. They are not interchangeable.
For larger text, inspect the full workflow at the supported text sizes identified by Apple’s criteria. Look for:
- Truncated labels and clipped buttons.
- Text hidden behind fixed toolbars.
- Dialogs that cannot scroll.
- Important status information conveyed only by position.
- Text fields where the editing controls disappear.
- Purchase totals or confirmation actions pushed outside the usable region.
Use Apple’s Larger Text evaluation criteria for the actual threshold and decision rule. Do not report “Dynamic Type is enabled” as the test result.
For color and dark appearance, repeat the common tasks with the system appearance changed. A color-only error message, selected state, or subscription tier is not sufficient if the distinction disappears. Apple’s Accessibility Human Interface Guidelines provide the design principles, but the evidence should still come from the app’s real task paths.
Reduced Motion requires a separate run. Enable the system setting, repeat navigation and content loading, and check whether the user can still understand transitions and complete the workflow. Use Apple’s Reduced Motion evaluation criteria for the support decision.
The evidence should include screenshots or recordings that show the setting, the tested screen, and the relevant result. A code review can explain why a setting should work; it cannot replace an observed failure or pass result.
Media labels apply only when media is part of the user task
Captions and audio descriptions should not be claimed simply because an app contains written text.
First decide whether video, audio, or another media format is necessary to complete a common task. A help article is not automatically a caption track. A transcript is not automatically an audio description. The test must establish whether users can receive the important content through the intended accessible format.
For captions, review:
- Whether spoken dialogue and meaningful audio information are represented.
- Whether captions remain available during the relevant playback states.
- Whether the language used in the task is covered.
- Whether captions remain readable in the app’s actual player.
- Whether the media can be paused, replayed, and navigated without losing context.
Apple’s Captions evaluation criteria should be attached to the result.
For audio descriptions, test whether visual information needed to understand the content is available through the audio-description experience. Check the main media paths and the languages the app presents. Apple’s Audio Descriptions evaluation criteria should determine whether the label is appropriate.
If the app has no media required for a common task, mark the capability as not applicable according to the current App Store Connect options. If only a secondary demonstration video has captions while the core media path does not, do not use that limited coverage to represent the whole app.
Device families must have independent conclusions
An iPhone result cannot be copied to iPad or Mac without testing. Different device families can change layout, keyboard behavior, pointer interaction, window size, navigation structure, and platform controls.
Use a separate matrix for each supported family:
- Record the operating system and app build.
- Identify the input method used for the task.
- Repeat the same common tasks.
- Note layout changes and modal behavior.
- Check whether custom controls expose the same actions.
- Mark a capability as unsupported or not applicable when the current product does not provide it on that family.
This is also where remote testing environments can help, but only when the environment can reproduce the required state. A remote Mac may provide Xcode, simulator control, Accessibility Inspector, and repeatable build access, but a remote session does not automatically prove support on physical hardware or every platform family.
The Accessibility Inspector guidance in Apple’s accessibility design material should be used as an inspection aid, not as the final acceptance authority. Inspector output can reveal missing labels, traits, and values. The final decision still comes from completing the common task.
Comparing the main evidence strategies
| Option | What it proves | What it misses | Best decision |
|---|---|---|---|
| API or modifier review | The project contains accessibility implementation | Real focus order, errors, custom controls, and task completion | Never use alone for a label |
| Single-screen manual test | One screen works under one setting | Login, purchase, settings, recovery, and other common tasks | Use only as an early defect check |
| Full task matrix on one device family | Users can complete defined tasks in that family | Differences on iPad, Mac, or another input model | Suitable for a family-specific declaration |
| Full task matrix across supported families | Coverage, failures, and scope are traceable | Future changes not yet tested | Preferred release evidence |
| Post-release spot check | The published declaration and product surface can be compared | It cannot replace pre-release validation | Use after publication and after major updates |
The table separates implementation evidence from declaration evidence. This distinction is the central safeguard against overclaiming.
Keep a release evidence pack that survives review
Before submitting an update, create one folder or archive for the tested build. It should contain:
- The common-task list and the reason each task matters.
- The device-family matrix.
- Test environment details, including operating system, app build, simulator or hardware identity, and accessibility settings.
- VoiceOver results.
- Voice Control results.
- Larger Text, appearance, contrast, and Reduced Motion results.
- Captions and audio-description results when media is applicable.
- Failed paths, issue identifiers, fixes, and retest results.
- The final label decision for each capability.
- A comparison showing that the tested build matches the release candidate.
Use redacted evidence. Account emails, app names, Bundle IDs, test users, customer content, screenshots, and recordings should be anonymized before they leave the development team.
If the team uses automation, Apple’s Accessibility declarations API documentation can help connect the declaration workflow to release tooling. Automation should transfer a reviewed decision; it should not infer support from the presence of accessibility APIs.
A remote Mac can be useful when a local machine cannot retain the required simulators and clean test states. NodeMini provides remote Mac access through supported remote methods, so a team can maintain a separate build and regression environment instead of altering the developer’s daily machine. The NodeMini remote Mac options should be evaluated against the team’s need for simulator access, session persistence, network controls, and test data isolation.
For a repeatable workflow, separate these environments:
- Development: fast iteration and local debugging.
- Accessibility regression: clean test accounts, controlled settings, and preserved evidence.
- Release verification: the exact candidate build intended for App Store Connect.
Do not store production credentials in a shared regression machine. Do not treat an unattended simulator as proof of physical-device behavior. The remote environment improves repeatability only when the test protocol defines what it can and cannot validate.
App Store Connect submission and post-publication checks
After fixing failures, return to the task matrix rather than testing only the changed screen. A change to a shared control, navigation container, purchase component, or localization can affect several paths.
Before saving the declaration, verify:
- The selected capabilities match the tested results.
- The device-family scope matches the actual app configuration.
- Unsupported or inapplicable capabilities are not presented as supported.
- The release candidate contains the fixes.
- Product metadata does not describe accessibility coverage beyond the evidence.
- The declaration is attached to the correct app and release context.
After publication, check the product surface again. If labels do not appear immediately, confirm that the declaration was saved, the correct version was released, and App Store Connect has processed the change. Apple’s current management instructions for Accessibility Nutrition Labels should take precedence over assumptions about display timing or submission behavior.
Apple’s current position, as reflected in the official material listed for this guide, is that the initial process is voluntary and is intended to become required for new apps and updates in the future. No universal enforcement date should be invented until Apple publishes one. Check the official help pages before each release because the available options and submission requirements can change.
FAQ: common submission decisions
The following questions are common sources of incorrect declarations. The answers focus on release decisions rather than on API implementation.
Final pre-submission checklist
Copy this list into the release issue and assign an owner to every line:
[ ] Core user tasks are documented
[ ] First launch and sign-in paths were tested
[ ] Purchase and restore paths were tested when applicable
[ ] Settings, errors, and recovery paths were tested
[ ] VoiceOver results are recorded separately
[ ] Voice Control results are recorded separately
[ ] Larger Text was tested in complete tasks
[ ] Dark appearance and non-color distinctions were checked
[ ] Reduced Motion was tested where relevant
[ ] Captions and audio descriptions were assessed only for applicable media
[ ] iPhone, iPad, and Mac conclusions were not copied between families
[ ] Failed paths have fixes and retest records
[ ] Screenshots and recordings are redacted
[ ] The evidence build matches the release candidate
[ ] App Store Connect declarations match the final evidence
[ ] Published labels were checked after release
The alternative to this process is usually a code-driven declaration: a team sees accessibility modifiers, passes one screen, and claims support across the app. That approach misses custom controls, purchase failures, dynamic layout problems, device-specific behavior, and media gaps. It also creates expensive rework when a label must be corrected after release.
For a team that needs a stable test Mac only during release cycles, renting a remote Mac can be more flexible than buying hardware that sits idle between submissions. A local Mac remains the better choice for developers who need permanent physical-device connections, sustained daily workloads, or hardware peripherals. A shared cloud environment is also a poor fit for unredacted production data. But when the problem is retaining simulators, clean accounts, build artifacts, and repeatable accessibility settings for periodic regression, a NodeMini Mac environment can provide a separate place to complete the evidence cycle before updating App Store Connect. The NodeMini Mac rental service is worth considering only after the task matrix and data-isolation requirements are defined.