alert()和confirm()无法被屏幕阅读器播报，因其脱离DOM且不触发ARIA机制；应改用<dialog>配合aria-live区域实现可访问弹窗，并手动管理焦点与遮罩层兼容性。
为什么alert()和confirm()无法被屏幕阅读器正确播报
因为它们不在 DOM 中，也不触发任何 ARIA 机制。alert() 和 confirm() 是浏览器原生阻塞式对话框，完全脱离页面结构，辅助技术无法感知其存在，更不会读出内容。即使你写了中文提示，视障用户也听不到——这不是配置问题，是技术原理决定的。
常见错误现象：在无障碍测试中，用 NVDA 或 VoiceOver 测试时，点击按钮后“无声无息”，用户只能靠视觉发现弹窗；或者弹窗关闭后焦点丢失，键盘用户卡在空白处。
-
alert()不支持role、aria-live等任何可访问性属性 - 调用
confirm()后返回true/false，但屏幕阅读器不会播报“你选择了确定”这类反馈 - 所有原生弹窗都绕过焦点管理，关闭后不自动恢复焦点，破坏键盘导航流
dialog 元素如何配合 aria-live 实现可访问警告
<dialog> 本身不自带实时播报能力，必须搭配 aria-live 区域才能让屏幕阅读器感知内容变化。关键不是把消息塞进 <dialog> 里，而是把动态提示单独放在一个 aria-live 容器中，并在 JS 中更新它。
典型场景：用户点击“删除”按钮后，先显示模态确认框，同时向屏幕阅读器播报“即将删除该订单，此操作不可撤销”。这个播报不能依赖 dialog 内容，而要靠外部 live region。
立即学习“前端免费学习笔记（深入）”；
- 警告类消息用
role="alert"+aria-live="assertive"，确保立即打断当前播报 - 状态类消息（如“已保存”）用
role="status"+aria-live="polite" - 每次更新 live region 内容前，建议清空再写入，避免残留旧文本干扰理解
- 不要把
aria-live放在<dialog>内部——部分屏幕阅读器对嵌套 live region 支持不稳定
<div aria-live="assertive" role="alert" id="live-alert"></div>
JS 更新示例：document.getElementById('live-alert').textContent = '密码错误，请重试';
dialog.showModal() 调用后焦点没落到弹窗里怎么办
即使用了 showModal()，Safari 和部分旧版 Chrome 仍可能不自动聚焦首个可聚焦元素，导致键盘用户按 Tab 键直接跳过弹窗。这不是 bug，是规范未强制要求默认焦点行为。
容易踩的坑：只加了 tabindex="0" 或 autofocus 属性，但没做 fallback 焦点控制；或者在弹窗内有多个按钮，却没指定哪个该获得初始焦点。
- 必须在
showModal()后手动调用dialog.querySelector('button, input, [href]').focus() -
autofocus在 Safari 中对<dialog>支持有限，不能依赖 - 关闭弹窗后，必须显式将焦点移回触发按钮（比如
triggerBtn.focus()），否则键盘流断裂 - 如果弹窗内没有可聚焦元素，需加
tabindex="-1"并手动 focus，否则整个弹窗对键盘用户不可达
移动端 Safari 对 dialog::backdrop 的样式限制
dialog::backdrop 在 iOS Safari 中无法设置背景色或透明度，background: rgba(0,0,0,0.5) 会被忽略，导致遮罩层不可见。这不是 CSS 写错了，是渲染引擎限制。
真实影响：用户看不到半透明遮罩，误以为背景仍可操作；点击空白处本应关闭弹窗，但因 backdrop 不生效，事件无法捕获。
- 降级方案：不用
dialog::backdrop，改用额外<div class="backdrop">插在<dialog>外层并绝对定位 - 监听
dialog的 click 事件，通过e.clientX和getBoundingClientRect()判断是否点在弹窗区域外 - 别给 backdrop 加
pointer-events: none，否则点击无效 - 确保 backdrop 元素是
<body>直接子元素，否则在某些 Safari 版本中 z-index 会失效
复杂点在于：同一套代码在 Chrome 和 Safari 中需要两套 backdrop 处理逻辑，且不能靠 UA 判断——Safari 的版本碎片化严重，得靠特性检测或实际运行时判断。
