无障碍体系化建设
为什么“体系化建设”比“会几个规则”更重要
无障碍最容易被压扁成一份 checklist。
例如：
- 图片加
alt - 表单加 label
- 颜色对比达标
这些当然都对。
但如果团队只停留在规则清单层面，通常做不出真正可靠的 a11y 体系。
因为无障碍的难点从来不只是规则本身。
更大的难点是：
- 它要不要进入设计系统
- 研发流程是否默认考虑它
- 测试有没有覆盖
- 产品和设计是否理解它
- 团队是否把它当成主干质量，而不是附加任务
所以“无障碍体系化建设”这个 topic 的重点不是背标准条目。
而是建立一套让团队长期稳定地做对的机制。
先把无障碍讲得既准确又不口号化
最简单、也最不容易错的理解是：
无障碍是在不同能力条件下，让用户仍然可以感知、操作、理解并完成任务。
这个定义的好处是，它不是把 a11y 限定给“某类特殊用户”。
它强调的是：
产品是否具备更广义的可达性和可完成性。
这也是为什么好的无障碍实践，常常会顺带提升：
- 键盘效率
- 文案清晰度
- 表单质量
- 交互一致性
- 代码语义性
为什么它在今天已经不是可选项
在很多市场里，无障碍不是道德加分题，而是合规与商业问题。
你提到的 ADA、EAA 这些背景，就是一个很现实的提醒：
无障碍在越来越多产品语境里，已经接近主干要求。
但即使先不谈法规，它在工程上也有非常现实的意义。
因为一个只有鼠标用户、标准视力用户、标准设备用户才能顺畅使用的产品，本身就说明系统设计过窄。
WCAG 为什么重要，但不能只背 WCAG
WCAG 是很重要的标准基础。
它给了团队一个公共语言。
但团队最容易犯的错误，是把 WCAG 当作：
背下来就等于做好无障碍。
这当然不成立。
更合理的看法应该是：
WCAG 给出原则和要求框架，而真正的产品落地需要把这些原则转成：
- 设计规范
- 组件约束
- 开发默认项
- 测试用例
否则标准永远只是文档里的知识。
POUR 为什么值得真正理解
POUR 之所以重要，不是因为它适合考试。
而是因为它帮团队从更高一层判断问题。
Perceivable
信息要能被感知。
这不只是图片 alt 的问题。
还包括：
- 对比度
- 文本可辨识性
- 状态提示是否只靠颜色
- 动态变化是否可被察觉
Operable
系统要能被操作。
这意味着：
- 键盘可达
- 焦点可管理
- 点击和触控区域合理
- 不把关键流程绑定在单一输入方式上
Understandable
用户不仅要能看到和点到，还要能理解。
这包括：
- 表单错误是否说得明白
- 流程反馈是否一致
- 操作结果是否可预期
Robust
系统应足够健壮，可以被浏览器、屏幕阅读器和其他辅助技术稳定解析。
这听起来抽象。
但它的工程含义非常明确：
不要用不语义的结构去伪装标准控件行为。
为什么语义化 HTML 仍然是第一原则
很多团队做 a11y 的第一反应是：
加 ARIA。
这通常说明方向已经偏了。
更成熟的顺序应该是：
先用正确的 HTML。
原生元素自带的大量语义和交互行为，本来就是平台给你的无障碍基础设施。
如果你用 <button>，你天然会得到：
- 键盘行为
- 角色语义
- 焦点管理的一部分默认行为
如果你用一个 div 假装按钮，你就必须自己重造这些东西。
而且很容易漏。
所以 a11y 体系建设的第一原则，常常不是“多做一点”。
而是“少违背平台原生能力”。
ARIA 为什么重要，但也为什么最容易被滥用
ARIA 是为了在原生语义不够表达的时候，补充语义和状态。
它不是一个“无障碍增强插件”。
最经典的一句话就是：
No ARIA is better than bad ARIA.
这句话值得团队牢牢记住。
因为一旦 ARIA 用错，问题不是“没加到位”。
而是可能把辅助技术直接带偏。
所以更稳妥的工程态度是：
- 原生能做的，优先原生
- 原生不够的，再按规范补 ARIA
- 不是每个交互都自己造一个语义系统
键盘导航为什么是体系建设的试金石
很多产品宣称自己“支持无障碍”。
但只要你开始纯键盘使用，就会很快看出真假。
原因很简单。
键盘流畅度几乎会同时暴露：
- 焦点顺序
- 组件语义
- 弹层行为
- 关闭机制
- 隐藏内容管理
所以如果团队资源有限，想先建立一条最有价值的检查线，
键盘可用性往往是非常好的起点。
焦点管理为什么是前端团队最该补的一课
现代前端里，最常见的无障碍问题并不一定发生在静态页面。
而是发生在复杂交互里。
例如：
- Dialog
- Drawer
- Tab
- Combobox
- Dropdown
- Command Palette
这些组件最大的问题往往不是长得不对。
而是焦点进出逻辑不对。
一旦焦点管理错了，键盘用户和辅助技术用户就会立刻卡住。
这也是为什么成熟团队会把这些复杂交互组件，优先收进设计系统统一治理。
a11y 为什么必须进入设计系统
如果无障碍只靠业务页面临时补，效果通常会很差。
因为业务团队的天然目标是交付需求。
而不是反复发明稳定的交互语义模式。
设计系统在这里的价值特别大。
它应该提供的不只是样式一致性。
还应该提供：
- 正确语义
- 键盘行为
- 焦点逻辑
- 状态暴露方式
- 组件 API 约束
这样业务团队拿到的是“默认更正确的积木”。
这才叫体系化。
自动化检测为什么必要但不够
axe-core、eslint-plugin-jsx-a11y、Lighthouse 这类工具都很有用。
它们能帮你快速发现很多明显问题。
但自动化检测永远只能覆盖一部分。
因为很多真正影响体验的问题，需要人工判断。
例如：
- 文案是否真的可理解
- Tab 顺序是否自然
- 屏幕阅读器语义是否符合用户预期
- 复杂交互是否真的能完成任务
所以成熟团队的态度应该是：
自动化检测是底线，不是上限。
为什么屏幕阅读器测试不能永远外包给“专家”
很多团队会觉得：
屏幕阅读器测试太专业，等后面统一做。
这样做通常会让问题积压。
更健康的方式是：
团队里至少要有一部分前端和 QA 具备基础使用能力。
不要求每个人都成为无障碍专家。
但至少应能做这些基础检查：
- VoiceOver 能否读通主流程
- 焦点是否迷路
- 表单错误是否能被读到
- 动态更新是否被感知
只要团队里完全没人会做这一步，a11y 就很难真正进入日常质量体系。
中国互联网语境里，为什么 a11y 常常推进更难
中国互联网产品往往面临：
- 活动页和营销页密度高
- 复杂业务状态多
- 迭代节奏快
- 视觉驱动很强
- 很多团队过去没有法规压力
这会让无障碍经常被放到“以后再补”的位置。
但也正因为如此，它更需要体系化推进。
否则每次都靠个别工程师自觉，很难长期稳定。
所以在中国语境里，a11y 推进往往不是“工程师知道重要就能做好”。
而是需要：
- 设计系统支持
- 流程门禁
- 测试基线
- 组织层认可
海外语境里为什么 a11y 更容易成为主干能力
海外很多产品，尤其是 SaaS、公共服务、教育和内容平台，更早把 a11y 放进法规、品牌和产品质量语境里。
所以前端团队会更自然地把它当成：
- 设计约束
- 工程默认项
- 测试范围
这也是为什么海外很多成熟组件库，在 API 层就把 accessibility 设计得更完整。
面试或技术分享里怎么讲更成熟
一个更成熟的表达可以是：
无障碍不是若干规则的集合，而是一套确保不同能力条件下用户仍能完成任务的系统性设计。WCAG 提供的是原则框架，但真正的工程落地必须把它转进语义化 HTML、焦点管理、组件系统、自动化检测和人工验证流程里。
如果 a11y 只靠页面临时补，它通常做不稳；只有进入设计系统和交付流程，团队才可能把无障碍做成持续能力。
实践建议
实践一：选一个复杂组件做全键盘走查
例如：
- Dialog
- Dropdown
- Tabs
- Combobox
记录：
- 焦点进入是否合理
- 关闭后焦点回哪里
- 是否能不靠鼠标完成
实践二：把一个“div 假按钮”组件重写成语义正确版本
这是最快的认知升级方式之一。
你会很直观地看到平台原生能力到底替你做了多少事。
实践三：为设计系统写一页 a11y 最低门槛
至少明确：
- 哪些组件必须键盘可达
- 哪些组件必须有人类可理解的标签
- 哪些状态必须能被辅助技术感知