不要根据项目使用了哪些无障碍 API 直接勾选 Accessibility Nutrition Labels；只有用户能借助对应功能完成登录、购买、设置和核心业务等常用任务时，才应声明支持。本周先建立按设备家族划分的测试矩阵，逐项记录通过与失败路径；未经验证的项目保持未申报。

这篇清单适合准备首次填写 Accessibility Nutrition Labels、但不确定 Apple 判定标准的独立开发者；也适合同时维护 iPhone、iPad 或 Mac 版本的小团队。若本地 Mac 无法长期保留多套模拟器、测试账号和回归状态，也可以把远程 Mac 作为隔离的重复验收环境，而不是把它当成“自动通过标签”的工具。

01

先把“支持”定义为常用任务全部可完成

Accessibility Nutrition Labels 的判断单位不是某个控件有没有 accessibilityLabel，而是用户能否借助某项功能完成 App 的全部常用任务。Apple 明确把首次启动、登录、购买和设置等基础流程纳入常用任务；如果核心业务路径中存在一个关键阻断，就不能因为首页或演示页面表现良好而申报整项支持。Apple 对常用任务与测试矩阵的说明

先建立任务清单，不要从代码搜索开始。一个订阅类 App 至少应拆出以下路径：

  • 首次启动、权限提示和新手引导；
  • 登录、注册、退出登录和密码恢复；
  • 浏览核心内容、搜索、筛选和打开详情；
  • 添加、购买、恢复购买或取消操作；
  • 账户设置、通知设置和无障碍相关设置；
  • 网络异常、表单校验失败、支付失败和重新尝试；
  • 弹窗、底部操作表、深层链接和外部跳转返回。

每条任务都要写出起点、操作步骤、预期结果和实际结果。例如，“购买可完成”不应只记录按钮能被聚焦，还应验证价格、订阅周期、确认弹窗、失败提示和恢复购买是否都能被用户理解。

任务：购买月度订阅
起点：已登录测试账号，处于产品详情页
步骤：打开订阅页 → 选择方案 → 确认购买 → 返回产品页
预期：用户能识别方案、价格、当前状态，并完成或安全取消购买
结果：VoiceOver 通过；Voice Control 在确认弹窗失败
申报决策：不勾选 Voice Control

Apple 建议为每个计划申报的设备创建测试矩阵，但矩阵本身不是替代测试的证据。真正有价值的是任务清单、测试环境、失败路径、修复记录和最终结论能够互相追溯。

02

VoiceOver 与 Voice Control 必须分别验收

项目已经接入 VoiceOver 修饰符，并不代表 VoiceOver 用户可以完成购买流程。常见失败点包括焦点顺序跳跃、图标按钮没有名称、状态没有更新、自定义滑块无法调整、弹窗背后的内容仍可访问，以及错误提示只通过颜色或动画表达。

VoiceOver 验收至少覆盖以下对象：

  1. 焦点顺序：从页面标题到主要内容、操作按钮和返回路径是否符合阅读顺序。
  2. 名称与类型：按钮、开关、复选框、输入框和自定义控件是否能说清“是什么”。
  3. 状态与值：选中、禁用、加载中、价格、数量和进度是否会随操作更新。
  4. 弹窗与遮罩：模态出现后，焦点是否进入弹窗，背景内容是否暂时不可访问。
  5. 手势替代：拖拽、多指手势、长按和上下文菜单是否提供可发现的辅助操作。
  6. 错误恢复：登录失败、库存不足、网络中断后，用户能否找到重新尝试或退出路径。

Apple 的 VoiceOver 评估标准要求重要内容能够以语音或盲文方式理解，自定义元素也应提供接近原生 UIKit、AppKit 或 SwiftUI 控件的可操作性。VoiceOver 评估标准

Voice Control 不能用“VoiceOver 已通过”代替。Voice Control 的判定是用户只用语音完成全部常用任务，不接触屏幕；应分别测试“显示数字”“显示名称”、点击、滑动、输入、选择和删除等命令。自定义文本输入、第三方控件以及输入校验尤其容易出现 VoiceOver 能读、但 Voice Control 无法操作的情况。Voice Control 评估标准

因此，申报记录中应把两列分开：

  • VoiceOver：焦点、朗读、状态、弹窗、操作反馈；
  • Voice Control：可见控件命名、语音激活、文本输入、语音选择和错误恢复。

注意： 如果一个自定义购买控件只能通过精确滑动手势操作，VoiceOver 可能可以聚焦它，但 Voice Control 仍可能无法完成同一任务。此时应分别保留结果，不能用“无障碍 API 已接入”覆盖失败结论。

