优先用原生语义标签，再用aria补缺；aria-label、aria-describedby、aria-live是最常被误用也最需谨慎的三个属性，其生效依赖id存在性、dom插入方式、初始非空容器等严格条件，而非简单添加。
直接结论：优先用原生语义标签，再用ARIA补缺；aria-label、aria-describedby、aria-live 是最常被误用也最需谨慎的三个属性。
哪些HTML属性能真正被屏幕阅读器识别
不是所有带 aria- 前缀的属性都有效——有些已被废弃（如 aria-role），有些在特定上下文中会被忽略（如 aria-hidden="true" 套在 button 外层会隐藏整个按钮）。真正稳定生效的有：
-
aria-label：当没有可见文本标签时兜底，但不能替代label或alt -
aria-describedby：必须指向一个存在的id，且该元素不能被aria-hidden="true"或display: none隐藏 -
aria-live="polite"：只对动态插入的 DOM 节点生效，且容器本身不能是空的或初始display: none -
lang：必须写在标签上，如lang="zh-CN"，否则 VoiceOver/NVDA 会按系统默认语言朗读 -
tabindex="0"：仅用于本不可聚焦的元素（如div），但应优先改用button或a
aria-label 和 alt 到底谁优先
顺序很明确：屏幕阅读器永远优先读 alt（对 img）、label（对表单）、legend（对 fieldset），aria-label 是最后 fallback。常见错误包括：
- 给
img同时写alt和aria-label→ 屏幕阅读器只读aria-label，alt被忽略 - 用
aria-label替代缺失的label for="xxx"→ 键盘用户 Tab 进去后仍不知道这是什么字段 -
aria-label写成“点击此处”“查看详情”→ 违反 WCAG 2.1 的“有意义链接文本”要求
正确做法：先确保原生语义存在；只有在无法修改结构时（如第三方组件封装死），才用 aria-label 补救。
aria-live 为什么有时完全不播报
这不是 bug，而是规则限制。以下任一条件不满足，aria-live 就静默失效：
- 容器初始为空（
<div aria-live="polite"></div>）→ 必须至少含一个字符或空格，如<div aria-live="polite"> </div> - 内容更新靠
innerHTML = "新提示"→ 会销毁旧节点，屏幕阅读器感知不到“变化”，应改用textContent或insertAdjacentText() - 容器被
aria-hidden="true"包裹 → 整个区域从可访问树中移除，aria-live彻底无效 - 更新发生在非主线程（如 Web Worker）→ 必须同步触发 DOM 修改
简单验证法：用 NVDA 按 Insert + B 打开“浏览模式”，再看是否列出该容器为“实时区域”。
动态插入内容后，焦点没跟过去怎么办
JS 插入新节点 ≠ 屏幕阅读器自动感知。尤其弹窗、表单错误、轮播切换等场景，必须手动干预：
- 新插入的是模态框（
dialog）→ 立即调用element.showModal()，并确保首个可聚焦子元素已设autofocus - 新插入的是错误提示（如
<p id="error-username">邮箱格式不正确</p>）→ 不仅要加aria-describedby="error-username"到对应输入框，还要把焦点移到输入框本身：inputEl.focus() - 新插入的是纯信息（如成功 toast）→ 放在
aria-live="polite"容器里，且容器不能有role="status"以外的其他 role（避免覆盖 live 行为）
最容易被忽略的一点：如果插入的是 div 包裹的按钮，别忘了它默认不可聚焦——要么换 button，要么加 tabindex="0" 并监听 Enter/Space。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
