alert() 不适合无障碍场景，因其强制中断操作、劫持焦点、屏幕阅读器朗读不可控、无 aria 支持且兼容性差；应改用 aria-live 结合 role、焦点管理与语义结构实现可控提示。
为什么 alert() 不适合无障碍场景
因为 alert() 会强制中断用户操作、劫持焦点，屏幕阅读器可能跳过上下文直接朗读，还无法被键盘用户关闭。WCAG 明确不推荐在网页中使用原生 alert() 做提示，尤其当它不是由用户主动触发（比如表单提交后）时，容易造成认知混乱和操作断层。
常见错误现象：alert("提交成功") 在表单提交后执行 → 屏幕阅读器可能只读出“提交成功”，但用户不知道当前还在原页面、焦点在哪、下一步该点什么；视障用户甚至可能误以为页面已跳转。
- 原生
alert()无 aria 属性支持，无法控制朗读时机或级别 - 无法自定义样式、位置、持续时间，也不支持暂停/重读
- 在 iOS VoiceOver + Safari 中，
alert()可能被静音或延迟触发
aria-live 怎么用才真正生效
aria-live 不是加了就自动读，关键看区域是否「动态更新」且「未被焦点抢占」。最稳妥的模式是 aria-live="polite" + aria-atomic="true" + 动态插入文本节点（而非替换整个 DOM）。
使用场景：表单校验失败提示、异步加载状态、成功 toast 提示。
立即学习“前端免费学习笔记（深入）”；
-
aria-live="assertive"仅用于紧急中断型消息（如“网络已断开”），但会打断当前朗读，慎用 - 必须确保容器本身不设
display: none或visibility: hidden，否则屏幕阅读器不可见；推荐用position: absolute; left: -9999px;隐藏视觉但保留可访问性 - 每次更新内容前，建议先清空容器再插入新文本，避免重复朗读或拼接错误（例如连续两次“密码错误”，变成“密码错误密码错误”）
<div aria-live="polite" aria-atomic="true" aria-relevant="text" style="position: absolute; left: -9999px;"></div>
如何让提示既可读又可控（含焦点管理）
纯 aria-live 解决朗读问题，但不解决「用户是否感知到、能否操作、是否干扰当前任务」。真正可用的警告提示，需要组合三要素：朗读通道（aria-live）、视觉焦点（focus()）、语义结构（role="alert" 或 role="status"）。
参数差异：role="alert" 默认触发 assertive 级别朗读，适合错误类强提示；role="status" 默认 polite，适合成功/加载类弱提示，且会被部分屏幕阅读器合并朗读（如连续两个 status，可能只读最后一个）。
- 如果提示框有「关闭」按钮，必须用
role="alertdialog"，并手动管理焦点进出（打开时focus()到第一个可交互元素，关闭后还原焦点） - 不要给
aria-live容器加tabindex="-1"后再focus()—— 这会导致朗读重复（一次 live 触发，一次 focus 触发） - 若提示需键盘可操作（如“重试”按钮），优先用
role="alertdialog"而非aria-live，因为后者不保证焦点停留
容易被忽略的兼容性细节
不同屏幕阅读器对 aria-live 的响应节奏不一致：NVDA 响应快但易漏读短文本，JAWS 对 aria-atomic="false" 更敏感，VoiceOver 在 Safari 中要求容器必须存在于 DOM 初始加载时（动态创建后加 aria-live 可能无效）。
- 测试时务必用真实组合：NVDA + Firefox、JAWS + Chrome、VoiceOver + Safari，不能只靠 ChromeVox 模拟
- 避免在
aria-live区域内放 HTML 标签（如<strong>），部分读屏会跳过或报错；如需强调，用aria-label或纯文本拼接 - React/Vue 等框架中，
aria-live容器需挂载在根组件外（如 document.body），否则组件卸载时 DOM 移除会导致朗读丢失
复杂点不在写法，而在于提示出现的时机是否与用户心智模型同步——比如表单提交后，用户预期看到的是「整个表单区域的变化」，而不是顶部飘一个孤零零的“成功”，这点连很多 ARIA 示例都忽略了。