03

视觉适配要看任务结果，不看开关是否存在

视觉相关标签至少要拆成文字大小、深色界面、非颜色区分、对比度和减少动态效果几个独立指标。系统设置已经打开，不等于 App 在真实流程中可用。

较大文字：检查截断、遮挡和滚动

Apple 的标准允许将正文放大到至少 200% 或系统支持的最大字号；但申报时不能只确认项目使用了 Dynamic Type。必须在登录、购买、设置和错误提示等任务中检查文字是否被截断、重叠、遮挡，或者因为固定高度导致主要按钮无法操作。Larger Text 评估标准

建议至少保存以下证据：

  • 最大文字设置下的页面截图；
  • 购买方案、价格、按钮和错误提示截图；
  • 长文本、多语言和小屏布局截图；
  • 页面能否继续滚动、返回和提交的操作记录。

如果标题被截断，但详情页仍能提供完整信息，需要记录这种补偿路径；如果价格或确认按钮被遮挡，则该常用任务不应判为通过。

深色界面、颜色区分与对比度：在关键任务中复核

深色界面不能只看首页是否变黑。应检查弹窗、输入错误、加载状态、图表、支付状态和第三方内容是否仍然可辨识。对于“成功 / 失败”“已选 / 未选”“可用 / 禁用”等状态，不能只使用红绿颜色，应同时提供文字、形状、图标或位置差异。

Accessibility Inspector 可以帮助定位界面元素的标签、特征和部分视觉问题，但它不是整条任务的自动验收工具。Apple 的 Human Interface Guidelines 也建议使用 Accessibility Inspector 审查界面如何向系统辅助功能表达自身。Apple Human Interface Guidelines：Accessibility

可用命令保留一次模拟器环境信息，避免截图无法说明测试对象：

xcrun simctl list devices | grep -E "Booted|iPhone|iPad"

示例输出：

iPhone 17 Pro (iOS 26.0) (Booted)
iPad Pro 13-inch (M5) (iPadOS 26.0) (Booted)

命令输出只能证明测试设备和系统环境，不能证明标签应当勾选；真正的结论仍要来自任务记录。

减少动态效果：检查会不会阻断操作

如果 App 使用视差、缩放、旋转、持续轮播或自动播放，应在系统开启减少动态效果后重复执行核心任务。Apple 建议根据动画是否造成不适、分散注意力或影响理解，决定停用、替换或提供可控版本；不是简单地把所有动画删除。Reduced Motion 评估标准

特别要测试自动隐藏的按钮、倒计时弹窗和自动切换的轮播。如果用户来不及找到“关闭”“下一步”或“重新尝试”，即使动画本身可以被系统减弱，也不应直接判为常用任务通过。

04

字幕与音频描述只在确实存在媒体内容时申报

如果 App 的核心任务不包含视频、音频或其他时序媒体，不要为了“标签看起来完整”而勾选 Captions 或 Audio Descriptions。普通文字说明、视频字幕和音频描述不是同一种能力。

申报 Captions 前，应确认：

  • 视频中的对话是否有与时间同步的文字；
  • 关键声音是否被表达，例如提示音或环境声；
  • 用户能否知道哪些内容提供字幕；
  • 主要语言和备用语言是否覆盖实际播放路径；
  • 播放、暂停、切换语言和全屏状态下字幕是否仍可读。

Apple 允许对视频对话提供字幕，也提到封闭字幕或 SDH 能进一步表达重要非语言声音；如果 App 只有很少内容带字幕，不应因为播放器存在字幕开关就申报支持。Captions 评估标准

Audio Descriptions 则要求媒体中存在描述画面信息的额外旁白。只有选择入口、但实际可播放内容很少或没有音频描述时，不应勾选该标签。Audio Descriptions 评估标准

05

设备家族必须独立判断，不能复制一份结论

App Store Connect 会按设备家族管理无障碍声明。iPhone 通过，不代表 iPad 或 Mac 也通过；不同窗口尺寸、输入方式、键盘操作、菜单结构和平台控件都可能改变常用任务是否可完成。Apple 的 API 文档也明确把无障碍声明与设备家族关联管理，例如 iPhone、iPad 或其他受支持平台。配置无障碍声明的 API 文档

截至 2026 年 9 月 7 日，Apple 官方说明 Accessibility Nutrition Labels 初期为自愿提供，并表示未来会成为新 App 和更新提交时需要提供的信息，但相关官方页面尚未公布统一的强制生效日期。因此，不应把未经 Apple 确认的日期写进发布计划；本周应按当前 App Store Connect 页面可用选项完成准确评估。

