Overview of Accessibility Nutrition Labels

The Accessibility Nutrition Labels will appear on your app’s product page in all countries or regions where your app is available. The App Store displays the labels specific to the device type (iPhone, Mac, etc.) used to view your product page.

You have the option to provide information for each device your app supports in App Store Connect. If you don’t provide this information for a device, the section will still appear on your product page and show that you haven’t indicated support yet. This section will also indicate if your app supports none of these accessibility features.

You also have the option to provide an accessibility URL that links to your website so that users can learn more about the app’s accessibility features. This link will show on your app's product page across all devices, except Apple TV. This accessibility URL should correspond uniquely to your app and can include information such as other accessibility features, how to turn on and manage any in-app accessibility settings, what languages are supported in captions, or areas of your app that don’t support an accessibility feature.

Starting this Fall, users can include Accessibility Nutrition Label features as part of their search query to make their results more relevant. For example, in searches like “VoiceOver note taking apps” or “running apps with Larger Text,” apps that have indicated support for those features in their labels will be considered more relevant in search results.

To encourage developers to respond consistently across all apps, the App Store has set evaluation criteria a developer should meet before indicating support in the Accessibility Nutrition Labels.

Before providing your responses in App Store Connect, you’ll need to audit your app to understand the level of support it provides and how it aligns to the App Store’s standards for each accessibility feature. Since your app’s support of an accessibility feature can differ per device and you can provide responses for each device in App Store Connect, you should assess your app on each of the devices your app supports.

To indicate support for an accessibility feature in the Accessibility Nutrition Labels, users must be able to complete all of the common tasks of your app using that feature.

In addition to following the evaluation criteria, make sure to follow App Review Guideline 2.3 for accurate metadata. If an app potentially has intentionally misleading or harmful accessibility labels, App Review has the ability to contact the developer and ask them to update their Accessibility Nutrition Labels.

You’re responsible for keeping your responses accurate and up-to-date. If your practices change, please update your responses.

Identifying the common tasks in your app

To indicate support of an accessibility feature in the Accessibility Nutrition Labels, users should be able to complete all of the common tasks of your app using that feature. Before you begin evaluating features, compile a list of the common tasks that a person can perform in your app.

Common tasks checklist

Common tasks consist of the primary functionality that you expect users to perform in your app, plus functionality that's fundamental to using an app in general: first launch experience, login, purchase, and settings.

• Primary functionality specific to your app

  • To indicate support for an accessibility feature, a user should be able to perceive, operate, and understand all of the primary functionality specific to your app while using the feature.

  • To come up with your list of primary functionality, start by defining the key goals, functionality, and features users download and use your app for. It may be helpful to consider what you market in your app’s description, screenshots, and app previews.

    As an example, a to-do list app’s common tasks will include these tasks below.

    • View task list

      • The user may need to mark a task as complete, undo marking a task as complete, change the due date, or create a new task.

    • Task detail view

      • For a new or existing task, the user may need to enter information about the task, save the task to a list, or exit the screen without making modifications.

• First launch experience

  • To indicate support for an accessibility feature, a user should be able to complete the app’s first launch experience while using the accessibility feature. For example, your first launch experience may have a video with sound that you may want to express in captions, or an onboarding flow that a user should be able to complete or skip.

• Login

  • To indicate support for an accessibility feature, a user should be able to complete the login experience while using the accessibility feature. For example, the user should be able to choose a login service, enter a username and password, interact with a login button, request a password reset, or enter information to create a new account.

• Purchase

  • If your app offers purchases, to indicate support for an accessibility feature, a user should be able to complete the purchase experience while using the accessibility feature. For example, the user should be able to select a payment provider, enter a credit card number, review the terms of an offer, or review before completing the purchase.

• Settings

  • To indicate support for an accessibility feature, a user should be able to adjust app settings while using the accessibility feature. For example, the user should be able to turn on accessibility or privacy features, manage purchases, or exit the settings screen without modifying settings.

Ensuring a comprehensive list

As you make your list, consider the following to ensure you have a comprehensive list of common tasks:

• Make sure your list includes common tasks that users both with and without disabilities can perform.

• Consider differences by device, such as if a certain experience is only available on Apple Watch but not Mac.

• Include tasks that you make mandatory to use your app, such as account sign-up or purchasing a subscription.

• Especially for new users, consider default and loading screens, such as the screen to view the task list when the user hasn’t added tasks yet.

• Consider actions a user can take outside your app that are common tasks, such as marking a task complete in a notification or widget from your to-do list app.

• When evaluating, you're not required to consider tasks that are uncommon in your app. If you're unsure if a task is common, ask yourself whether you'd ship an urgent fix if users were blocked from completing this task. For example, if your app provides links to your app’s marketing channels on social media and web but that isn’t a key goal of using the app, you're not required to include it in your evaluation. If you want to provide more information about the accessibility of uncommon tasks, use the accessibility URL to do so.

Recommended: Create an accessibility testing matrix

After you identify your app’s common tasks, to guide your evaluation, it may be helpful to create an accessibility testing matrix for each device you plan to provide Accessibility Nutrition Labels for in App Store Connect. Following this matrix isn’t required, but it can help make sure you’re validating that all common tasks can be completed for an accessibility feature on that device. This is especially helpful since some of your app’s common tasks may not be available on some devices, and some accessibility features aren’t available on certain devices.

