VoiceOver evaluation criteria

For iPhone, watch "How to Navigate your iPhone or iPad with VoiceOver,” then visit Turn on and practice VoiceOver on iPhone, Use VoiceOver Gestures on iPhone, and Operate iPhone when VoiceOver is on.

For iPad, watch "How to Navigate your iPhone or iPad with VoiceOver,” then visit Turn on and practice VoiceOver on iPad, Use VoiceOver gestures on iPad, and Operate iPad when VoiceOver is on.

For Mac, visit Learn and practice VoiceOver on Mac, then review other topics in the VoiceOver User Guide for macOS.

For Apple TV, visit Use VoiceOver on Apple TV.

For Apple Vision Pro, visit Turn on and practice VoiceOver on Apple Vision Pro, and Learn VoiceOver gestures on Apple Vision Pro.

For Apple Watch, visit Use VoiceOver on Apple Watch.

Buttons, icons, form controls, and all other elements should contain a concise label providing a text equivalent for VoiceOver users. Interactive text fields and similar form controls should have a label (for example, “phone number”) in addition to the text value (“555-555-1212”) of the selection or contents.

Labels should be concise, so that the interface isn’t tedious for a user to navigate and understand quickly. For example, a button for composing a new message should be labeled “New Message” rather than something more verbose like “Press to compose a new message.”

Ensure the labels make sense out of context. Because VoiceOver users may land on an element in different ways, avoid ambiguous labels that are unclear when the user encounters the item in a non-linear order, such as “Click here” or “Learn more.” If multiple action elements have the same label, like “Delete” in a Shopping Cart, the label text should make it clear what the action will do, especially in the case of destructive actions. For example, which cart item will be deleted?

Ensure that labels don’t include control types like "checkbox" or states like "checked." Otherwise, VoiceOver may speak redundant information to the user, such as “Unsubscribe checkbox, checkbox.” Instead, implement these in your app as traits or through similar APIs appropriate to the device.

Most images should include a relevant description or alternative text. If an image is purely decorative, make sure it’s ignored completely by VoiceOver.

If your app provides a way for users to upload media, such as images, ensure users have a way to include labels or descriptions for the user-generated content, so that VoiceOver users can hear this description when encountering the media.

Charts and other data visualizations should include accessibility information through a more specific chart API, or at minimum, include a reasonably complete text alternative.

If third-party or user-generated content is required in your common tasks, refer to the detailed guidance for third-party content on the Overview of Accessibility Nutrition Labels.

For more ideas, watch “Writing Great Accessibility Labels“ and "Bring accessibility to charts in your app."

When a VoiceOver user lands on an item, VoiceOver should speak the type of element in addition to the label or text content. For example, “Unsubscribe from all emails, checkbox."

Users should be able to understand control state and values. Keep in mind that default states, like the “unchecked” state of a checkbox, are implied so they may not be spoken by VoiceOver. For example, “Unsubscribe from all emails, checkbox.” Additionally, take care to update the API for control state and values. For example, once the user has checked the checkbox, VoiceOver will describe the control, including its new state, as, “Unsubscribe from all emails, checked checkbox."

All visible text in the app should be accessible to assistive technologies, including VoiceOver. Plain text elements, such as paragraphs, don’t need a separate label, though you should ensure that VoiceOver can speak the text content.

Custom keyboards and text entry methods (for example, custom keyboards or PIN code entry widgets) should be operable with VoiceOver, and produce correct speech/braille output for the user, in addition to providing accurate text entry and selection.

Temporary status banners and important in-app alerts should be conveyed to VoiceOver users in a timely but non-disruptive manner, often done so with an AccessibilityNotification.

VoiceOver users should be able to navigate to any visible element, either in order (swipe right, VO+Right, and so on) or by using a rotor and touch navigation on most platforms.

VoiceOver users should be able to navigate away from the element they are on, whether by continuing forward, going backward (Swipe Left, VO+Left, etc), or by using a rotor or touch navigation on most platforms.

If multiple elements or actions are presented as a group, VoiceOver users should be able to either move to each item in the group, or be able to interact with the grouped behaviors (for example, reply, forward, delete) through features like custom actions.

VoiceOver users should be able to progress to each element without skipping items or looping back to the same item repeatedly. Try navigating forward through all contents, then backwards through all contents. Try looping through all rotor items forward and backwards, too.

When content reloads or refreshes in the background, a VoiceOver user’s reading position shouldn’t reset unexpectedly. For example, if a VoiceOver user is near the bottom of a content feed when the app loads more content, the VoiceOver cursor shouldn’t accidentally reset to the top of the list.

When the screen changes or a modal dialog appears, the VoiceOver cursor should move logically into the new content area. VoiceOver users shouldn’t be able to move into invisible, offscreen, or background content.

VoiceOver’s activation gesture (select then double-tap) and keyboard command (VO+space) should trigger the same behavior as a standard tap or click.

Standard keyboard operations (for example, arrow keys) and keyboard modifier shortcuts should continue to work, even when VoiceOver is active, and the VoiceOver cursor should follow changes triggered by standard keyboard navigation like the Tab key, arrow keys, and more.

If your app’s controls provide a context menu, overload a long press, or provide other non-default behaviors, consider providing the same behaviors as a custom action using VoiceOver’s actions rotor or its equivalent “show context menu” keyboard command (VO+Shift+M).

VoiceOver should work with modal views, like dialogs. Apps should ensure that inactive content behind the modal view isn’t accessible to VoiceOver while the content is inactive. Apps should also support VoiceOver users being able to dismiss modal views, like closing the dialog, using the Escape key or an accessibilityPerformEscape action.

Complex app behaviors, such as drag and drop or multi-touch gestures, should be provided in an accessible, discoverable way, such as through a custom rotor or action. Whenever possible, use the Apple-provided native API to reduce implementation complexity.

Custom elements, if used by the app or any included frameworks, should provide equivalent accessibility of native elements provided by the Apple UIKit, AppKit, and SwiftUI frameworks. For example, custom buttons, tab bars, and sliders should be operable with VoiceOver and convey the same information as controls using standard API equivalents.