HTML inert 属性怎么安全管理弹窗外焦点：从遮罩层到键盘导航边界

做一个带遮罩的登录弹窗时，真正容易漏掉的不是半透明背景，而是键盘焦点还在页面后面的搜索框、菜单和链接上。HTML 的 inert 属性可以把弹窗外的内容暂时变成不可交互区域：后代元素不能获得焦点、不能响应点击，也不会继续出现在辅助技术的可访问性树中。弹窗打开时只让对话框内部接管焦点，关闭时再把焦点还给原来的触发按钮，键盘用户才能完整走完这段交互。

把 inert 当成“当前不该参与交互的整块区域”来用：打开弹窗就让主内容 inert，关闭弹窗先撤销 inert，再恢复触发按钮焦点；它不是隐藏元素，也不能代替弹窗自身的焦点管理。

先看一个焦点会“穿出遮罩”的弹窗

假设页面有一个“编辑资料”按钮，点击后显示对话框。只加遮罩和 z-index，鼠标看起来像被挡住了，但按 Tab 仍可能跳到后面的导航链接；如果脚本把焦点留在触发按钮，屏幕阅读器也不一定能马上知道弹窗已经成为当前工作区域。

编辑资料
  帮助中心
编辑资料
  昵称 
  取消

这里先把“页面主内容”和“弹窗”拆成两个明确区域。后面的状态切换只操作这两个区域，不要对 body 整体设置 inert，否则弹窗如果也是它的后代，可能一起失去交互。

打开弹窗时按固定顺序切换状态

打开流程可以分成四步：记录触发按钮、让页面区域 inert、显示对话框、把焦点放到第一个可操作控件。使用原生 dialog.showModal() 时，浏览器还会处理模态对话框的一部分行为；显式写出页面区域的 inert，代码意图会更清楚，也方便自定义弹窗结构。

const pageContent = document.querySelector('#page-content');
const dialog = document.querySelector('#profile-dialog');
const openButton = document.querySelector('#open-profile');
const closeButton = document.querySelector('#close-profile');
const nickname = document.querySelector('#nickname');

let opener = null;

function openProfile() {
  opener = document.activeElement;
  pageContent.inert = true;
  dialog.showModal();
  nickname.focus();
}

openButton.addEventListener('click', openProfile);

pageContent.inert = true 和 HTML 里的 inert 属性效果一致，布尔属性也可以直接写成

关闭时要把焦点还给触发按钮

关闭不是简单地调用 dialog.close()。如果不撤销 inert，页面会继续像“死掉”一样；如果不恢复焦点，键盘用户可能跳回文档开头，或者落到一个已经被删除的按钮上。把关闭逻辑集中在一个函数里，按钮、遮罩和 Escape 都走同一条路径。

function closeProfile() {
  dialog.close();
  pageContent.inert = false;

  if (opener instanceof HTMLElement && opener.isConnected) {
    opener.focus();
  }
  opener = null;
}

closeButton.addEventListener('click', closeProfile);

dialog.addEventListener('cancel', (event) => {
  event.preventDefault();
  closeProfile();
});

cancel 事件通常由用户按下 Escape 触发。调用 preventDefault() 后统一走自己的关闭函数，可以避免浏览器默认关闭和自定义收尾各执行一次。若弹窗打开期间触发按钮会被列表重绘替换，就要接受“原按钮已不存在”的情况，准备一个仍可见的备用焦点目标。

别用三个相似属性互相顶替

inert、aria-hidden="true" 和 pointer-events: none 都可能出现在弹窗代码里，但它们解决的问题不同。

• inert 管的是一整块区域的交互状态：不能聚焦、点击、选中文本，内容也会从辅助技术的访问范围中移除。
• aria-hidden="true" 只表达“辅助技术不要读取这部分内容”，它不能阻止键盘焦点；把仍可聚焦的按钮放在 aria-hidden 子树里会造成无障碍问题。
• pointer-events: none 只影响指针命中，Tab 键、脚本调用的 focus() 和屏幕阅读器访问仍需另外处理。

因此，遮罩的视觉层可以继续使用 CSS，交互隔离则交给 inert 和焦点逻辑。不要为了让按钮“看起来灰掉”就把整个页面设置成 disabled，普通容器并没有这个通用属性语义。

能力检测与旧浏览器降级怎么写

现在主流浏览器已经广泛支持 inert，但嵌入式 WebView、旧版企业内核和特殊运行环境仍值得做能力检测。检测重点是属性是否存在，而不是硬编码浏览器名称。

function supportsInert() {
  return 'inert' in HTMLElement.prototype;
}

function setPageBlocked(blocked) {
  if (supportsInert()) {
    pageContent.inert = blocked;
    return;
  }

  pageContent.setAttribute('aria-hidden', String(blocked));
  pageContent.querySelectorAll('a, button, input, select, textarea, [tabindex]')
    .forEach((element) => {
      if (blocked) {
        element.dataset.previousTabindex = element.getAttribute('tabindex') ?? '';
        element.setAttribute('tabindex', '-1');
      } else {
        const previous = element.dataset.previousTabindex;
        if (previous === '') element.removeAttribute('tabindex');
        else if (previous != null) element.setAttribute('tabindex', previous);
        delete element.dataset.previousTabindex;
      }
    });
}

这个降级只是示意，生产代码还要处理动态插入的控件、原本就有 tabindex="-1" 的元素以及弹窗关闭后的状态恢复。若项目需要覆盖较老环境，优先评估经过维护的 inert polyfill，并把降级路径纳入键盘测试，不要只把 aria-hidden 当成完全等价替代。

上线前用键盘走一遍验收清单

• 焦点停在“编辑资料”按钮时按 Enter，弹窗显示后焦点是否进入昵称输入框或明确的第一个控件？
• 弹窗打开后连续按 Tab，是否不会落到页面主内容的链接和按钮？
• 按 Escape、点击取消、点击遮罩这三种关闭方式，是否都撤销了 pageContent.inert？
• 关闭后焦点是否回到仍存在的触发按钮，而不是跳到页面顶部？
• 用屏幕阅读器检查时，弹窗外内容是否不会与弹窗内容同时被读到？
• 弹窗中有表单校验失败时，焦点和错误提示是否仍留在弹窗内部？

常见问题

设置 inert 后还能用 JavaScript 调用 focus() 吗？

不应把脚本调用焦点当成可靠的绕过方式。inert 的目标就是让元素及其后代不能获得焦点，代码应把需要操作的控件放在非 inert 的弹窗区域内。

弹窗可以和页面主内容放在同一个 inert 容器里吗？

不建议。inert 会作用于后代，弹窗也会被禁用。更稳妥的结构是让主内容和弹窗成为同级区域，或者只把明确的页面内容根节点设置为 inert。

inert 能替代焦点陷阱吗？

它能阻止焦点进入弹窗外的区域，但不等于完成了弹窗内的所有焦点管理。仍要设置初始焦点、处理关闭后的焦点回收，并测试 Tab、Shift+Tab 和 Escape。

把“不可交互”当成一个可恢复状态

inert 最适合表达页面状态，而不是装饰层效果。只要打开、关闭、异常退出和组件卸载都能沿着同一套状态函数完成切换，弹窗外的焦点就不会在遮罩后面“漏出来”。最后再补上键盘和辅助技术验收，才算把这条交互边界真正交付。