Highlight
Apple 设计师 Chris 和 Lisa 提出 inclusion gap 框架：残障产生于身体能力与社会期望之间的差距，因此弥合这个差距的产品（电梯、麦克风、路缘斜坡）最终让所有人受益。
核心内容
很多开发者把无障碍当成”做完功能后再补一遍 VoiceOver label”的合规任务。这个 session 给出一个更实用的视角：每七个人里就有一个有某种形式的残障（00:39），这还没算上临时性的——演唱会后的暂时听力下降、嘈杂图书馆里没法外放视频、所有人都说外语的场合。把残障当成”少数人的特殊需求”，等于放弃了一大块设计空间。
session 把残障重新定义为 inclusion gap——身体能做到的事，与社会默认它应该能做到的事，两者之间的距离（04:55）。一栋两层楼，没有电梯，轮椅使用者上不去；如果楼梯也在施工，腿脚正常的人同样上不去。能力差距是真实的，但残障是环境造出来的。基于这个框架，设计师该做的工作不再是”补救”,而是去找 app 里那些隐性的 inclusion gap，把它们当成创新机会。
Chris 提到一个实用的语言技巧：把残障当成频谱来思考，多说一个”some”——“some vision”、“some hearing”。他自己法定盲，但仍能看到颜色、光线和大物体（03:29）。这个微小的措辞调整能让设计决策从”全或无”的二元判断，变成连续区间上的渐进取舍。
详细内容
session 给出五个感官维度供设计时检查：视觉、听觉、运动、语音、认知（02:35）。围绕这五个维度，Apple 提出四条可执行原则。
1. 支持多种感官（08:54）
视频字幕是最经典的例子：聋人和听障者需要它，图书馆里的人也需要它。同一个信息要至少有两条感官通道。
新功能 Accessibility Reader 把这点做到了极致（10:11）：屏幕上任何文字都能切换成视觉阅读、纯朗读、或边听边高亮文字三种模式。第三方 app Crouton 是食谱应用，导入食谱有四种方式：From Image、From Camera、From Text、Hands Free 模式（11:27）。打不了字的人可以拍照，看不见屏幕的人可以打字，做饭时手上沾满食材的人可以用语音控制翻页。同一个功能，四条感官通道。
2. 提供自定义（12:46）
每条感官通道都该可以单独定制，不只是字号变大。Accessibility Reader 允许调字号、改配色、切换 San Francisco 的高可读性字形、整体换字体（13:10）。
第三方 app Carrot Weather 把布局密度做成了滑杆（13:39）：从信息密集的仪表盘式布局，一直滑到只剩一行温度的极简界面。认知负担高的人可以选最简版本，气象爱好者可以选最密版本。app 适应人，不是人适应 app。
3. 采用 Accessibility API（14:26）
VoiceOver、Switch Control、Voice Control、Larger Text，这些 API 已经存在多年。集成它们意味着用户可以用一个外接物理按键完成全部操作——一个键切下一项，一个键确认（16:42）。Larger Text 把字号放大到三倍，前提是布局做了响应式调整。
session 举了 Blackbox 的例子（17:35）。这是一款利用 iPhone 传感器解谜的游戏，比如把手机水平旋转 360 度。低视力玩家通过 VoiceOver 朗读出的极简提示——“线索：360 个虚线组成的圆”——也能解开谜题。游戏机制本身没有变，只是多了 audio label。
4. 追踪 inclusion debt（18:45）
包容性不是一锤子买卖。session 把它类比成技术债：你做完一轮设计后，仍然会发现新的 gap，把它们记下来、排进 backlog、迭代解决。Accessibility Reader 自己也还在迭代，比如更丰富的排版选项、更多阅读风格。
设计阶段的关键问题：“如果用户是聋人/盲人/手部不便/无法说话/认知负担高，他能不能用我的 app 完成核心任务？” 不能的话，就是一个 inclusion gap，也就是一个产品机会。
另一条贯穿全 session 的原则：“Nothing about us without us”（07:48）——做关于残障人士的设计决策时，必须有残障人士参与。如果团队里没有，至少找一位使用辅助技术的用户做测试。
核心启发
1. 给 app 做一次 inclusion gap 审计
为什么值得做：在五个感官维度上各检查一次（视觉、听觉、运动、语音、认知），通常会发现 3 到 5 个隐性 gap。这些 gap 不只是无障碍问题，往往也是普通用户的痛点（嘈杂环境、双手忙碌、语言不通）。
怎么开始：列出 app 的核心任务流（注册、主功能、付款）。每个流程过五遍，每次假设用户失去一种感官能力。记下哪些步骤会卡死，那就是 gap。
2. 把”自定义”从字号扩展到每条感官通道
为什么值得做：大多数 app 的”无障碍设置”只是支持 Dynamic Type。但视障用户需要的是配色与字形，听障用户需要的是字幕与触感反馈，认知障碍用户需要的是布局密度。Carrot Weather 的密度滑杆是一个具体可借鉴的模型。
怎么开始：选一条核心界面，提供至少两套布局——信息密集版与极简版。让用户在设置里切换，并把这个偏好持久化。
3. 给视频和音频内容加第二条通道
为什么值得做：视频自动加字幕（Apple 已提供 Speech 框架本地转写），音频内容自动生成文字摘要。聋人受益，地铁上不方便外放的人也受益。
怎么开始：使用 SpeechAnalyzer 或 SFSpeechRecognizer 做本地字幕。对长音频，用 Foundation Models 生成段落摘要并允许跳转。
4. 把 inclusion debt 纳入工程流程
为什么值得做：包容性需要持续投入而非一次冲刺。把 gap 当技术债追踪，可以在每个迭代中分配固定预算解决一两条，避免它们变成永久积压。
怎么开始：在 issue tracker 里建一个 inclusion label。每次用户研究、可用性测试、AppStore 评论中发现的 gap 都打上这个标签。每个 sprint 拿出 10% 容量处理这个 backlog。
5. 至少找一位使用辅助技术的真实用户做测试
为什么值得做：模拟测试（比如自己关闭屏幕用 VoiceOver）能发现 30% 的问题，剩下 70% 必须真实用户才能暴露。“Nothing about us without us” 是设计原则，也是质量保证手段。
怎么开始：联系本地的盲人/聋人协会，或在 TestFlight 招募时明确说明寻找辅助技术用户。给他们一个核心任务，观察他们如何完成或放弃。
关联 Session
- Customize your app for Assistive Access — Assistive Access 是为认知障碍用户设计的简化 iOS 模式，看 app 如何在这个模式下重塑界面。
- Evaluate your app for Accessibility Nutrition Labels — App Store 今年新增 Accessibility 标签，让用户在下载前就能知道 app 支持哪些辅助功能。
- Make your Mac app more accessible to everyone — Mac 端无障碍 API 集成，包含 VoiceOver 在 macOS 上的特殊行为与桌面交互模式。
- Catch up on accessibility in SwiftUI — SwiftUI 的 accessibility modifier 全景，是本 session 推荐的 API 入门视频。
评论
GitHub Issues · utterances