登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  前端

HTML inert 如何锁住模态框背后的页面:焦点隔离、点击拦截与无障碍验收

来源:17golang原创

时间:2026-08-30 03:58:20 398浏览 收藏

做后台管理页的删除确认时,最容易漏掉的不是弹窗样式,而是弹窗打开后背景仍能被 Tab 键走到、按钮仍能响应点击。HTML 原生的 inert 可以把一整块背景内容变成不可聚焦、不可点击的区域,再配合 dialog 的模态行为,把“当前只能操作弹窗”这件事交给浏览器处理。

最小可靠组合是:用 dialog.showModal() 打开弹窗,把背景容器的 inert 设为 true;关闭后恢复为 false,并把焦点送回触发按钮。

实践要点
  • inert 会影响后代的焦点、点击和辅助技术树,不只是盖一层灰色遮罩。
  • 模态弹窗用 showModal(),背景隔离用 inert,两者职责不要混在 CSS 里。
  • 验收至少覆盖 Tab、鼠标点击、Esc 关闭和关闭后的焦点回归。

先复现背景页面还能操作的问题

页面有一个主内容区和一个确认弹窗。若只给弹窗加遮罩,背景按钮视觉上变暗了,但它们仍可能出现在 Tab 顺序里。这个差异在键盘用户和读屏用户那里尤其明显。

返回草稿列表

确定删除这份草稿吗?

这里的关键不是把 pointer-events 写成 none,而是让页面的交互状态真的发生变化:背景区域进入 inert,弹窗保持可操作。

用 dialog 和 inert 建立清晰的隔离边界

打开弹窗时保存触发按钮,把 page-content.inert 设为 true,再调用 dialog.showModal()。下面的链路只保留三个真实节点:dialog 接收模态状态,inert 锁住背景,focus 落到弹窗内。

dialog、inert 和 focus 的模态隔离调用链示意图

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

openButton.addEventListener('click', () => {
  pageContent.inert = true;
  dialog.showModal();
  dialog.querySelector('button[value="cancel"]').focus();
});

dialog.addEventListener('close', () => {
  pageContent.inert = false;
  openButton.focus();
});

可见成功状态是:弹窗打开后,按 Tab 只能在取消和确定之间移动;点击背景链接不会触发导航;关闭弹窗后,焦点回到“删除草稿”按钮。showModal() 让 dialog 进入顶层模态状态,inert 则明确表达背景不可交互。

属性写法和脚本写法怎么选

静态页面可以直接写

,但动态弹窗更适合使用 HTMLElement.inert,因为打开和关闭动作都能在同一处完成。不要把 aria-modal 当成点击拦截器:它主要向辅助技术表达模态语义,不能替代真正的交互隔离。

HTMLElement.inert、aria-modal 与 click 事件的验收关系示意图

function setModalState(open) {
  pageContent.inert = open;
  dialog.toggleAttribute('aria-modal', open);
  if (open) {
    dialog.showModal();
  } else if (dialog.open) {
    dialog.close();
  }
}

实际项目里,如果使用原生模态 dialog,优先让它承担语义和顶层展示;只有在自定义容器或兼容旧浏览器时,才需要额外检查 aria-modal 是否与真实状态一致。背景上的 click 事件不应再有业务效果,这一点要用实际点击验证,而不是只看 DOM 属性。

四个验收动作能抓住大部分回归

  1. 鼠标点击“删除草稿”,确认弹窗出现,背景变为 inert。
  2. 连续按 Tab,确认焦点不会落到“返回草稿列表”或其他背景控件。
  3. 直接点击背景链接,确认没有导航和业务 click 处理。
  4. 按 Esc 或点击取消,确认弹窗关闭、背景恢复可操作,焦点回到“删除草稿”。

如果只做了视觉遮罩,第二和第三步很容易失败;如果只恢复了背景状态而没有恢复焦点,第四步会暴露键盘操作断点。

兼容和实现时的几个边界

MDN 将 inert 标为跨浏览器广泛可用,但项目仍应按目标浏览器做一次兼容性测试。对单个按钮这种控件,不要滥用 inert,直接使用 disabled 更贴合语义。另一个常见坑是把弹窗本身放进被设为 inert 的容器;模态 dialog 能逃逸祖先的 inert 影响,但显式给 dialog 自身加 inert 仍会让它不可操作。

收尾检查清单

  • 打开动作是否先保存触发按钮,再设置 pageContent.inert = true
  • 弹窗是否通过 showModal() 打开,而不是只切换 CSS?
  • 是否验证了背景 click、Tab 顺序和读屏可见性?
  • 关闭后是否把 inert 恢复为 false,并将 focus 送回触发控件?

常见问题

inert 会不会等同于 display:none?

不会。内容仍在布局中,只是不能获得焦点、点击或被辅助技术正常访问,视觉上是否隐藏要另行决定。

只设置 aria-modal 可以吗?

不可以。它不能阻止背景点击,也不能自动改变 Tab 顺序;仍需真实的模态机制和背景隔离。

关闭弹窗后为什么要手动 focus?

为了让键盘用户回到触发动作所在的位置。否则焦点可能落到不可预期的文档位置,尤其是在弹窗内容较长时。

总结

模态交互的可靠性不在遮罩颜色,而在状态边界。让 dialog 负责模态呈现,让 inert 负责背景隔离,再用 Tab、click、Esc 和焦点回归做验收,页面行为才和用户看到的“当前只能处理确认框”一致。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>