Sunqy 文档库

主题

05 · 可访问性：为什么做、怎么做、怎么验收 ​

可访问性（a11y）不是"给残疾人做的额外功能"，是"让产品对所有用户都可用"的底线。 色盲、弱视、键盘操作、屏幕阅读器……每一条都在扩大你的用户面，也是很多合规与商业要求的前提。本篇讲为什么做、通用怎么做、怎么验收；Flutter/前端的 API 落地链回各域。

速览卡 ​

项内容
一句话定位把可访问性从"可选加分项"变成"开发流程内建的质量要求"：为什么、四类通用做法、怎么验收
核心内容可访问性服务的真实人群、四类做法（语义/键盘/对比度/文字）、移动端要点、怎么验收、常见误区
读完能回答可访问性到底解决什么问题？开发时最该先做哪几件事？怎么判断自己做到位了？
相关板块H03 · UI/UX 基础 ｜ B35 · 无障碍与语义树 ｜ S05 · 数据与隐私合规

一、可访问性服务谁 ​

可访问性不只是"盲人"：

人群需求例子
视觉障碍屏幕阅读器、高对比度按钮有可读标签、文本可缩放
色觉障碍不只靠颜色区分状态用颜色 + 图标/文字
运动障碍键盘/语音操作所有功能可键盘到达
认知障碍清晰简单一致的导航、明确的反馈
暂时性障碍环境受限阳光下看不清、单手操作

每一条不仅帮助特定人群，也帮助所有人：颜色 + 图标在色盲友好，也在强光下可读；键盘可达方便专业用户提速。

二、四类通用做法 ​

2.1 语义：让"机器"也能理解 ​

界面不只是给人看的，还要能被屏幕阅读器/自动化读懂：

  • 按钮有明确的可读标签，不是"图标 + 空白"
  • 表单输入有 label 关联
  • 图片有替代文本（装饰图标记为可忽略）
  • 用正确的语义元素，而不是 div/View 堆出来的假按钮

2.2 键盘与焦点：所有功能都能到达 ​

  • 所有交互元素可达、可聚焦、可见焦点
  • 焦点顺序符合视觉阅读顺序
  • 弹窗能正确捕获并归还焦点

2.3 对比度与文字：看得见 ​

  • 正文与背景对比度达标（WCAG AA 通常 4.5:1）
  • 文字可缩放，不因放大而截断或重叠
  • 不只靠颜色传达信息（加图标/文字/形状）

2.4 状态与反馈：不静默 ​

  • 加载/空/错误/成功都有明确提示
  • 错误提示能定位到具体字段
  • 动效可被关闭（尊重"减少动态效果"偏好）

三、移动端要点 ​

移动端可访问性多几件事：

要点说明
触控目标点击区域足够大，间距不误触
语义树屏幕阅读器读到的顺序是否合理（B35）
字体缩放系统大字时布局不崩、文字不截断
动态效果尊重系统"减少动态效果"设置
方向与旋转横竖屏都可操作

Flutter 的语义树、无障碍 API 具体实现见 B35 无障碍与语义树。

四、怎么验收 ​

可访问性验收要可操作，不是"感觉还行"：

检查项方法
语义标签用屏幕阅读器走一遍主流程
键盘/焦点全程键盘操作完成一次任务
对比度用检查工具扫主要页面
文字缩放系统大字下走一遍核心流程
自动化接入无障碍扫描（CI 可跑）

经验：从"主流程"开始验收（登录、查询、下单），比全页面过一遍更能体现真实影响。先保证主流程可用，再铺开长尾。

五、常见误区 ​

误区事实
"可访问性是加分项"是底线，影响真实用户与合规
"等测试发现再说"应该内建到开发与验收流程
"做了就不许动了"要随设计迭代持续维护，防止回归
"移动端不需要"移动端屏幕阅读器使用率很高

自检清单 ​

  • [ ] 所有交互元素有可读标签，不靠颜色/图标单独传达信息
  • [ ] 主流程可全程键盘（或辅助设备）操作完成
  • [ ] 对比度达标，文字可缩放不截断
  • [ ] 状态与反馈不静默，错误能定位
  • [ ] 移动端触控目标、语义树、字体缩放已覆盖
  • [ ] 主流程做过一次辅助技术走查

动手练习 ​

练习 A：辅助技术走查 ​

用屏幕阅读器（或系统自带朗读）走一遍 App 主流程，记录"读到什么/读不到什么"，修复缺失标签。

练习 B：对比度扫描 ​

用对比度检查工具扫一个页面，把不达标的组合列出来，用设计 token 调整。

练习 C：键盘可达 ​

在 Web 端（或模拟）全程用键盘完成一次核心任务，记录焦点丢失或顺序错乱的位置。

相关文档 ​

本区 ​

其他域 ​