判断框：适合采用“双机基线＋折叠专项”验收，不适合穷举所有辅助功能组合。 先用 iPhone 18 Pro 验证登录、表单、购买、确认等共同核心任务，再在 iPhone Duo 追加内外屏切换、焦点连续性和状态恢复测试；涉及交易、身份验证或关键表单的流程，必须保留真机人工验收。

如果负责通用 App，可以用这套方法建立两款设备共享的最低无障碍基线。金融、医疗、政企团队还应补充关键任务、系统版本、构建号和审计证据；QA 团队则应把静态检查、自动化回归与真人操作分层执行。

最后更新于 2026 年 9 月 17 日；本文涉及的 iPhone Duo 开发资料、无障碍测试建议与工具能力，已核对 Apple 的 iPhone Duo 开发资料、无障碍测试文档 与相关 Human Interface Guidelines。iPhone Duo 各显示状态下的具体焦点行为，仍需以对应 SDK、模拟工具和真机复核结果为准。

先定义三个不可失败的任务，再缩小测试范围

我们不会先按“所有页面、所有辅助功能、所有设备状态”建立庞大矩阵，而是先列出本版本最不能失败的三个用户任务，例如：

  • 登录并完成身份验证；
  • 填写表单并提交；
  • 选择商品、确认订单并退出或返回。

如果产品包含媒体播放、编辑草稿或医疗记录保存，再从中选一个具有中途恢复要求的流程。Apple 的通用建议也是先识别 App 的主要任务，再决定设备、辅助设置和辅助技术组合，而不是机械遍历每一个页面。可参考 Apple 关于建立无障碍测试矩阵的说明。

这一步能直接回答一个常见疑问：无障碍验收不一定要求每个页面都在两款真机上完整重测，但关键任务必须在实际支持的设备上验证。 iPhone 18 Pro 可承担共同路径的首轮回归，iPhone Duo 则负责证明显示状态变化没有破坏任务连续性。

表单填到一半后，文字放大为什么会让关键操作消失

一个典型失败场景是：用户已经填完表单前半部分，打开更大辅助字体，随后设备展开或切换显示状态；页面仍然没有崩溃，但“继续”“确认”按钮被截断，错误提示被推到不可达区域，或者焦点移动后用户无法知道哪些字段已经完成。

动态字体测试不能只看标题是否变大。我们会在 iPhone 18 Pro 和 iPhone Duo 的代表状态分别检查：

  • 较大的标准字体与辅助字体是否导致按钮、输入框和错误提示重叠；
  • 表单提交、购买、确认、取消和退出等关键操作是否仍然可见、可触达；
  • 粗体文本和按钮形状开启后，控件边界、状态反馈与选中状态是否仍然清楚；
  • 内外屏尺寸变化后，滚动位置是否保留，焦点是否落在当前任务附近；
  • 文本变长后，是否出现只显示半个词、不可滚动的容器或被安全区域遮挡的控件。

Apple 的 Typography 指南要求布局适应不同字体大小，并尽量减少文本截断；其中还特别建议在设备上开启较大的辅助文字尺寸，确认 App 在最大尺寸下仍然可读。具体规则可参阅 Apple 的 Dynamic Type 与排版指南。

验收证据不要只保存一张“放大后页面截图”。至少应记录测试状态、操作步骤、关键控件是否可见、是否能完成任务，以及失败时的屏幕录制或 VoiceOver 输出。对于表单，最好保留“填写前—切换状态—提交前—提交后”四个时间点的证据。

内外屏切换后，VoiceOver 焦点怎样保持连续

这类问题不能根据普通 iPhone 的经验直接推定。iPhone Duo 的显示状态变化可能触发布局重建、场景变化或可见层级调整，因此我们要验证的是上下文是否连续，而不是只确认 VoiceOver 还能读出某个按钮。

重点观察以下情况：

  • 展开或合起后，焦点是否跳回页面开头；
  • 当前焦点是否落到已隐藏、不可见或重复的元素；
  • 弹窗关闭后，焦点能否回到触发弹窗的控件；
  • 列表滚动到中段后切换状态，当前位置和上下文是否保留；
  • 导航层级改变后，标题、返回按钮和当前页面关系是否仍然清晰；
  • 动态插入错误提示、加载结果或确认信息后，VoiceOver 是否收到合理通知。

Apple 的 VoiceOver 指南要求开发者在可见内容或布局变化时通知辅助技术，并正确提供标题、分组、顺序和状态信息；UIKit 也提供了 布局变化通知的说明。如果 App 使用 UIKit，可以进一步核对焦点和通知接口，但 API 层面的通知正确，不等于真机上的焦点体验一定正确。