To start, create a matrix for each device you’ll be evaluating for Accessibility Nutrition Labels.

For each matrix, take the common tasks that are available on that device, and add them as rows. For example, if a common task is only available on Mac but not Apple Watch, include the common task in your matrix for Mac but not your matrix for Apple Watch.

Next, consider the accessibility features you want to evaluate. Since some accessibility features aren’t available on certain devices, you won’t be able to provide Accessibility Nutrition Labels for them. Take the accessibility features that are available on that device, and add them as columns.

Now you're ready to evaluate your app.

Implementation

• Whenever possible, use the Apple-provided native API to reduce implementation complexity and so customers who have turned on the system setting will automatically get this experience without an additional setting. We highly recommend Apple-provided native APIs for complex app behaviors, such as drag and drop or multi-touch gestures.

• Provide native support for core assistive technologies, including VoiceOver and Voice Control. These assistive technologies allow connection to hardware interfaces, such as braille displays, and interaction with operating system features, like app switching, that your app otherwise wouldn’t be able to support. Don’t attempt to make a custom implementation of the functionality provided by core assistive technologies like VoiceOver or Voice Control.

• With the exception of core assistive technologies like VoiceOver and Voice Control, you may use a custom implementation to indicate support for your labels, such as a custom dark color scheme, instead of using the system’s standard dark appearance.

• Even if you use a custom implementation for an accessibility feature, consider leveraging the user’s system setting to ensure your app responds to their needs. For example, if you render custom captions in a game, check the user’s system setting that indicates a need or preference for displaying captions when available. If you offer your own in-app setting, it should offer more granular user interface customization than the system setting provides.

• Pay extra attention to custom elements, since they are less likely than standard elements to have accommodations for accessible experiences. Additionally, some features like VoiceOver and Voice Control may require additional work to support custom elements.

Third-party content

• You don’t have to consider third-party or user-generated content when evaluating accessibility labels if those views aren’t part of your common tasks.

• When third-party or user-generated content views are part of your common tasks, you don’t need to ensure all third-party content is accessible, but your app should provide the third-party content creators a reasonable, discoverable way to make their content accessible. For example:

  • In most video streaming apps, developers support a way to display closed captions, even though not all third-party movie and television studios provide captions with their video content.

  • In apps that allow users to upload images, developers should provide a way for the users to label the image, so the image content is perceivable to VoiceOver users.

  • In apps that use a web view to load third-party websites, WebKit provides default support for most accessibility labels for web content by using web standards like HTML, CSS, and ARIA.

  • In addition, web browsers like Safari provide additional accessibility features, like site-specific font size settings, which allow users to enlarge the font sizes of web sites to 200% the default size, or sometimes larger.

Best practices

• The common guiding principles of accessibility are that content, controls, and interfaces should be perceivable, operable, understandable, and robust. Keep these principles in mind as you’re evaluating your app. For example, a blind VoiceOver user should be able to perceive the content of a visual photograph or icon, often by experiencing its text alternative label as speech or braille. Likewise, if most users can operate an item by tapping, clicking, or dragging it, the item should also be operable to assistive technologies like VoiceOver and Voice Control, so that users with disabilities can use all the same functions of an app.

• You may consider exceptions to the recommendations here if users with disabilities would find them reasonable. For example, you might hide a button from VoiceOver in one view if it duplicates functionality that’s already available and discoverable elsewhere.

Your app has bugs that affect its accessibility.

If bugs are significant enough to change your answer according to the Accessibility Nutrition Labels evaluation criteria, then don’t indicate support for the accessibility feature. To avoid misleading users, you shouldn’t enter answers that aren’t aligned with the evaluation criteria.

An accessibility feature doesn't apply to your app.

Review the evaluation criteria for the accessibility feature to determine if it's applicable and whether to indicate support.

You have additional accessibility information to share with users.

Add an accessibility URL to your product page to provide users additional accessibility information, such as other accessibility features, how to turn on and manage any in-app accessibility settings, what languages are supported in captions, or areas of your app that don’t support an accessibility feature feature.

Your app includes app extensions.

Your app may include app extensions such as stickers, custom keyboards, Safari extensions, or photo editing extensions. To determine whether to include app extensions in your evaluation, determine whether they are part of your app’s common tasks. If using the app extension isn't part of your app’s primary functionality, then it's unlikely to be one of your app’s common tasks.

Your app has advertising.

Include advertising in your evaluation if it’s present in the UI when users are completing your app’s common tasks. If the advertising experience prevents users from completing a common task using an accessibility feature (for example, the advertisement contains problematic motion that can't be addressed by a system or in-app setting to reduce motion), then don’t indicate support for the feature.

Your app is a compatible iPhone and iPad app on Apple Vision Pro.

If your iPhone and iPad app is compatible with and can run on Apple Vision Pro, no responses are needed for Apple Vision Pro. The labels for iPhone or iPad will be shown to users on the Apple Vision Pro App Store.

Your app is a compatible iPhone and iPad app on Macs with Apple silicon.

If your iPhone and iPad app is compatible with and can run on Macs with Apple silicon, no responses are needed for Mac. The labels for iPhone or iPad will be shown to users on the Mac App Store.