role="alertdialog" 是 ARIA 定义的需用户立即交互的模态对话框角色，适用于不可逆操作（如删除数据）、权限拒绝或关键流程阻断等场景，须配 aria-labelledby、aria-describedby、焦点管理及键盘交互逻辑。
role="alertdialog" 是什么，什么时候该用
role="alertdialog" 是 ARIA 规范中定义的一个语义角色，表示一个需要用户立即注意、且必须交互（如确认或关闭）的模态对话框。它不是普通弹窗，也不是 alert() 的 HTML 替代品——它本质是“中断当前流程 + 强制响应”的可访问性组件。
常见误用场景：用它替代 loading 提示、表单校验提示、成功 toast；或者没配 aria-labelledby 和 aria-describedby，导致屏幕阅读器只读出“alertdialog”，不读内容。
- 真正该用它的情况：用户操作触发了不可逆行为（如删除全部数据）、权限拒绝后需重新授权、关键业务流程被阻断（如支付失败且无法重试）
- 不该用它的情况：输入邮箱格式错误、上传进度条、通知类消息（这些更适合
role="alert"或role="status"） - 浏览器不会自动聚焦或禁用背景交互——这些必须手动实现，否则只是个“有语义的 div”
必须配齐的 ARIA 属性和 DOM 结构
光写 role="alertdialog" 没用。屏幕阅读器依赖配套属性才能理解上下文和操作意图。
最简可用结构需同时满足：
立即学习“前端免费学习笔记（深入）”；
-
aria-labelledby指向标题元素（如<h2 id="del-title">确认删除？</h2>），不可为空或指向不存在的 ID -
aria-describedby指向描述性内容（如解释后果的段落），若无描述则可省略，但不能留空值 - 至少包含一个可聚焦的焦点管理入口（通常是第一个按钮），且打开时需用 JavaScript 主动
.focus() - 背景元素需加
aria-hidden="true"（注意：不是display: none，否则会破坏焦点流）
示例片段：
<div role="alertdialog" aria-labelledby="del-title" aria-describedby="del-desc"> <h2 id="del-title">永久删除所有文件</h2> <p id="del-desc">此操作无法撤销，且影响所有关联设备。</p> <button onclick="confirmDelete()">确定删除</button> <button onclick="closeDialog()">取消</button> </div>
焦点陷阱和键盘交互必须手写
HTML 不会自动实现模态行为。role="alertdialog" 本身不阻止 Tab 离开、不拦截 Esc、也不限制背景点击——全靠 JS 补足。
关键逻辑缺一不可：
- 打开时：用
element.focus()聚焦到第一个可操作元素（通常是确认按钮），否则焦点可能留在背景 - Tab 键：监听
keydown，检测 Tab 到最后一个元素时，强制跳回第一个；Shift+Tab 到第一个时跳到最后一个 - Esc 键：必须监听并关闭对话框，同时把焦点还给触发它的元素（如原按钮）
- 点击背景遮罩层：不能仅靠 CSS 遮罩，要绑定
click事件并调用关闭逻辑，否则视障用户无法关闭
漏掉任意一项，都会让使用键盘或屏幕阅读器的用户卡死在对话框里。
兼容性和测试盲区
不同屏幕阅读器对 role="alertdialog" 的播报差异很大：NVDA 会读标题 + 描述 + “alertdialog”，VoiceOver 可能只读标题，JAWS 有时会重复播报两次。不能依赖“写了就一定被正确读出”。
真实测试要点：
- 用 NVDA + Firefox、VoiceOver + Safari、JAWS + Chrome 分别测试打开/关闭/Tab 导航流程
- 检查焦点是否始终在对话框内，背景元素是否仍可被 Tab 访问（如果可以，说明
aria-hidden没生效或没覆盖全） - 关闭后，焦点是否回到触发源——这是很多 JS 框架（如 React Modal）默认不处理的点
- 不要信“无障碍检测工具扫过没报错”：axe 或 WAVE 只能查属性是否存在，查不出焦点是否真被锁住
最常被忽略的是：没有为对话框设置 tabindex="-1"，导致它无法被键盘聚焦，进而使焦点管理失效。这个细节小，但一漏就全盘崩。
