2026/6/24 · 8:15
别等用户投诉才查无障碍：用 AI + Accessibility Inspector 做一次 iOS 界面体检
今天这一技教你先用 AI 把关键页面拆成无障碍验收清单，再用 Xcode Accessibility Inspector 检查名称、状态和朗读顺序。PM 不用先学一堆 API，也能把问题整理成 AI 编码工具能执行的缺陷单。
你可能已经在 Xcode Preview 里看过加载态、空状态和错误态，页面肉眼看起来也没问题。但还有一类问题很容易被 PM 漏掉：VoiceOver 读不出来按钮含义、图标没有可听名称、文字和背景对比太弱。Apple 在 WWDC19 里把 Accessibility Inspector 定位为一个用来发现、诊断并修复 App 无障碍问题的工具，它还能模拟 VoiceOver 会读出什么1。
今天这一技不是让你变成无障碍专家，而是把 AI 当成「验收清单助理」，再用 Accessibility Inspector 做一次能落地的界面体检。你最后要产出的不是一堆术语，而是一张可以自己修、也可以交给 AI 编码工具修的缺陷单。
这个技巧解决什么
PM 独立做 iOS 前端时，最容易检查的是「看得见的界面」。无障碍问题麻烦在于，它经常发生在「看不见的描述层」：按钮在屏幕上是相机图标，VoiceOver 却读成图片文件名；卡片上有未读小圆点，但读屏用户听不到；一个悬浮菜单要鼠标悬停才出现，键盘或 VoiceOver 用户走不到。
SwiftUI 会为界面生成 accessibility elements，VoiceOver、Voice Control、Switch Control 这类辅助技术主要通过这些元素理解和操作 App2。所以这件事的核心不是「页面漂不漂亮」，而是「系统能不能把页面正确讲给用户听」。
你要检查三件事：
| 检查点 | PM 能听懂的说法 | 常见坏味道 |
|---|---|---|
| 名称 | 用户听到这个控件时，知道它是什么吗 | 读成 star.fill、camera.on.rectangle、button 1 |
| 状态 | 用户听得出当前选中、关闭、已读、未读吗 | 视觉上有颜色变化，但读屏没有状态 |
| 顺序 | 用户一路往下听，顺序和页面任务一致吗 | 先读操作按钮，再读它属于哪条内容 |
先让 AI 把页面变成「无障碍验收单」
在打开工具前，先让 AI 根据你的页面用途列一张清单。不要直接问「这个页面无障碍好吗」，这个问题太空。把页面当成一个产品流程来描述。
可以复制这段提示词，把方括号里的内容换成你的页面：
你是 iOS 无障碍验收助手。我要检查一个 [页面名称]，用户在这里要完成 [核心任务]。页面上有这些元素：[按屏幕从上到下列出标题、输入框、按钮、图标、列表、状态提示]。请帮我列出 VoiceOver 用户必须听懂的内容：1）每个可点击元素应该听到什么名称；2）哪些状态必须被读出来；3）哪些装饰图不应该被读出来；4）如果只能检查 5 个点，优先查什么。
这一步的价值是先把「看界面」改成「听流程」。比如一个收藏按钮，AI 应该提醒你检查它是读「收藏」还是读「星形图标」，以及收藏后的状态有没有变成「已收藏」。SwiftUI 的 accessibility modifiers 可以给视图补充 label、trait、action，也可以把多个视图合并成一个更容易导航的元素2。PM 不一定要手写这些修复，但要知道问题大概会落在哪一层。
用 Accessibility Inspector 跑一遍
打开你的 App 模拟器或真机预览，然后在 Mac 上进入 Xcode 菜单：
Xcode > Open Developer Tool > Accessibility Inspector。Apple 在 WWDC19 的演示里也是从这个路径打开工具，再选择 iOS 设备作为检查目标1。按这个顺序做：
- 在 Accessibility Inspector 里选择你的模拟器或连接的设备。
- 切到 Audit 标签，点 Run Audit。
- 先看工具列出的高风险问题，比如元素没有描述、标签不可读、对比度不足。
- 点某条问题，让工具高亮屏幕上的对应元素。
- 切回 Inspector 标签，用 Point Inspection 点那个元素，再用朗读按钮听一下它会被怎么读。
WWDC23 里，Apple 展示过 Accessibility Inspector 对单个界面做 audit：它会检查元素描述是否足够、对比度是否合适，并把发现的问题列出来3。这对 PM 很友好，因为你不用先理解所有 API，先把「工具发现了什么」和「用户会听到什么」记录下来就行。
这里有个小原则：不要一看到红色问题就急着让 AI 改代码。先问自己一句：这个元素对用户完成任务有没有意义？如果是背景图，可能应该让 VoiceOver 跳过；如果是拍照按钮，就必须给一个人能听懂的名称。WWDC23 的示例也提到，装饰背景图不一定要读出来，关键内容和操作才应该暴露给辅助技术3。
把发现的问题交给 AI 修，不要只丢截图
你给 AI 编码工具的材料越像缺陷单，它越不容易乱改。每个问题按四行写：
| 字段 | 写法示例 |
|---|---|
| 位置 | 商品详情页底部的拍照按钮 |
| 现在听到 | camera.on.rectangle button |
| 应该听到 | 「拍照，按钮」 |
| 验收方式 | Accessibility Inspector 点这个按钮，朗读结果不再出现图标名 |
如果你用的是 SwiftUI，常见修复会落在 accessibility label、hint、element 合并、状态描述这些地方。Apple 的 SwiftUI 文档把
accessibility(label:) 描述为给视图添加描述其内容的标签4；WWDC24 也提醒，优先使用系统内置控件和样式，因为它们通常会保留更多内建无障碍信息，自己重做控件时就要补回这些信息2。可以这样给 AI 下任务：
请只修复无障碍描述，不改变视觉样式。根据下面的缺陷单，在 SwiftUI 页面里为对应按钮、图标和状态补充 accessibility label 或状态描述。每改一个地方都解释它会让 VoiceOver 多听到什么。不要重构页面布局。
这段提示词的重点是「只修无障碍描述，不改变视觉样式」。PM 最怕 AI 顺手重写布局，把一个小问题变成一堆新问题。修完以后，再用同一个 Accessibility Inspector 路径复测一次。
今天的最小行动
今天不用全 App 扫一遍，选一个最容易影响转化的页面就够了，比如登录页、支付页、创建内容页、商品详情页。按下面 20 分钟流程走：
- 用 AI 为这个页面生成 5 条无障碍验收清单。
- 打开 Accessibility Inspector，对这个页面跑一次 Audit。
- 逐条听 3 个关键按钮和 1 个状态提示。
- 把问题改写成「位置 / 现在听到 / 应该听到 / 验收方式」四行缺陷单。
- 让 AI 编码工具只修 accessibility 相关内容，修完再听一次。
最后提醒一句：Accessibility Inspector 的 audit 很适合做第一轮体检，但 Apple 在 WWDC23 里也明确提醒，audit 不能替代真实使用 VoiceOver、Dynamic Type 等辅助技术测试3。对独立 PM 来说，今天先做到「关键页面不读乱码、不漏状态、不乱顺序」，已经能挡掉一批很基础但很伤体验的问题。
围绕这条内容继续补充观点或上下文。