alert()不是用户提示组件而是调试用阻塞弹窗，必须替换；正确方案是用role="alert"/"status"配合aria-live等属性实现语义化、可访问的提示。
为什么不能用alert()做用户警告
因为alert()会强制中断所有操作、劫持焦点、无法被键盘用户关闭，屏幕阅读器朗读不可控——它根本不是为用户提示设计的，而是调试用的阻塞式弹窗。上线前必须替换。
常见错误现象：表单提交后执行alert("提交成功") → 视障用户听到“提交成功”，但不知道当前页面状态、焦点在哪、下一步该做什么；iOS VoiceOver 可能静音或延迟触发；连续调用还会卡住脚本。
真正的问题不在“怎么弹出来”，而在于“用户是否理解上下文”。原生alert()不提供任何语义、无法关联表单字段、不支持暂停/重读、也不能被自动化测试捕获。
role="alert"和aria-live="assertive"怎么配才生效
单独加aria-live="assertive"没用，必须配合语义容器和动态更新方式。最稳妥组合是：role="alert" + aria-live="assertive" + aria-atomic="true" + 动态插入文本节点（而非innerHTML替换）。
立即学习“前端免费学习笔记（深入）”；
使用场景限于紧急中断型消息，比如“密码错误”“会话已过期”。非紧急状态（如“保存成功”）应改用role="status" + aria-live="polite"。
关键细节：
- 容器不能设
display: none或visibility: hidden，否则屏幕阅读器不可见；推荐用position: absolute; left: -9999px隐藏视觉但保留可访问性 - 每次更新前先清空容器内容，避免重复朗读（如两次“邮箱格式错误”变成“邮箱格式错误邮箱格式错误”）
- 不要在
fetch回调里直接调showModal()或更新aria-live区域——需确保 DOM 已就绪且在用户手势上下文内
表单错误提示怎么关联输入框并触发朗读
核心是三要素同步：视觉错误样式 + ARIA 状态标记 + 屏幕阅读器可感知的播报通道。只改input样式或只写div错误文案都不够。
正确做法：
- 给出错的
input加aria-invalid="true"和aria-describedby="error-id" - 错误文案容器用
id="error-id"，且设role="alert"（强错误）或role="status"（弱提示） - 错误文案必须是纯文本节点，不要包裹多余标签；若需 HTML 结构（如链接），得用
aria-atomic="true"保全文本完整性 - 提交失败时，在表单顶部加一个
role="alert"错误摘要，并提供tabindex="-1"+focus()自动跳转，让用户第一时间感知整体问题
容易踩的坑：用placeholder代替label、错误提示未与input绑定、错误文案用display: none隐藏、JS 动态插入后没触发aria-live刷新。
<dialog></dialog>弹窗的无障碍要点
<dialog></dialog>本身语义正确、支持showModal()、可聚焦、原生支持 ESC 关闭，但它不是开箱即用的无障碍组件——漏掉焦点管理，就等于没做。
必须做的几件事：
- 打开前确保
<dialog></dialog>已插入 DOM（比如document.body.appendChild(dialog)），否则showModal()报错 - 调用
showModal()后，立刻dialog.querySelector('button, input, [tabindex]')并focus()到第一个可交互元素 - 关闭时，必须还原上一个焦点元素（缓存
document.activeElement，关窗后.focus()回去） - 如果有“关闭”按钮，整个弹窗要用
role="alertdialog"而非role="dialog"，否则屏幕阅读器不会按错误级别播报 - 关闭后调用
element.remove()，而不是只设display: none——残留 DOM 会干扰焦点流、被读屏软件误读
真正难的不是让弹窗出现，而是它消失之后，页面是否回到可预期、可导航、可播报的状态。很多线上 bug 都卡在这一步：弹窗关了，但焦点丢了、朗读停了、AT 还在读旧内容。
