不是必须，但不加就大概率被屏幕阅读器忽略或误读为普通弹层；手写div模态框必须显式声明aria-modal="true"并与role="dialog"配对使用，否则辅助技术可能继续朗读背景内容，破坏模态隔离性。

模态对话框必须用 aria-modal="true" 吗？

不是必须，但不加就大概率被屏幕阅读器忽略或误读为普通弹层。原生 <dialog></dialog> 元素默认带语义，而手写 div 模态框必须显式声明 aria-modal="true"，否则辅助技术可能继续朗读背景内容，破坏“模态”隔离性。

常见错误是只加 role="dialog" 却漏掉 aria-modal，尤其在 React/Vue 动态渲染时容易遗漏。注意：IE 不支持 aria-modal，但 IE 本身已退出主流支持，不必为此降级处理。

• aria-modal="true" 应放在最外层容器（如 <div class="modal">）上 <li>若使用 <code><dialog></dialog>，无需手动加 aria-modal，但需调用 showModal() 而非 show()
• 关闭时建议同时移除 aria-modal 或设为 false，避免残留语义

点击遮罩层关闭模态框时，如何防止触发底层元素的 click 事件？

直接 event.stopPropagation() 在遮罩层上是错的——它会阻断自身事件冒泡，但遮罩层本就不该有业务逻辑；真正要防的是穿透点击（pointer-events 穿透或 focus 后回车触发），核心是确保遮罩层覆盖完整、且背景不可交互。

关键点在于 CSS 层级与交互控制：

• 遮罩层必须设 pointer-events: auto（默认值），不能设 none，否则无法响应点击
• 模态框主体需设 pointer-events: auto，且 z-index 高于遮罩层（否则点不到）
• 关闭逻辑应绑定在遮罩层的 click 事件上，并检查 event.target === modalBackdrop，避免点到内部按钮误关
• 键盘关闭（Esc）更可靠，建议同时支持

React 中用 createPortal 渲染模态框，为什么有时焦点没落到第一个可聚焦元素？

因为 createPortal 只解决 DOM 位置，不自动管理焦点。模态框打开后，焦点仍停留在触发按钮上，用户按 Tab 会跳到页面其他地方，违反模态框可访问性要求。


HTML Extract
使用 MinerU 从 HTML 页面和文件中提取内容，将 HTML 转换为保持标题、列表、表格及文本层次结构的干净、结构化 Markdown。F...
下载

必须手动接管焦点流：

• 模态框挂载后，立即用 ref.current?.focus() 尝试聚焦第一个 button 或 input
• 更稳妥的做法是给模态框容器加 tabindex="-1"，再调用 .focus()，确保其可接收焦点
• 监听 keydown 捕获 Tab 键，限制焦点在模态框内循环（focus-trap 逻辑）
• 关闭时，务必将焦点还原到触发按钮（保存 ref 或用 document.activeElement 记录）

原生 <dialog></dialog> 在 Safari 上打不开？

是的，Safari 直到 15.4 才支持 showModal()，且部分旧版 iOS Safari 仍不兼容。如果项目需支持 Safari 15.2 或更早版本，<dialog></dialog> 不能直接用。

实际应对策略：

• 用 typeof HTMLDialogElement !== 'function' 检测原生支持，不支持则降级为 div 实现
• 避免只靠 dialog.open 属性判断，因为 Safari 15.2 支持 <dialog></dialog> 但不支持 showModal()
• 降级方案中，CSS 的 inert 属性（用于禁用背景交互）同样不受 Safari 支持，得用 JavaScript 手动遍历并设 aria-hidden="true" 和 tabindex="-1"

真正的麻烦不在样式，而在焦点管理和语义一致性——这些细节一旦漏掉，模态框就只是个“看起来像”的弹窗，而不是一个可访问、可预期的交互单元。