因此，模拟器适合提前发现层级、标签和布局逻辑问题，不能替代最终焦点验收。Apple 的测试文档明确指出，VoiceOver 和 Voice Control 的关键验证应在实体设备上完成；模拟器发现的问题可以先修复，真机则负责确认真实操作路径。

状态变化后，登录、结算和播放任务是否仍然完整

“App 没有崩溃”不等于任务具备无障碍可用性。我们会挑选不容易重新开始的流程，在任务中途进行显示状态切换，再核对状态是否完整保留：

任务类型 切换前必须保存的状态 切换后验收证据 主要阻断风险
登录与身份验证 已输入账号、验证码阶段、错误提示 可继续当前步骤，不要求无提示重填 用户被退回起点或无法读取错误
表单与编辑 已填写字段、光标位置、选中项 输入内容仍在，焦点位于合理位置 内容丢失或焦点落入隐藏区域
结算与购买 商品、数量、配送或支付选择 订单摘要和确认控件保持一致 重复选择、误提交或无法确认
媒体播放 播放位置、暂停状态、字幕设置 可从原位置继续播放并读取控制状态 播放位置归零或控件标签消失
弹窗与导航 当前列表位置、触发来源、页面层级 关闭后回到触发点或明确的下一步 返回页面开头，用户失去上下文

在 iPhone Duo 上，至少要覆盖合起、展开和应用主动改变可见布局的状态；如果当前 SDK 或模拟工具尚未完整表达某种状态，就把它标记为“待真机确认”，不要把模拟结果写成已通过。

这也是 iPhone Duo 无障碍测试 与普通响应式布局回归的区别：前者不仅检查页面能否重新排版，还要确认任务的语义、输入内容和辅助技术上下文都没有丢失。

Accessibility Inspector 应该放在哪一层

Accessibility Inspector 很适合做第一层筛查，例如检查元素标签、层级、裁剪文本、颜色对比度和部分系统设置；Apple 将它定位为查看和测试视图层级无障碍信息的开发工具，具体可参考 Accessibility Inspector 官方文档。

但它回答不了以下问题：

  • VoiceOver 用户是否能理解当前页面发生了什么；
  • 焦点从内屏切到外屏后是否仍然符合任务上下文；
  • 错误提示是否在正确时间被读出；
  • 用户是否知道提交成功、选择已改变或播放已暂停；
  • 真实操作中，手势、语音、键盘或 Switch Control 是否能完成整个任务。

我们通常把工具和真人验证分成三层：

  1. 静态检查：确认标签、Traits、分组、可见性、文本裁剪和颜色等基础属性。
  2. 自动化回归：用 XCTest 与 XCUIAutomation 验证登录、表单提交、导航和状态恢复等可重复步骤；Apple 的 XCTest 文档说明了 UI 测试与交互流验证能力。
  3. 真人操作：在真机开启 VoiceOver、Voice Control、Switch Control 或外接键盘，按用户任务完成操作，而不是按控件顺序机械点击。

因此，Accessibility Inspector 是诊断工具，不是人工 VoiceOver 的替代品。尤其涉及 iPhone Duo 的折叠、展开和焦点恢复时，最终结论必须来自真实设备上的操作证据。

辅助输入要以核心路径为中心，而不是遍历所有页面

VoiceOver 之外，我们会为三个不可失败任务增加 Voice Control、外接键盘和 Switch Control 检查。优先确认关键控件具备稳定标签、合理顺序和可见反馈，而不是先统计覆盖了多少页面。

具体可以这样执行：

  • 用 Voice Control 说出打开页面、选择选项、输入内容和提交命令，确认控件名称不会因显示状态变化而失效；
  • 连接外接键盘，开启 Full Keyboard Access，检查焦点能否到达输入框、确认按钮、关闭按钮和错误提示；
  • 用 Switch Control 完成最短核心路径，确认自动扫描不会跳过关键控件；
  • 对依赖拖拽、悬停、长按或精细手势的操作，提供可替代的按钮、语音或键盘路径；
  • 在显示状态变化后重新检查可见反馈，不能只验证控件“理论上存在”。

Apple 的 辅助功能设计指南强调，界面不应依赖单一交互方式。键盘和 Full Keyboard Access 的测试注意事项，可进一步参考 Apple 的键盘交互指南。

用分层矩阵控制双机回归容量

当版本频繁发布时，最容易出现的误区是把所有任务、所有辅助功能和所有显示状态都放进每次构建。这样会挤占构建、模拟器和真机时段，却未必提高核心任务的发现率。

