App Store Connect 帮助
旁白：评估标准
描述
借助 Apple 的旁白屏幕阅读器，用户无需看到屏幕即可导览 App 界面。许多视障人士或低视力人士使用旁白来理解并操作 App。
目标
每个人，无论健全与否，都应该能够使用你的 App。通过鼠标或触控屏手势能够完成的 App 内操作（如轻点、点按、拖移等），也应该支持用户通过旁白来完成。对于屏幕上可供查看的重要内容，你的 App 应为旁白用户提供语音或盲文形式的标签或描述。
【注】针对旁白功能的支持度优化，往往也有助于提升其他辅助功能的使用体验，如语音控制、切换控制、悬停文本。因此，我们建议先评估 App 对旁白的支持度，再针对语音控制功能进行评估。
后文将详细说明如何确定 App 是否充分支持旁白。为确保残障用户也可以使用 App 的所有常用功能，请参照下方所列的评估标准，综合判断是否在 App Store 中将你的 App 标为支持旁白。
从测试开始
为保证评估结果的准确性，请务必在 App 支持的所有平台上都充分测试旁白功能。请仔细阅读以下内容，确保能够熟练使用旁白进行测试。
-
iPhone：请观看视频了解如何借助旁白操作 iPhone 或 iPad，并参阅“在 iPhone 上打开和练习‘旁白’”、“在 iPhone 上使用‘旁白’手势”以及“‘旁白’打开时操作 iPhone”。
-
iPad：请观看视频了解如何借助旁白操作 iPhone 或 iPad，并参阅“在 iPad 上打开和练习‘旁白’”、“在 iPad 上使用‘旁白’手势”以及“‘旁白’打开时操作 iPad”。
-
Mac：请参阅“在 Mac 上学习和练习旁白”；更多信息请查看“适用于 Mac 的旁白使用手册”中的其他相关内容。
-
Apple TV：请参阅“在 Apple TV 上使用旁白”。
-
Apple Vision Pro：请参阅“在 Apple Vision Pro 上打开和练习‘旁白’”，以及“了解 Apple Vision Pro 的‘旁白’手势”。
-
Apple Watch：请参阅“在 Apple Watch 上使用旁白”。
对旁白有基本了解之后，你便可以开始测试。不过，为了保证良好的用户体验，我们建议更深入地阅读用户指南，了解用户可能常用的高级旁白功能。
标为支持旁白
如果用户仅通过旁白即可导览 App 中的视觉元素（包括文本、媒体、按钮和控件）并与之交互，则可将 App 标为支持旁白。换言之，用户应能通过手势或键盘指令，聚焦用户界面的各个部分、听取说明并与之交互。请确保用户仅通过旁白便能使用 App 的所有常用功能，且在此过程中不需要非视障人士协助。
所有控件须配备简明准确的标签。
标签也称“替代文本”，可以帮助旁白用户快速理解控件或界面元素的用途。
-
按钮、图标、表单控件等所有元素都应配备简明扼要的标签，为旁白用户提供文字版的描述。对于可交互的文本框及类似的表格控件，除了应说明文本值（如“555-555-1212”）外，也应配备标签（如“电话号码”）。
-
标签应简洁明了，以免界面过于繁复，影响用户理解与导览。例如，用于新建信息的按钮应标注为“新信息”，不应标注为“点此以撰写新信息”，后者过于冗长。
-
标签在脱离上下文后，仍应具备明确含义。旁白用户可能会以不同方式接触到界面元素，且操作顺序可能不固定。因此，应避免使用“点按此处”或“了解更多”等缺乏明确指向的标签。如果多个不同元素的标签相同（如购物车中的多个“删除”按钮），标签文本应明确说明操作的对象。对于不可逆操作，这一点尤为重要。例如，应明确说明购物车中的哪一件商品会被删除。
-
标签不应包含对控件类型（如“复选框”）或状态（如“已勾选”）的描述，以免旁白播报冗余信息，如“取消订阅复选框，复选框”。你可以通过 traits 或设备适用的其他 API 来描述此类内容。
-
大部分图像应配备对应描述或替代文本。纯装饰性的图像无需标签，应确保旁白完全略过此类图像。
-
如果 App 支持用户上传图像等媒体内容，则必须提供为此类用户生成内容添加标签或描述的途径，确保旁白用户能够听到相关说明。
-
图表和其他可视化数据应配备辅助说明。建议使用图表专用 API，或至少通过替代文本说明图表的主要信息。
-
如果 App 的常用界面必须显示第三方或用户生成的内容，请参阅辅助功能标签概述中有关第三方内容的详细说明。
-
如需了解更多内容，欢迎观看“编写出色的辅助功能标签”和“让您 app 中的图表可供残障人士无障碍访问”。
确保旁白用户能明确理解元素的类型，以及控件的状态或值。
此类内容可能仅以视觉形式呈现（如已勾选的复选框）。因此，你需要为使用旁白的用户提供更多信息，仅仅提供标签和文本描述并不足够。你可以通过 traits 或设备适用的其他 API 来描述此类内容。
-
用户选中某一元素时，除了标签或文本内容，旁白还应朗读该元素的类型。例如，朗读“取消订阅所有邮件，复选框”。
-
确保用户能明确理解控件的状态和值。请注意，旁白不会特意朗读控件的默认状态。例如，如果复选框未勾选，则旁白仅会朗读“取消订阅所有邮件，复选框”。此外，请务必在 API 中及时更新控件的状态和值。在用户勾选复选框后，旁白应描述该控件的新状态，即“取消订阅所有邮件，复选框已勾选”。
旁白应能够朗读 App 中的所有可见文本，且所有文本输入方式都支持用户通过旁白操作。
如果你使用 Apple 框架，则系统会为大部分可见文本提供支持。若你的 App 使用其它框架或自定义文本输入方式，则可能需要进行额外适配。例如，Apple 为基于 Unity 开发的 App 提供开源的辅助功能插件，欢迎进一步了解。
-
App 中的所有可见文本均应支持包括旁白在内的辅助技术。纯文本元素（例如段落）无需单独添加标签，但应确保旁白能够朗读文本内容。
-
自定义键盘和文本输入方式（如输入 PIN 码的小组件）应当支持旁白功能，以语音或盲文形式准确传达信息，并确保用户能够精准输入或选择文本。
-
临时状态横幅和重要的 App 内通知须及时传达给旁白用户，但不应对用户造成干扰；一般通过 AccessibilityNotification 实现。
用户使用旁白进行导览或与群组交互时，应有统一、完整、符合逻辑的体验。
用户应能够按页面顺序导览内容，或通过旁白转子等功能，直接跳转至屏幕的某个部分。
-
用户应能够跳转至任何可见元素，方式包括：线性方式（向右轻扫、VO + 右箭头键等），或转子与触控导览（适用于大多数平台）。
-
用户应能够离开当前聚焦的元素，方式包括：向前继续、向后返回（向左轻扫、VO + 左箭头键等）、转子或触控导览（适用于大多数平台）。
-
如果多个元素或操作以群组形式出现，旁白用户应能够跳转至组内的各个项目，或通过自定操作等功能直接触发群组内的操作（如回复、转发、删除等）。
-
用户应能够逐一访问各项元素，无需跳过项目或重复回到同一项目。建议在测试时，先向前完整导览所有内容，随后向后完整导览所有内容。另外，也请逐个测试所有的转子项目，包括正向与反向。
-
当后台有内容重新加载或刷新时，旁白聚焦的位置不应突然重置。例如，如果在用户浏览页底信息时，App 加载出了新内容，旁白光标不应突然跳转至页面顶部。
-
屏幕内容变化或弹出模态对话框时，旁白光标应移至新内容所在的区域，不应停留在不可见、屏幕外或后台内容中。
所有可交互元素和控件都应易于发现、易于操作，且充分适配旁白。
通过鼠标或触控屏手势能够完成的 App 内操作（如轻点、点按、拖移等），也应该支持用户通过旁白来完成。
-
旁白的激活手势（选中后轻点两下）和键盘命令（VO + 空格键）应触发与常规轻点或点按相同的行为。
-
即使旁白已打开，常规键盘操作（如方向键）和键盘辅助快捷键仍应保持可用，且旁白光标应随常规键盘导览（如 Tab 键、方向键等）同步移动。
-
如果 App 包含快捷键菜单、自定义长按等非默认操作，则建议通过旁白转子或“打开快捷键菜单”键盘命令（VO + Shift + M），将这些操作设置为自定操作。
-
对话框等模态视图应适配旁白。模态视图激活时，旁白不应跳转至背景内容。用户应能够关闭模态视图，如通过 Escape 键或 AccessibilityPerformEscape 来关闭对话框。
-
复杂的交互行为（如拖放或多点触控手势）应支持通过自定义转子或操作等方式实现，确保用户能发现且无障碍地完成该操作。请尽量使用 Apple 原生 API 以降低实现难度。
-
若 App 或其内置框架使用了自定义元素，则应确保这些元素的无障碍支持达到与 Apple UIKit、AppKit 和 SwiftUI 框架原生元素同等的标准。举例而言，自定义按钮、标签栏和滑块应支持旁白，其提供的信息也应与使用标准 API 的控件一致。
目前，若 App 的常用界面支持旁白，即可标为支持此功能，但你还可以进一步优化 App 的辅助功能。每次更新 App 时都可以重新评估 App 对旁白的支持度。不断设定优化目标，让发布的每个 App 版本都能带来更人性化的用户体验。