[!info] 关联笔记

• 所属：HTML 可访问性 MOC
• 路线：HTML 学习路线
• 相关：语义化元素 · ARIA · 表单

HTML 可访问性基础

这个概念为什么出现

如果页面只对“鼠标 + 好视力 + 好网络”友好，就会系统性排除：

• 键盘/开关用户
• 读屏用户
• 低视力/色弱用户
• 临时情境受限用户（强光、单手、慢网）

可访问性不是插件清单，而是从 HTML 结构开始的默认质量。

[!abstract] 一句话理解 先用正确的原生语义与键盘路径，再补可访问名与状态；ARIA 是最后的修补工具，不是第一选择。

最小可运行示例

场景：库存列表的危险操作

<!-- 好：原生 button，有名字，禁用态可表达 -->
<button type="button" aria-describedby="del-help">删除 SKU</button>
<p id="del-help">删除后不可恢复，需仓储主管权限。</p>

<!-- 差：div 点击，无键盘角色，无名字 -->
<div class="btn" onclick="removeSku()">🗑</div>

再看图标按钮：

<button type="button" aria-label="关闭盘点抽屉">✕</button>

期望：Tab 可聚焦；读屏读到“删除 SKU/关闭盘点抽屉”，而不是“空白”或“叉号”。

结合场景关注点

1. 可访问名来源：内容文本、aria-label、aria-labelledby、label 关联。
2. 角色优先原生元素自带。
3. 状态（expanded/disabled/invalid）需要可被辅助技术感知。

核心模型：四条主线

1. 感知：文本替代、对比度、状态不只靠颜色
2. 可操作：键盘可达、焦点可见、合理顺序
3. 可理解：标题层级、错误提示、一致命名
4. 稳健：语义正确，不因 JS 失败完全不可用

名称-角色-值（教学）

辅助技术用户依赖：

• 这是什么（role）
• 叫什么（name）
• 当前怎样（value/state）

设计动机

Web 的包容性要求同一套内容服务不同交互通道。HTML 原生控件已经编码了大量可访问行为（焦点、空格激活按钮等）；重造控件等于重造义务。

边界

• 复杂 widget（树、网格）可能需要 ARIA 模式，但成本高。
• 视觉隐藏与读屏隐藏不是一回事（display:none vs aria-hidden）。
• 动画与自动播放另有前庭友好要求。

常见误区

[!warning] 常见误区：到处加 role=button 能用 <button> 就用。div+role+keyboard handler 是高维护补丁。

[!warning] 常见误区：icon-only 控件不给名字 视觉用户靠图标，读屏用户需要文本名。

工程实践

• PR 检查：焦点轮廓是否被全局 outline:none 杀掉。
• 表单错误与字段关联。
• 路由切换后管理焦点（SPA）。
• 用键盘走完主流程作为验收。

本节总结

可访问性的第一课不是背 ARIA 属性表，而是：正确的元素 + 可访问名 + 键盘路径。

自测题

1. 为什么“点击的 div”比 button 贵？
2. aria-label 与可见文本冲突时优先谁（实践原则）？

参考答案

1. 要自行实现角色、焦点、键盘激活、表单默认行为等。
2. 尽量保证可见文本与可访问名一致；避免只给读屏另一套文案导致认知分裂。优先可见 label。

延伸阅读

资料	类型	支撑内容
MDN Accessibility	文档	总览
WAI-ARIA APG	权威	模式
WCAG	标准	成功标准