设备矩阵可以按下面方式建立：

设备家族：iPhone
任务：登录、搜索、购买、设置、错误恢复
VoiceOver：通过 / 失败 / 不适用
Voice Control：通过 / 失败 / 不适用
较大文字：通过 / 失败 / 不适用
深色界面：通过 / 失败 / 不适用

设备家族：iPad
任务：同上，另加分栏布局与横屏路径
VoiceOver：通过 / 失败 / 不适用
Voice Control：通过 / 失败 / 不适用

如果某个标签在特定设备上不适用，应以当日 App Store Connect 提供的选项为准，不要为了保持各平台“勾选数量一致”而复制结果。

06

发布前把证据包和线上版本对齐

App Store Connect 的填写流程通常包括选择 App、进入 App Accessibility、选择设备、确认是否支持功能、选择具体标签并发布。发布后的信息会立即生效，但 Apple 说明对所有用户显示可能需要 最多 24 小时；因此标签发布后没有立刻显示，不一定代表提交失败。管理 Accessibility Nutrition Labels

发布前建议按以下 6 步执行：

  1. 冻结版本范围：确认申报针对的是即将上线的构建版本，而不是开发分支或尚未提交的修复。
  2. 列出常用任务：把首次启动、登录、购买、设置、核心业务和错误恢复写成可执行步骤。
  3. 建立设备矩阵：按 iPhone、iPad、Mac 等实际支持的设备家族分开记录。
  4. 执行辅助功能测试：分别运行 VoiceOver、Voice Control、文字大小、深色界面、对比度、减少动态效果和适用的媒体测试。
  5. 收集证据：保存测试系统、设备、构建号、截图、失败路径、修复提交和复测结果，并脱敏账号、App 名称、Bundle ID、测试用户及截图信息。
  6. 发布后复核：等待显示窗口后，从对应设备查看产品页，确认标签与线上版本能力一致。

对于需要长期执行的团队，可以把这套矩阵放入构建验收流程：构建完成后启动目标模拟器，执行固定任务，保存截图与日志；如果关键任务失败，就阻止发布标签，而不是让 CI 只检查某个修饰符是否存在。

若本地 Mac 的磁盘空间不足以长期保留多设备模拟器、测试账号和截图状态，可以参考 NodeMini 的 Mac 远程算力方案，把无障碍回归环境与日常开发环境分开。需要特定区域访问时，也可以查看 Mac mini 云算力配置页面，但仍应先确认远程会话能够稳定完成图形界面操作、模拟器运行和证据保存。

07

发布前申报决策表

验收对象 必须验证的内容 有失败项时的申报决策 证据建议
常用任务 首次启动、登录、购买、设置、核心业务、错误恢复 关键任务无法完成：不申报 任务清单、操作录屏、失败路径
VoiceOver 焦点顺序、名称、状态、值、弹窗、自定义控件 任一核心路径阻断：不申报 VoiceOver 语音结果、焦点记录、截图
Voice Control 显示数字、显示名称、语音点击、输入、选择、删除 只能触摸或键盘完成：不申报 Voice Control 语音命令记录、录屏
较大文字 最大字号下无关键截断、遮挡，内容可滚动 价格、按钮或错误信息不可读：不申报 不同字号截图、设备信息
深色与对比度 核心页面、弹窗、状态、图表仍可区分 关键状态只靠颜色或不可辨认：不申报对应项 前后模式截图
减少动态效果 轮播、缩放、视差、自动播放不阻断任务 动态效果导致无法操作或恢复：不申报 系统设置、任务结果
字幕与音频描述 主要媒体路径、语言、播放状态和内容覆盖 内容覆盖不足：不申报 媒体清单、播放截图
设备家族 每个平台独立布局、输入方式和任务结果 不复制其他平台结论 分设备矩阵、构建号

如果当前方案是把测试堆在一台个人 Mac 上，常见缺点是磁盘空间会被多个模拟器和构建产物持续占用、设备状态难以复现，且本地机器离线或被日常开发占用时无法执行固定回归。对需要短期完成版本验收、维护独立测试环境的小团队而言，按周期租用 NodeMini 的远程 Mac，通常比为一次申报专门购买并长期维护一台测试机更灵活；但若团队需要长期满负载运行、连接实体配件或保留物理真机，购买自有设备仍然更合适。

本周可以先完成一件具体工作：为每个目标设备家族创建任务矩阵，并把每个标签的结论绑定到“通过、失败或不适用”。只有当 VoiceOver、Voice Control、视觉适配和媒体支持都经过真实任务验收后，才在 App Store Connect 更新 Accessibility Nutrition Labels。