HTML inert 怎样暂时禁用背景区域交互

我在给一个带抽屉和确认弹窗的页面整理交互时，最容易漏掉的不是弹窗本身，而是弹窗打开以后，页面背景还可以被点击、按 Tab 聚焦，甚至继续被辅助技术读到。这个场景可以先用 HTML 的 inert 解决：给背景区域设置 inert，让它和所有后代暂时退出交互；浮层关闭后移除 inert，再把焦点恢复到触发控件。

一句话概括：inert 是“区域级”的交互开关，不是只禁用一个按钮的替代品。它会影响点击、聚焦、文本选择和辅助技术访问；视觉上的遮罩、焦点回收和不支持环境的降级仍然需要开发者补齐。

先划分浮层与背景的交互边界

一个稳定的模态交互通常有两个兄弟区域：页面背景负责展示原内容，模态对话框负责当前任务。打开模态内容时，背景应该暂时不能参与交互；关闭后，背景重新可用。inert 最适合放在背景容器上，而不是随手加在 body 或单个链接上。

下面这段结构把“背景”和“当前任务”分开，后面的 JavaScript 只需要切换背景容器的状态：

打开设置
  帮助文档
页面设置
  关闭

这里的关键不是元素名字，而是边界清楚：将来页面增加导航、表单或异步提示时，只要它们仍在 main 内，就会跟随背景状态统一处理。

用 inert 暂停背景区域

inert 是布尔全局属性。它存在时，元素及其扁平树后代不能获得焦点，也不会触发普通的点击和聚焦事件；内容还会从辅助技术访问树中排除。对模态层来说，这比逐个给按钮加 disabled 更接近真正的“背景暂停”。

const pageContent = document.querySelector('#page-content');
const settingsDialog = document.querySelector('#settings-dialog');
const openButton = document.querySelector('#open-settings');

openButton.addEventListener('click', () => {
  // 先暂停背景，再打开当前任务，避免切换瞬间仍可操作页面内容。
  pageContent.inert = true;
  settingsDialog.showModal();
});

// HTMLElement.inert 与 HTML 属性 inert 表达的是同一个状态。

为了让用户能看出当前状态，还要配合遮罩或明确的视觉层级。inert 本身不会自动把背景变暗，也不会自动告诉用户为什么暂时不能操作；可见提示和真实交互状态要保持一致。

body:has(#settings-dialog[open]) #page-content {
  /* 视觉提示只表达背景暂不可操作，不代替 inert 的语义效果。 */
  opacity: 0.55;
  filter: saturate(0.7);
}

#settings-dialog::backdrop {
  /* 遮罩把当前任务和背景分开，颜色不要遮住对话框内容。 */
  background: rgb(15 23 42 / 0.42);
}

如果只是单个表单控件暂时不能使用，优先考虑 HTML 的 disabled；inert 更适合一整块内容，例如导航区、页面主体或抽屉背后的区域。

关闭浮层后怎样恢复交互

背景暂停和恢复必须成对出现。关闭对话框时移除 inert，并将焦点送回原来的打开按钮，键盘用户才不会突然失去位置。恢复动作应该挂在同一个关闭路径上，包含关闭按钮、取消动作和用户按 Esc 的情况。

function restorePage() {
  // 先恢复背景语义，再把键盘焦点送回用户刚才触发的位置。
  pageContent.inert = false;
  openButton.focus();
}

document.querySelector('#close-settings').addEventListener('click', () => {
  // close 会结束 dialog 的模态状态，恢复动作保证背景不会一直锁住。
  settingsDialog.close();
  restorePage();
});

settingsDialog.addEventListener('cancel', (event) => {
  // cancel 对应用户按下 Esc；保留浏览器默认关闭行为后再恢复背景。
  event.preventDefault();
  settingsDialog.close();
  restorePage();
});

如果关闭后还要刷新列表或显示提交结果，建议先完成 close()、inert = false 和焦点恢复，再处理后续提示。这样即使后续请求失败，页面也不会因为等待请求而保持“背景锁死”。

可访问性上要特别注意什么

我第一次使用 inert 时，以为它会顺便完成全部模态可访问性工作，后来发现它解决的是背景边界，不是完整的对话框设计。对话框仍然要有可读的名称，关闭后要有明确的焦点去向，背景状态也最好有颜色、遮罩或说明文本提示。

原生

确认删除
  
删除后无法从当前列表恢复。
  取消
  确认

还有一个容易忽视的点：inert 没有默认的视觉表现。只设置属性、不加遮罩或状态提示，用户可能只觉得页面“突然失灵”。视觉线索不能替代语义属性，但两者应该同时存在。

旧浏览器怎样保留降级方案

MDN 当前把 inert 标记为广泛可用，但实际项目仍可能需要照顾旧设备或嵌入式 WebView。我的做法是把基础布局和关闭逻辑先写成可用版本，再用 @supports 增强；不支持时至少保留遮罩、关闭按钮和手动的焦点策略。

.modal-backdrop {
  /* 基础样式让旧环境仍能区分当前浮层和背景。 */
  position: fixed;
  inset: 0;
  background: rgb(15 23 42 / 0.42);
}

@supports (inert: true) {
  /* 支持 inert 时让语义状态负责阻止背景交互。 */
  #page-content[inert] {
    pointer-events: none;
  }
}

需要说明的是，pointer-events: none 只能覆盖鼠标或触摸命中，不能代替 inert 对焦点和辅助技术访问树的处理。旧环境如果没有 inert，应该结合移除背景中的可聚焦入口、保存并恢复焦点等策略，而不是只加一层透明遮罩。

我的结论：用 inert 管区域，用 dialog 管当前任务

如果你要实现模态框、抽屉或全屏确认层，可以把职责拆开：背景容器用 inert 暂停，

对我来说，inert 最实用的地方不是少写一个点击拦截器，而是把“这整块区域暂时不属于当前交互”表达成了原生语义。它适合区域级暂停；如果只是禁用一个输入框，仍然应该使用更具体的 disabled。

常见问题

inert 会自动显示遮罩吗？

不会。它负责交互和辅助技术边界，不提供默认的视觉效果。遮罩、透明度、提示文本和层级样式需要自行设计。

给 body 设置 inert 可以吗？

通常不建议。更稳妥的做法是把背景内容放进明确的容器，只暂停该容器；浮层和需要继续工作的全局提示不应被误伤。

inert 和 disabled 有什么区别？

disabled 主要针对单个表单控件或控件组；inert 面向一整块元素及其后代，还会影响焦点、点击和辅助技术访问树。

把背景边界、焦点恢复、视觉提示和兼容回退一起考虑，模态交互才不会只“看起来打开了”，而是真的把当前任务交给用户。