我们建议按风险分层：

  • 每次提交或每日构建：iPhone 18 Pro 上跑静态审计和自动化核心路径，检查标签、文本裁剪、导航和基础状态恢复。
  • 每个候选版本：iPhone 18 Pro 完成人工 VoiceOver、Voice Control、键盘和 Switch Control 的核心任务。
  • 涉及布局或显示逻辑的版本：iPhone Duo 增加内外屏切换、焦点连续性、列表位置和中途状态恢复。
  • 发布候选版本：两款真机都保留身份验证、结算、表单提交等高风险任务的人工证据。

双机无障碍回归矩阵可以按“任务风险 × 显示状态 × 辅助技术”缩减，而不是按页面数量缩减。金融、医疗和政企 App 应把审计要求较高的任务固定在候选版本；普通内容型 App 则可以把低风险页面留给自动化与静态检查。

如果现有环境出现构建排队、模拟器排队或远程协作等待，应先核算每个版本需要占用的构建时段、模拟器时段和真机人工时段，再决定是否增加独立验证通道或临时云端 Mac 环境。机器扩容只能缓解并发和等待，不能替代辅助技术使用者的人工操作。

发布门槛必须绑定证据、负责人和复核版本

最终验收可以分成三档，避免所有问题都被写成同样严重：

  • 阻断核心任务：关键按钮不可达、身份验证无法完成、输入内容丢失、VoiceOver 无法恢复焦点、结算状态错误。发布前必须关闭。
  • 明显降低可用性：焦点顺序混乱、错误提示延迟、键盘路径需要绕行、显示切换后列表位置不清楚。可以延期，但必须写明降级方式、负责人和复核版本。
  • 一般视觉瑕疵：非关键文字换行不理想、装饰性元素尺寸不一致、低风险页面存在轻微间距变化。不能影响核心任务完成，并应进入后续计划。

发布证据至少包含：

  • 设备名称与显示状态；
  • 系统版本；
  • App 构建号；
  • 辅助功能设置；
  • 测试任务和操作步骤；
  • 截图、屏幕录制、VoiceOver 语音记录或自动化日志；
  • 缺陷等级、负责人、修复版本和复核结果。

这份证据链比“已通过无障碍测试”更有价值，因为它能说明究竟验证了哪条路径、在哪个状态下完成，以及哪些结论仍然等待 SDK 或真机复核。

验收清单：先完成共同基线，再补 iPhone Duo 专项

  • [ ] 从登录、表单、结算、编辑或媒体播放中选出 3 个不可失败任务。
  • [ ] 在 iPhone 18 Pro 上完成默认字体、较大字体、粗体和按钮形状检查。
  • [ ] 确认关键按钮、输入框、错误提示和退出路径没有被截断或推入不可达区域。
  • [ ] 用 Accessibility Inspector 检查标签、层级、裁剪文本、对比度和可见性问题。
  • [ ] 用自动化测试覆盖核心任务的输入、提交、返回和状态恢复。
  • [ ] 在 iPhone 18 Pro 真机开启 VoiceOver，按真实任务而不是控件顺序完成操作。
  • [ ] 在 iPhone Duo 上分别记录内屏、外屏、合起、展开或其他可用显示状态。
  • [ ] 在任务进行中切换显示状态，核对输入内容、选中项、列表位置和错误提示。
  • [ ] 确认 VoiceOver 焦点不会跳到隐藏元素、页面开头或无关控件。
  • [ ] 用 Voice Control、外接键盘和 Switch Control 各完成至少一条核心路径。
  • [ ] 将问题分为阻断、明显降低可用性和一般视觉瑕疵三档。
  • [ ] 为每个未关闭问题记录负责人、降级方式、目标修复版本和复核证据。
  • [ ] 在最终报告中保留设备状态、系统版本、构建号和测试环境信息。

如果当前方案只是用一台常规 iPhone 加模拟器完成回归，真实缺点通常不是“少测了一台设备”这么简单，而是无法稳定复现内外屏状态、真机 VoiceOver 焦点变化和辅助输入路径，同时构建与人工验收还可能互相排队。对于临时版本验证、候选版本验收或团队暂时缺少独立 Mac 环境的情况，使用 zekmac 租赁 Mac 可以把构建、模拟器和远程协作环境单独隔离出来；但关键交易、身份验证和 iPhone Duo 的焦点连续性，仍应由团队保留真机人工验收。

zekmac M4 远程节点

用 zekmac 远程 Mac 加速无障碍验收

通过 zekmac 按需开通远程 Mac，快速搭建移动端无障碍测试与验收环境。

立即租用 Mac mini M4 对比 M4 套餐