很多团队把无障碍理解为给图片补alt,或者等上线后跑一次检测。实际上,用户能否看清、找到焦点、理解控件、恢复错误和在放大后继续操作,早在设计阶段就已决定。
优先处理高频、关键和不可替代的流程,再将规则纳入设计系统和开发测试。
01 文字与控件必须有足够可读性
检查正文、弱化文字、按钮、表单边框和状态颜色。不要只依赖颜色传达成功、警告或错误。
在真实设备、亮度和深浅背景中验证,而不是只看设计软件。

02 所有功能应可通过键盘完成
交互顺序要符合阅读逻辑,焦点样式清晰可见。弹窗打开后焦点进入,关闭后回到触发位置。
不要用悬停作为唯一入口。
03 表单需要明确标签与错误恢复
占位文字不能替代字段标签。错误信息应指出问题和修复方式,并与对应字段关联。
提交失败后保留用户已输入内容,避免迫使重填。

04 触控目标和间距需要真实操作验证
小图标、密集操作和相邻危险按钮容易误触。优先扩大可点击区域并提供间距,而不是只放大图形。
移动端还要考虑单手操作和系统缩放。
05 内容结构要能被辅助技术理解
标题层级、列表、表格、按钮名称和区域语义要与视觉一致。图标按钮需要可理解名称,重要图片提供等价说明。
视觉顺序与DOM顺序不应矛盾。

06 动效、缩放与响应式不能让内容消失
支持文字放大、页面缩放和窄屏重排。动画应避免诱发不适,并尊重减少动态偏好。
内容不应因为横向滚动、固定高度或悬浮层而无法访问。
无障碍优先修复10项
优先项 | 快速检查 |
|---|---|
颜色对比 | 弱化文字和按钮是否仍可读 |
键盘操作 | 能否完成核心任务 |
焦点可见 | 当前位置是否清楚 |
字段标签 | 离开占位文字后仍有名称 |
错误提示 | 是否说明如何修复 |
触控目标 | 小按钮是否容易误触 |
语义结构 | 标题、表格、按钮是否正确 |
替代内容 | 图片与图标是否可理解 |
缩放重排 | 放大后是否仍可用 |
动态控制 | 能否减少或暂停非必要动画 |
常见问题
无障碍只服务残障用户吗?
不是。清晰标签、可见焦点、错误恢复和更大触控区域也帮助临时受限、老年和移动场景用户。
自动检测工具够用吗?
不够。工具能发现部分问题,键盘流程、语义和实际理解仍需人工测试。
所有按钮都必须很大吗?
应满足可操作目标和间距要求,具体还要结合场景、平台和例外条件。
品牌色对比不足怎么办?
可调整明度、使用辅助色或改变文字与背景组合,不必放弃整个品牌色。
旧产品从哪里开始改?
先选登录、支付、表单和核心任务,建立基线组件,再逐步覆盖。