无障碍别等上线再补，Accessibility Personas 这套方法把问题堵在设计阶段

无障碍别等上线再补，Accessibility Personas 这套方法把问题堵在设计阶段

导语

很多团队的无障碍（a11y）流程都是「上线 → 审计 → 修 bug → 再审计」的循环，修来修去成本越来越高。A List Apart 的 Aaron Gustafson 提出了一套叫 Accessibility Personas 的方法，核心思路是：像做用户画像一样做无障碍画像，在设计阶段就把问题拦住，而不是等代码写完再补。

正文

问题：无障碍为什么总变成"事后补救"？

大多数团队的无障碍工作流是这样的：

1. 设计师按"普通用户"出图

2. 开发按设计稿实现

3. 上线前跑一遍 axe 或 WAVE

4. audit 报告出来，几十上百个 issue

5. 改一半赶上线，剩下的"下个版本再说"

这个循环的成本是递增的。设计阶段改一个颜色对比度，成本几乎为零；上线后改一套导航的焦点管理，可能要动十几处代码，还要回归测试。

WCAG 2.2 已经把这个问题说得很清楚了：无障碍要从设计开始，不是从测试结束。但真正落到流程里的团队并不多。

方案：Accessibility Personas 是什么？

Accessibility Personas 的核心思路是：在设计评审时，带入一组"无障碍用户画像"，逐个场景过一遍。

这些画像不是泛泛的"视障用户""听障用户"，而是有具体场景、具体行为、具体痛点的角色。比如：

• 小林，低视力，用系统高对比度 + 200% 放大：她能看清大字体，但颜色对比度不够时还是糊。她依赖键盘导航，因为鼠标精度不够。
• 阿明，色弱，红绿色盲：他分不清红色错误提示和绿色成功提示，需要依赖图标或文字标签。
• 小陈，运动障碍，只用键盘操作：他无法使用鼠标，tab 顺序乱了就等于用不了。
• 小吴，认知障碍，注意力容易分散：动画太多、内容太密会让他迷失，需要清晰的焦点指示和简洁的布局。

每个 Persona 都回答三个问题：

• 他能做什么（能力边界）
• 他会遇到什么障碍（当前设计的风险点）
• 怎么帮他解决（设计/开发上的调整）

怎么落地：设计评审 checklist

把 Personas 落到设计评审，不需要复杂的工具，一个 checklist 就够：

视觉层

• [ ] 颜色对比度是否达到 WCAG AA（4.5:1 正文，3:1 大文字）
• [ ] 错误提示是否只用颜色区分，有没有图标或文字辅助
• [ ] 200% 放大后布局是否可用（是否溢出、是否换行）

交互层

• [ ] 所有交互元素是否支持键盘操作
• [ ] Tab 顺序是否符合视觉流
• [ ] 焦点指示器是否清晰可见（不要 outline: none 不补）
• [ ] 模态框打开时焦点是否被捕获，关闭后是否返回触发点

内容层

• [ ] 图片是否有 alt 文本
• [ ] 表单是否有明确的 label 关联
• [ ] 错误提示是否关联到具体字段（aria-describedby）

动效层

• [ ] 动画是否有 prefers-reduced-motion 降级
• [ ] 自动播放的内容是否有暂停控制

一个真实案例：表单页面的 Persona 评审

假设你要设计一个登录页面。带着 Personas 过一遍：

| Persona | 风险点 | 调整方案 |

|———|——–|———|

| 小林（低视力） | 输入框边框太浅，放大后 label 飘走 | 边框 contrast 提到 4.5:1；label 用 float 或固定定位 |

| 阿明（色弱） | 密码强度只有颜色提示 | 加图标：🔴🟡🟢 |

| 小陈（键盘） | Tab 顺序跳到了页脚 | 调整 DOM 顺序，或管理 tabindex |

| 小吴（认知） | 错误提示堆在顶部，找不到对应字段 | 用 aria-describedby 关联，inline 显示 |

这四个调整，在设计稿阶段就能标出来，不需要等开发完再改。

结论：Personas 不是额外工作，是省时间的流程

很多团队觉得无障碍是"加分项"，优先级排在功能后面。实际上，Accessibility Personas 的核心价值是提前发现问题，而不是增加工作量。

设计阶段改一个焦点顺序，5 分钟；上线后改，可能要半天。 Personas 的意义就是把那 5 分钟用在刀刃上。

下一步：下次设计评审时，带上一张"无障碍 Personas 卡片"，过一遍 checklist。跑两个 sprint，看看 issue 数量有没有变化。

收尾

无障碍不该是上线前的"补考"，而应该是设计阶段的"预习"。Accessibility Personas 不是什么新框架，而是一种把用户多样性带入设计流程的思维方式。从下一张设计稿开始，试试带入一个 Persona，你会发现很多问题其实早就该被发现。

—

参考来源

• A List Apart — Accessibility Personas (Aaron Gustafson)
• WCAG 2.2 — W3C Web Content Accessibility Guidelines
• MDN — Understanding WCAG
• Smashing Magazine — Why Accessibility Is An Operational Capability
• Google — Designing For Global Accessibility