accessibility

Web 无障碍

无障碍是一项质量属性，而不是可以留到最后再添加的功能。从编写第一行标记时就应考虑无障碍。无障碍界面让有视觉、运动、听觉或认知障碍的人能够感知、浏览和使用你的应用。它们也有助于键盘重度用户、网络连接较慢的人、暂时受伤的用户，以及身处受限环境中的任何人。

无障碍为何重要

维度	影响
法律	大多数司法辖区的法律（ADA、EAA、Section 508、EN 301 549）都要求数字产品具备无障碍能力。不合规会带来诉讼风险和经济处罚。
道德	全球约有 16% 的人口存在某种形式的残障。将他们排除在数字服务之外是一种选择，而非不可避免的结果。
业务	无障碍产品能触达更广泛的受众、改善 SEO（结构化内容有助于爬虫抓取）、降低支持成本，并且通常与更高的整体易用性评分相关。
技术质量	无障碍要求促使代码使用整洁的标记、恰当的语义和关注点分离，从而提升可维护性。

---

WCAG 原则：POUR

《Web 内容无障碍指南》将所有成功标准归纳为四项原则。每项无障碍要求至少对应其中一项。

原则	所回答的问题	示例
可感知	用户能否感知内容？	图片的文本替代内容、视频字幕、足够的颜色对比度、可调整大小的文本
可操作	用户能否与每个控件交互？	可通过键盘操作、有充足时间完成任务、不含会诱发癫痫的动画、清晰的导航
可理解	用户能否理解内容和 UI 行为？	易读的语言、可预测的导航、输入辅助和错误消息
健壮	能否兼容各种辅助技术？	有效的标记、恰当使用 ARIA、兼容屏幕阅读器和其他工具

---

符合性等级

WCAG 定义了三个等级。每个更高等级都包含其下方等级的全部标准。

等级	目标受众	典型要求
A	最低标准，消除最严重的障碍	大多数法律和采购要求从此等级开始
AA	行业标准，解决大多数用户遇到的大多数障碍	ADA、EAA、Section 508 以及大多数组织政策均要求达到此等级
AAA	最高标准，并非所有内容类型都能达到	理想目标；在可行的情况下有选择地应用

对于大多数项目，以 AA 级为目标。它能满足大多数实际需求，并避开与某些内容类型冲突的要求。

---

语义 HTML 基础

原生 HTML 元素自带语义、键盘行为和屏幕阅读器播报。使用正确的元素是最有效的无障碍技巧。

不要使用	应使用	原因
<div onclick="...">	<button>	按钮可获得焦点，会播报其角色，并能响应 Enter 和 Space
<span class="link">	<a href="...">	链接会被播报为“链接”，支持鼠标中键点击，并会出现在链接列表中
<div class="header">	<header>、<nav>、<main>、<footer>	地标元素让屏幕阅读器用户能够在页面区域之间跳转
<div class="list">	带有 <li> 的 <ul> / <ol>	列表会播报项目总数和当前位置（“第 3 项，共 7 项”）
<div class="table">	带有 <th> 的 <table>	表头会将数据单元格与其标签关联起来，供屏幕阅读器读取
用于输入框的样式化 <div>	<input>、<select>、<textarea>	原生表单控件内置标签关联、验证和辅助技术支持

标题层级

标题会创建一个大纲，屏幕阅读器用户可以像浏览目录一样浏览大纲。

• 每个页面使用一个 <h1> 描述页面用途
• 不要跳过层级（例如，不要从 <h2> 跳到 <h4>）
• 使用标题构建结构，而非调整视觉样式。外观由 CSS 控制

---

常见的无障碍问题

问题	影响	修复方法
图片缺少替代文本	屏幕阅读器会读出文件名，或者不读任何内容	添加描述性的 alt；纯装饰图片使用 alt=""
颜色对比度不足	低视力用户无法阅读文本	普通文本达到 4.5:1，大号文本达到 3:1（AA）
无法通过键盘操作交互元素	键盘和开关设备用户会完全无法操作	使用原生交互元素，或添加 tabindex="0" 和按键处理程序
表单标签缺失	屏幕阅读器无法说明输入框的用途	使用 for/id 关联每个输入框与 <label>，或将输入框嵌套在标签中
媒体自动播放	会使屏幕阅读器用户感到不适，也会对有认知障碍的用户造成伤害	切勿自动播放；如无法避免，请提供醒目的暂停/停止控件
缺少跳转链接	键盘用户每次打开页面都必须逐项浏览整个导航栏	将跳转到主要内容的链接设为页面中第一个可聚焦元素
缺少焦点指示器	键盘用户会无法确定自己在页面上的位置	移除 outline 时，务必提供醒目的自定义替代样式
缺少页面语言	屏幕阅读器可能会误读内容	在 <html> 上设置 lang 属性（例如，lang="en"）
动态内容无法访问	屏幕阅读器不会播报页面加载后发生的更改	使用 ARIA 实时区域播报动态更新
缺少文档标题	屏幕阅读器用户切换标签页时无法识别页面	为每个页面设置唯一且描述清晰的 <title>
触控目标过小	运动障碍用户无法可靠地点按小型控件	最小尺寸为 24x24 CSS 像素（AA）；为方便操作，建议使用 44x44
动效和动画	可能导致眩晕、恶心或癫痫发作	遵循 prefers-reduced-motion 媒体查询；闪烁频率不得超过每秒 3 次

---

无障碍表单

表单中的无障碍问题危害最大：用户可能无法完成购买、注册或其他关键工作流。

关联标签

每个表单控件都需要以编程方式关联标签：

<label for="email">Email address</label>
<input type="email" id="email" name="email" required>


<label>
  Email address
  <input type="email" name="email" required>
</label>

错误处理

• 在相关字段旁内联显示错误，而不是只在表单顶部显示
• 使用 aria-describedby 将错误消息与对应的输入框关联
• 在未通过验证的字段上使用 aria-invalid="true"
• 编写清晰、具体的错误文本（例如“请输入格式为 [email protected] 的电子邮件地址”，而不是“输入无效”）

必填字段

• 使用 required 属性（原生验证）或 aria-required="true"（自定义验证）标记必填字段
• 不要只依赖颜色或星号表示必填状态。请添加“（必填）”等文字

---

颜色与对比度

绝不能仅通过颜色传达信息。请结合文字、图标、图案或其他视觉提示。

对比度比例（WCAG AA）：

元素	最低比例
普通文本（小于 18pt / 粗体小于 14pt）	4.5:1
大号文本（18pt 及以上 / 粗体 14pt 及以上）	3:1
UI 组件和图形对象	3:1

快速改进：

• 使用浏览器开发者工具检查对比度（Chrome DevTools 会在悬停时显示比例）
• 遵循 prefers-color-scheme，支持深色模式
• 使用模拟色盲（红色盲、绿色盲、蓝黄色盲）测试设计

---

参考文件

参考资料	内容
ARIA 模式	何时使用 ARIA、角色和属性、组件模式（标签页、模态框、手风琴、下拉菜单）、实时区域、地标角色
键盘与焦点	Tab 顺序、方向键导航、焦点锁定、跳过链接、焦点恢复、可见的焦点指示器、触控目标
测试策略	自动化工具、手动测试清单、屏幕阅读器测试、对比度验证、无障碍树、CI 集成

---

与其他技能的集成

情况	推荐技能
构建能够提供无障碍错误响应的 REST 或 GraphQL API	api-design
会影响无障碍性的安全标头（CSP、iframe 限制）	security
使用单元测试和集成测试测试无障碍组件	testing
不牺牲无障碍性的性能优化	performance