可访问弹窗的焦点陷阱、关闭恢复与背景隔离

我以前实现弹窗时，最容易把时间花在遮罩、动画和居中布局上，最后才补键盘交互。结果通常是鼠标看起来没问题，按 Tab 却跑到背景链接，Escape 关闭后焦点又丢到页面开头。现在我会反过来：优先用原生

官方参考：https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/showModal

无障碍模式参考：https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

真正可访问的模态弹窗必须同时满足三件事：焦点进入并留在弹窗任务内，关闭后回到合理位置，弹窗打开期间背景对所有用户都不可操作。只有 aria-modal="true" 而没有这些行为，并不算完成。

先决定弹窗是不是真正的模态任务

模态弹窗会中断主页面任务，用户必须完成或取消当前操作才能回到背景。因此它适合确认删除、编辑少量字段、选择关键选项等短任务；如果内容需要长期对照主页面，侧边栏、非模态浮层或独立页面往往更合适。

这个判断很重要。把普通信息面板标成模态，会让键盘和辅助技术用户失去访问背景内容的能力；相反，把必须阻断背景的确认框做成普通浮层，又会让焦点跑到被遮住的控件。

用原生 dialog 建立语义与背景隔离

showModal() 会把原生 dialog 显示在顶层，并让同一文档内除弹窗及其后代之外的内容变为 inert。这样背景控件不能被点击，也不会进入页面的正常交互范围。遮罩可以用 ::backdrop 绘制。

删除项目


    
    
确认删除项目？
    
删除后需要从备份中恢复。

    

      
      取消
      确认删除
    
  

/* 只负责视觉遮罩；交互隔离由 showModal 的模态语义提供。 */
#delete-dialog::backdrop {
  background: rgb(15 23 42 / 55%);
}

/* 让键盘用户始终能看见当前焦点。 */
#delete-dialog :focus-visible {
  outline: 3px solid #2563eb;
  outline-offset: 3px;
}

不要用设置 open 属性代替 showModal()。直接打开的 dialog 是非模态状态，不会获得相同的顶层与背景隔离行为。若弹窗位于 iframe 内，阻断范围也只在该 iframe 所属文档，不会自动让父页面 inert。

为不同内容选择初始焦点

弹窗打开后，焦点必须进入弹窗，但“第一个按钮”不总是最佳答案。我会根据任务性质选择：

• 短确认框：把焦点放到取消或最安全的操作，避免误触不可逆按钮；
• 简单表单：聚焦第一个需要用户输入且没有错误的字段；
• 长文本、列表或表格：给标题或顶部静态元素添加 tabindex="-1" 并聚焦，让读屏用户先理解结构；
• 大内容弹窗：避免聚焦底部操作导致顶部内容滚出视野。

示例使用 autofocus 把初始焦点放在“取消”。如果规则需要根据数据动态决定，可以在 showModal() 后调用目标元素的 focus()，但不要同时让多个元素带 autofocus。

统一处理关闭与焦点恢复

原生 dialog 支持 close()、method="dialog" 表单以及 Escape 触发的取消请求。浏览器会为原生模态弹窗处理焦点恢复；实际组件中我仍会保存触发器，作为动态列表、触发器被替换或业务关闭后的明确兜底。

const openButton = document.querySelector('#open-delete');
const dialog = document.querySelector('#delete-dialog');
const pageHeading = document.querySelector('main h1');

let invoker = null;

openButton.addEventListener('click', () => {
  // 在打开前记录真实触发元素，不能假设永远只有一个固定按钮。
  invoker = document.activeElement;
  dialog.showModal();
});

dialog.addEventListener('close', () => {
  // 触发器仍存在时恢复原位，否则进入业务流程中的合理后继位置。
  if (invoker instanceof HTMLElement && invoker.isConnected) {
    invoker.focus();
  } else if (pageHeading instanceof HTMLElement) {
    pageHeading.setAttribute('tabindex', '-1');
    pageHeading.focus();
  }
});

dialog.addEventListener('cancel', (event) => {
  // 默认不阻止 Escape；只有未保存数据确实需要二次确认时才 preventDefault。
  console.debug('用户请求关闭弹窗', event.type);
});

如果确认操作会删除触发器所在的列表项，就不应该把焦点送回已经不存在的按钮。更合理的去向可能是新建条目后的首个单元格、删除后相邻行的操作按钮，或页面标题。恢复规则应属于业务流程，而不是弹窗组件里写死的 CSS 选择器。

只在不得不用自定义弹窗时手写陷阱

维护旧组件、特殊渲染容器或受限兼容环境时，可能不能直接改成原生 dialog。这时 role="dialog" 和 aria-modal="true" 只会向辅助技术表达语义，不会自动阻止点击、Tab 或程序化焦点进入背景。

自定义实现至少要同时完成下面几项：

• 打开前保存触发器，打开后把焦点移入弹窗；
• Tab 在最后一个可聚焦元素处回到第一个，Shift+Tab 反向循环；
• 主内容容器设置 inert，但弹窗不能放在被 inert 的祖先内部；
• Escape 与可见关闭按钮使用同一关闭逻辑；
• 关闭时移除 inert，并恢复到触发器或逻辑后继位置；
• DOM 更新后重新计算可聚焦元素，避免缓存过期。

我不建议在原生 dialog 已能满足需求时再叠加一套手写 Tab 陷阱。两套机制同时维护，反而容易在 Shadow DOM、动态禁用控件或嵌套弹窗中产生重复跳转。自定义方案是兼容兜底，不是默认起点。

用键盘与辅助技术验收

弹窗完成后，不要只点一遍鼠标。至少按以下清单验证：

常见问题

给 div 加 aria-modal 就能隔离背景吗？

不能。ARIA 改变的是辅助技术可感知的语义，不会自动实现焦点限制、点击阻断或背景 inert。自定义 dialog 仍需要完整的交互代码。

原生 dialog 还需要 aria-modal="true" 吗？

用 showModal() 打开的原生 dialog 已具备模态语义和行为，通常不需要重复添加。更重要的是提供可访问名称、正确初始焦点和可见关闭方式。

点击遮罩要不要关闭弹窗？

这取决于任务风险。轻量预览可以支持，数据编辑或不可逆确认不应把一次误点变成关闭。无论是否支持遮罩关闭，都必须保留键盘可达的显式关闭按钮。

弹窗中没有可聚焦控件怎么办？

给标题或顶部静态容器设置 tabindex="-1" 并聚焦它，同时提供一个可见的关闭按钮。纯信息弹窗如果不需要阻断背景，也应重新考虑是否真的需要模态。

小结

可访问弹窗的采用路径很清晰：先确认任务确实需要模态，再用