WAI-ARIA 是语义补丁而非可访问性开关，仅在 HTML 原生语义缺失时按规范精准使用；必须用 role 的场景包括 tablist、dialog 等无原生标签支持的组件，禁用对 button 等原生元素强行覆盖 role；aria-hidden="true" 高危误用会全局屏蔽内容，应改用 inert 或焦点锁定；aria-label 仅对可聚焦/有交互语义元素生效，且不可与可见文本共存，优先用 aria-labelledby 复用可见文案；ARIA 正确性须通过真实辅助技术+键盘导航手动验证，而非依赖工具报错。
WAI-ARIA 不是“加了就更可访问”的开关，而是语义补丁——只在 HTML 原生能力失效时才该用，且必须严格按规范打。
什么时候必须用 role？
当组件没有对应原生 HTML 元素时，role 才是合规刚需。比如：
-
tablist、tabpanel、dialog等 UI 模式，HTML 无原生标签支持 - 自定义下拉菜单（
combobox）需配合aria-haspopup、aria-expanded和焦点管理 - 工具栏（
toolbar）需声明aria-label，并为每个按钮提供aria-pressed或aria-checked
反例：<div role="button">Click</div> —— 完全没必要，直接用 <button> 即可，否则会丢失键盘交互、表单提交、默认 focus 样式等原生保障。
aria-hidden="true" 的高危误用场景
这个属性看似简单，但极易全局锁死屏幕阅读器：
立即学习“前端免费学习笔记（深入）”；
- 给
<body>或包裹整个页面的<div>加aria-hidden="true"→ 整页内容消失，只剩<title> - 在模态框打开时仅隐藏背景却漏掉
aria-modal="true"→ 屏幕阅读器仍可朗读被遮挡区域 - 对图标用
aria-hidden="true"却未提供替代文本（如aria-label或<span class="visually-hidden">）→ 功能不可知
真正安全的做法：用 inert 属性（现代浏览器支持）或显式移除 tabindex + aria-hidden 组合，并确保焦点被正确捕获到模态框内。
为什么 aria-label 有时完全不生效？
aria-label 不是万能覆盖，它只对「可聚焦」或「有交互语义」的元素起作用：
-
<div aria-label="删除"></div>→ 多数屏幕阅读器忽略，因为div默认不可聚焦、无角色 - 正确写法：
<button aria-label="删除"></button>或<div role="button" tabindex="0" aria-label="删除"></div> - 若已有可见文本，优先用
aria-labelledby关联，而非重复覆盖aria-label
本质是 ARIA Name Calculation 规则在起作用：辅助技术按固定优先级计算名称，aria-label 仅在无其他命名来源时才被采用。
测试 ARIA 是否真起作用，不能只靠验证器
HTML 语法合法 ≠ ARIA 语义正确。常见假阳性：
- axe 或 WAVE 报“通过”，但 VoiceOver 朗读为空白或错误状态
-
aria-expanded="true"已设置，但面板未实际显示 → 辅助技术用户被误导 - 焦点顺序错乱、
tabindex滥用、缺少aria-live区域更新 → 动态内容不可感知
必须手动验证：关闭显示器，纯用键盘导航 + NVDA/VoiceOver，走完所有交互路径，确认每一步的朗读内容、焦点位置、状态变化都与视觉一致。这是唯一能暴露 ARIA 逻辑断裂的方式。
