HTML 可访问性基础

以语义、键盘可达、可访问名与状态为主线的 HTML 可访问性入门，明确 ARIA 的补充边界。

#concept #growing #frontend #html

[!info] related notes

所属：HTML 可访问性 MOC

路线：HTML 学习路线

相关：语义化元素 · ARIA · 表单

HTML 可访问性基础

这个概念为什么出现

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

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

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

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

最小可运行示例

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

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

<!-- 差：普通 div 不可 Tab 聚焦，缺按钮角色与键盘激活；emoji 文本也不能可靠说明操作 -->
<div class="btn" onclick="removeSku()">🗑</div>

再看图标按钮：

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

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

结合场景关注点

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

核心模型：四条主线

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

名称-角色-值（教学）

辅助技术用户依赖：

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

设计动机

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

边界

复杂 widget（树、网格）可能需要 ARIA 模式，但成本高。
display:none 通常同时从布局与可访问树移除；aria-hidden="true" 只影响可访问树，不阻止显示或键盘聚焦，不能用在可聚焦控件或其祖先上。\
aria-disabled="true" 只声明状态，不会阻止点击或键盘操作；原生 disabled 控件则有浏览器行为支持。
动画与自动播放另有前庭友好要求。

常见误区

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

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

工程实践

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

本节总结

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

自测题

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

参考答案

要自行实现角色、焦点、键盘激活、表单默认行为等。
在按钮等支持命名的元素上，aria-labelledby/aria-label 通常优先于内容文本；因此有可见标签时，可访问名应包含它，方便语音控制按可见文字定位。优先复用可见 label，而不是提供另一套名字。

延伸阅读

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