"可访问性(Accessibility，又译无障碍性)"听起来像是"给残障人士加个无障碍坡道"——只服务一小撮人。这批笔记把这个误解掰开：它其实分成三个边界不同的概念(无障碍 / 通用 / 包容)，而真正高频踩坑的落地场景，是深色模式(谁都会遇到、但坑极多)和面向辅助技术用户的研究(最容易被跳过)。
一条主线贯穿全文：无障碍不是"给少数人开小灶"，而是"把所有人都照顾到"的设计纪律——年龄增长导致的视力衰退、夜间低光、白内障、混血身份、跨文化姓名、只能靠听觉的电话用户……这些都不是边缘人群，而是"任何用户在某个时刻"。
全文五块：① 三个易混概念怎么分(无障碍 / 通用 / 包容) → ② 包容性设计落地清单(表单/插画/筛选器) → ③ 深色模式的视觉科学(到底该默认哪个) → ④ 深色模式 8 大设计坑 + 何时优先做 → ⑤ 怎么对屏幕阅读器用户做研究 + 电话语音树 16 准则。
一、三个最容易混的概念:无障碍 / 通用 / 包容
很多人把"无障碍设计 Accessibility""通用设计 Universal Design""包容性设计 Inclusive Design"当同义词，其实它们的覆盖范围、是否允许多套设计、用在哪都不同。先用一张表分清，下面再讲为什么。
| 概念 | 服务谁 | 允许多套设计变体吗 | 典型应用 | 锚定标准 |
|---|---|---|---|---|
| 无障碍设计 Accessibility | 只针对残障人士(听觉/认知/身体/视觉障碍) | 不强调变体，重在技术适配 | 数字界面的具体适配(读屏兼容、键盘可达) | 有明确标准 WCAG(Web 内容无障碍指南)——所以易于评估、能打勾验收 |
| 通用设计 Universal Design | 所有人,一套设计走天下 | 不允许——一套设计满足全部，不做变体 | 多用于物理/环境设计(因为改造实体产品成本高、做多版本不划算) | —— |
| 包容性设计 Inclusive Design | 所有背景与能力的人(年龄/经济/地域/语言/种族/能力…) | 允许多个设计变体，只要都能达到预期效果 | 多用于数字产品(数字界面改造成本低、灵活，做多版本可行) | —— |
心法：三者是"同心圆 + 不同哲学"。无障碍是最窄、最可量化的那一圈(有 WCAG 当尺子)；通用设计追求"一套设计普适于所有人"但拒绝分叉；包容性设计最宽，且主动拥抱"多套设计变体"——目标不是"服务最多数人"，而是"尽可能多地满足不同用户的差异化需求"，营造归属感。
Why（为什么数字产品该选包容性设计）：实体产品做多个版本(比如三种尺寸的门把手)成本高，所以物理世界倾向"通用设计"——找一个对所有人都凑合的折中。但数字界面改个变体几乎零边际成本(加个暗模式开关、加个筛选维度)，所以数字产品有条件做到"既照顾差异、又不牺牲任何一群人"，这正是包容性设计的主场。
反例 / 排斥现象：很多网站让用户选"种族"时给的是互斥单选项——混血用户无从选起，被设计无形排斥。包容性的改法：加"两个或更多种族"选项、或干脆改成多选框。这就是"识别排斥现象 → 调整设计反映真实用户群"的典型动作。
给 PM 的取舍：要给团队/合规一个能验收的硬指标时，谈"无障碍 + WCAG"(能打勾)；要做产品差异化、提升不同人群的归属感时，谈"包容性设计"(能讲故事、能落到具体功能)。两者不冲突——无障碍是底线，包容是上限。
二、包容性设计落地清单:从表单到插画
概念再清楚，落不到具体控件也是空谈。NNGroup 给的全是可直接抄的模式。
| 落地点 | 排斥写法(反例) | 包容写法 | 照顾了谁 |
|---|---|---|---|
| 姓名/姓氏字段 | 限制字符数、禁连字符、禁特殊字符 | 不对姓氏的长度/连字符/特殊字符设限 | 不同文化背景的用户(姓名形式千差万别) |
| 种族选项 | 互斥单选 | "两个或更多种族"选项 / 多选框 | 混血用户 |
| 性别选项 | 男/女二选一 | Tinder 提供 30+ 种性别身份，并允许自定义输入；可选择是否在资料中展示(默认关) | 性别多元用户 |
| 筛选器 | 只有通用筛选维度 | Pinterest 按发型类型(卷发/直发)筛图；Sephora 按年龄段筛护肤品 | 有个性化需求的用户，提升参与感 |
| 插画风格 | 极简但人物高度统一、忽视种族多样性 | Airbnb、Atlassian 更新插画融入多元人物特征 | 让用户在产品里"看见自己"，不被排斥 |
| 老年用户文本 | 小字、低对比 | 大字体、高对比、清晰字体；提供字号调整按钮 + 暗模式选项 | 老花眼、视力衰退的老年用户 |
心法：包容性设计的工作流是闭环的——包容性研究(理解差异) → 识别排斥现象(谁被现有设计挡在外面) → 调整设计反映真实用户群。不是拍脑袋加选项，而是先看清你的真实用户有多"不一样"。
Why：统一、极简的设计风格看似"高级"，但当它默认了一种长相、一种姓名格式、一种身份，就在悄悄告诉一部分用户"这产品不是为你做的"。归属感是留存的隐性变量。
三、深色模式的视觉科学:到底该默认亮还是暗?
深色模式(Dark Mode，浅字配深底)是最贴近"日常 + 视力差异"的无障碍话题。直觉常说"暗模式护眼"，但研究结论更细：对大多数人,光模式(Light Mode,深字配浅底)其实视觉表现更好。
先理解瞳孔机制(这是所有结论的物理根因)：瞳孔是光线进眼的"门"。环境亮 → 瞳孔收缩变小 → 对球面像差(图像模糊)更不敏感、景深增加 → 更容易聚焦文字、眼睛更不累。环境暗 → 瞳孔扩张 → 聚焦更难。光模式屏幕亮，等于人为让瞳孔收缩，所以聚焦更好。年龄因素：随年龄增长瞳孔变小，低光下进光更难，所以老年人读低对比/暗光文本更吃力，且更易被强光眩光干扰(这反而对光模式网页浏览不利)。
研究证据(全部带数字，别凭感觉)：
| 研究 / 来源 | 任务 | 结论 |
|---|---|---|
| 2013《Ergonomics》 | 视敏度(找 Landolt C 字母缺口位置)+ 校对找错；测 18–33 岁与 60–85 岁两组 | 光模式在所有维度全胜(不分年龄)；但视敏度测试里光模式对老年人的帮助小于对年轻人 |
| 《Human Factors》 | 字号 × 对比极性 | 字号越小，光模式的优势线性越大——字越小，光模式越好读。但用户主观上感觉两种模式差不多 → 印证 UX 黄金法则:"别过度依赖用户的主观反馈" |
| 2017 MIT AgeLab | 快速浏览(类比开车/手表上瞄方向、通知) | 白天两模式无显著差异；夜间光模式胜过暗模式，尤其小字时光模式显著降低错误率和反应时间。大字(4mm)比小字(3mm)好读 |
| 2018《Nature Scientific Reports》 | 长期影响:测脉络膜厚度(变薄与近视相关) | 长期光模式阅读 → 脉络膜变薄(与近视相关);暗模式阅读 → 脉络膜变厚；已近视者变薄更明显。即光模式短期视觉表现好，但长期可能有视力风险 |
| 视力受损用户(文献较少) | —— | 白内障等"浑浊眼介质"用户在暗模式下阅读更快——暗模式减少屏幕发光、降低散射和眩光。注:这些早期研究多基于旧式 CRT 显示器，现代 LED 屏性能已大幅提升，结论未必完全适用 |
心法 / 设计建议：默认用光模式，但必须提供暗模式选项，并跟随系统设置自动切换。
Why（为什么默认光、却又必须给暗）：
- 目标受众含普通用户 → 光模式短期视觉表现更优(瞳孔收缩、像差小、景深大、聚焦好)，所以默认光。
- 但要给暗模式选项，因为:① 长期光模式可能伤视力(脉络膜变薄/近视)；② 部分视力障碍用户(白内障)暗模式更好；③ 一部分用户就是偏好暗模式(尤其夜间)。
- 频繁使用的应用尤其要给暗模式；若操作系统提供暗模式 API，必须接入，让用户自选。
四、深色模式 8 大设计坑 + 何时优先做
做暗模式不是"把颜色取反"。NNGroup 的调查:115 名移动用户里约各三分之一分别用暗模式 / 亮模式 / 两者都用。用户选暗模式的三大理由——减少眼疲劳(尤其昏暗环境；但研究未证实它显著减头痛，且屏幕亮度+环境光对眼疲劳的影响和颜色模式同样重要)、省电(OLED 屏:Purdue 研究在 100% 亮度下暗模式省 67% 功耗，但 30% 亮度时只省 14%；Apple Watch 干脆不给亮模式就为续航)、美学(Spotify 只做暗模式，把它比作"黑暗影院"——次要 UI 元素淡入黑底，突出专辑封面等彩色内容)。
用户的两个关键期望:① 在系统设置里开了暗模式后，App/网站应自动跟随切换；② 用户通常不太注意哪些设计没做暗模式，也不会因此弃用——所以暗模式是"加分项"而非"生死线"，但做就要做对。
8 大设计坑(全部是"取反就翻车"的地方):
| # | 坑 | 怎么翻车 | 正解 |
|---|---|---|---|
| 1 | 图形/图片透明度 | 暗模式下图片的白色背景暴露出来，显得粗糙(房屋图在亮模式好看、暗模式露白底) | 用 SVG / WEBP / PNG(支持透明)，别用 JPG |
| 2 | 用阴影做深度感 | 亮模式靠阴影做层叠，但暗模式下浅色阴影表现不出层叠，反而让上层元素像"发光" | 最深的颜色打底层、最浅的颜色做最靠近用户的顶层(Duolingo 模态、Google Keep 卡片为例) |
| 3 | 字体过细 | 暗底上细字容易消失，视力差的用户尤甚 | 给文字/标志加描边、光晕、阴影或渐变 |
| 4 | 字体过粗 | 暗底上粗字会"渗入"背景 | 同上，确保边界清晰 |
| 5 | 颜色对比不足 | 暗模式下文字与背景对比不够，难辨认 | 守 WCAG:普通文本对比度最低 4.5:1。反例:iOS Coinbase 蓝色 UI 元素 vs 深灰背景对比 4.59:1 勉强合规，视觉上仍难分辨——合规 ≠ 好用 |
| 6 | 高饱和色 | 暗底上高饱和颜色可见度差、不达无障碍要求 | 暗模式下降低饱和度 |
| 7 | 跨渠道一致性 | App 支持暗模式，但点链接跳到的网页还是亮模式，体验割裂 | App 与其官网/邮件保持模式一致(反例:iOS TSA App 暗模式，链出的移动网页却是亮模式) |
| 8 | 页面结构/分隔符消失 | 暗模式下分隔线、卡片边界看不见，用户读不懂布局 | 不只靠分隔线，还用颜色差异区分元素(Trello 用浅灰背景块分隔;反例:Yahoo Fantasy 卡片/标题/列表在暗模式糊成一团) |
| (+) | 浮动组件 | 浮动按钮/组件融进暗背景几乎不可见 | 让浮动组件与背景明显区分(反例 National Geographic 浮动组件几乎不可见 vs Lime 浮动按钮突出) |
| (+) | 可扫描代码(二维码/条形码) | 暗模式把码反色,很多扫描设备无法识别反色码(设备默认期望"暗前景+浅背景") | 两种模式下都用相同颜色的前景和背景保证可扫(反例:邮件二维码暗模式反色扫不了;正例:Delta 登机牌放进 Apple Wallet,两模式同色背景保可扫) |
何时优先投入做暗模式(四种场景):
| 场景 | 为什么暗模式重要 | 例子 |
|---|---|---|
| 长时间使用 Long sessions | 久用时暗模式减眼疲劳 + 省电 | 新闻应用、电子书阅读器 |
| 频繁使用 Frequent usage | 高频打开时降低视觉疲劳 | 消息类应用 |
| 低光环境 Low-light | 黑暗中亮屏刺眼，暗模式更舒适 | 流媒体应用 |
| 少媒体内容 Little use of media | 图/视频少，暗模式负面影响小、好实现 | 文本为主的应用 |
三条落地建议:① 自动适配系统设置——别让用户在每个 App 里手动开；② 测试暗模式——确认所有元素(尤其透明背景图、浮动元素)在暗模式清晰可见；③ 检查邮件——确认字体、标志、图像在暗模式邮件客户端显示正常。
五、面向辅助技术用户的研究 + 电话语音树 16 准则
无障碍不能只靠"专家自检 + 跑 WCAG 工具"，得让真实的辅助技术用户来用。这一节是方法论。
5.1 怎么对屏幕阅读器(Screen Reader)用户做移动端研究
屏幕阅读器 = 把屏幕内容读出声、让视障用户靠听觉+手势操作设备的辅助技术。这类用户很难在常规招募数据库里找到——但有低成本高效的办法。
| 环节 | 做法 | Why |
|---|---|---|
| 招募 | 口碑招募:联系当地盲人组织(如美国国家盲人联合会 NFB)；定期测试就和组织/用户建长期关系，建用户面板随时可约 | 低成本、还能建立有意义的合作关系；常规数据库里几乎找不到这类用户 |
| 测试形式 | 选面对面，不选远程 | 参与者在熟悉环境更放松；研究者能观察更多细节——如何用外接盲文键盘、肢体语言和表情反馈。别让参与者来实验室，尽量去他们熟悉的地方 |
| 研究规划 | 用打印的研究计划和笔记;预留额外设置时间;研究者要熟悉屏幕阅读器操作 | 参与者家中可能没多显示器；打印材料减少干扰；陌生环境帮人准备设备更花时间 |
| 记录 | 双路记录:文档摄像头拍手势 + 屏幕录制拍屏幕；并提供音频反馈和报时 | 完整捕捉关键行为;参与者看不到时间，需研究者定期口头告知进度 + 简短音频确认"我在关注你" |
记录五元素对应表(直接照搬):
| 要记录的会话元素 | 用什么技术记 |
|---|---|
| 参与者的屏幕 | 参与者用移动设备加入视频通话并共享屏幕 |
| 参与者持设备的手 | 文档摄像头 |
| 参与者的评论 | 文档摄像头的麦克风 |
| 主持人的评论 | 文档摄像头的麦克风 |
| 屏幕阅读器的音频输出 | 文档摄像头的麦克风 |
心法:对屏幕阅读器用户的研究要更多规划和灵活性(参与者会频繁变换持机姿势，相机要不断重新对准)，但这是真正改善无障碍性的关键一环——光靠工具检测查不出真实使用障碍。
5.2 电话语音树(IVR / Phone-Tree)系统:16 条可用性准则
电话语音导航(IVR，互动语音应答)是被忽视的无障碍场景——它完全依赖听觉，而人类获取的信息 83% 来自视觉、仅 11% 来自听觉，所以纯听觉导航天然增加记忆和认知负担。(NNGroup 指出 IRS 国税局电话树可深达 10 层，活像迷宫。)
四大根本难题(理解了才知道准则为什么这么设计):
- 责任分配不清:用户打电话往往是因为网站找不到信息，结果有些 IVR 反而把人导回网站，火上浇油。
- 目标冲突:用户想找真人，企业想省钱减人工——根本利益对立。
- 用户别无选择:电话常是最后渠道，所以遇阻碍格外沮丧无助。
- 听觉劣势:见上(83% vs 11%)。
16 条准则(本质是把 Nielsen 十大可用性启发式搬到"只能用耳朵"的语境):
| # | 准则 | 对应的可用性原则 |
|---|---|---|
| 1 | 优先提供语言选择 | 别强迫用户听不懂的冗长信息 |
| 2 | 帮用户记录信息 | 技术信息放慢语速、可重播、或发到用户手机(降记忆负担) |
| 3 | 用一致的术语和控件 | 如统一用 "#" 键回退(一致性) |
| 4 | 始终允许撤销选择 | 每层菜单都能回到上一决策点(用户控制与自由) |
| 5 | 允许立即选择 | 不强制听完所有选项才能操作(效率) |
| 6 | 使用独特的语言 | 每个选项表达独特，避免混淆(识别) |
| 7 | 提供语音输入的替代 | 除语音描述外给键盘选择作备用(灵活性) |
| 8 | 提供有用的非工作时间信息 | 报工作时间、网站、紧急联系方式 |
| 9 | 保持简洁 | 砍掉冗长促销/解释 |
| 10 | 提供明确反馈 | 用户选完给简短确认(系统状态可见性) |
| 11 | 给用户找信息的时间 | 要身份证明等信息时留充裕时间 |
| 12 | 给出所需信息的示例 | 说清号码/信息的格式 |
| 13 | 菜单选项前置 | 先说任务信息、再说按哪个键(减记忆负担——别让用户记着"任务"等"按键") |
| 14 | 使用真人录音 | 比机械合成音更亲和、更符期待 |
| 15 | 提供定期状态更新 | 等待时报排队进度和预计时长 |
| 16 | 提供等待期回拨功能 | 长时等待时可保位置稍后回拨，减挫败 |
心法:电话语音树的可用性和任何界面遵循同一套基本原则——它不是特殊物种，只是"输入输出通道更窄(只剩耳朵和键盘)"的极端版界面。把视觉界面的反馈、一致性、撤销、识别优于回忆等原则翻译到听觉通道，就是这 16 条。
源自 NNGroup Topics / Accessibility - 可访问性 无障碍性(5 篇)。十大可用性启发式(本篇 IVR 16 准则与之同源)见 NNGroup 可用性测试与十大可用性启发式(10 条启发式完整表 · 复杂应用应用 · 用户愉悦层级 · 测试方法 5 人法则/招募/远程/任务场景/分步任务/态度vs行为/4步分析/小样本误差/竞争性评估);包容性设计与全球化/伦理的延伸见 NNGroup 交互模式·伦理·全球化·新兴技术(15 个模式 · 欺骗模式/潜入/危险UX · 包容性设计 · 全球化跨文化/语言切换/尺码/全渠道 · VR-AR/GenAI提示控件 · 用户自主性 · UX文案长度/推荐内容);深色模式的颜色/对比/视觉层级原理见 NNGroup 视觉设计原理·格式塔分组·视觉层次·排版·色彩·图像(19 篇 · 五大视觉原则/格式塔接近-相似-闭合-共同区域/视觉层次-网格-黄金比例/字体术语-搭配-阅读字体/色彩60-30-10/图片优势效应-照片-意象/美学-可用性效应/术语表);Apple 平台的无障碍与暗模式实现见 Apple HIG 无障碍与伦理 Accessibility(九大原则/包容性/隐私/文案/RTL);屏幕阅读器用户招募与定性研究方法见 NNGroup 定性研究与研究方法工具箱(方法全景/访谈/共情图/样本量/任务设计/主持/专家评估/工作坊/伦理)。图片与原文档(含 Tinder/Pinterest/Sephora/Airbnb 截图、iOS 亮暗模式对比、IRS 电话树插图、屏幕阅读器研究现场照)保留在 sources。