本文深入解析如何借助
先说一个核心结论：在现代 Web 开发中，实现真正无障碍的模态对话框或抽屉式导航，关键不在于“手动劫持 Tab 键并循环焦点”，而在于正确运用语义化原生能力，让浏览器自动完成焦点管理。
遗憾的是，不少开发者仍停留在“手动劫持”的思维定式里——监听 keydown、判断焦点位置、再用 focus() 强制跳转。这种方式的弊端很明显：不仅增加代码复杂度，还极易因事件时序问题（如 keyup 与 keydown 的差异），引发“刚抵达最后一个元素就跳回第一个”的反直觉行为。结果就是焦点过早循环，彻底打乱键盘用户的操作预期。
✅ 正确路径：用
HTML5 原生
- 将焦点捕获至对话框内首个可聚焦元素（无需手动 focus()）；
- 限制 Tab 键仅在对话框内部循环（即自然焦点环，非 JS 模拟）；
- 阻断背景内容交互（视觉遮罩 + 逻辑禁用）；
- 支持 Esc 关闭、点击 backdrop 关闭，并在关闭后自动将焦点恢复至触发按钮；
- 设置 aria-modal="true" 和 role="dialog"，并动态管理 aria-hidden 属性。
const drawer = document.getElementById('mobileDrawer');
const openBtn = document.getElementById('openMenuBtn');
const closeBtn = document.getElementById('closeDrawerBtn');
openBtn.addEventListener('click', () => {
drawer.showModal(); // 自动接管焦点、禁用背景、启用 Tab 循环
openBtn.setAttribute('aria-expanded', 'true');
});
closeBtn.addEventListener('click', () => {
drawer.close();
openBtn.setAttribute('aria-expanded', 'false');
});
// 可选：监听 close 事件统一清理状态
drawer.addEventListener('close', () => {
console.log('用户已关闭抽屉，焦点已自动返回 openBtn');
});
⚠️ 注意：showModal() 是模态语义的黄金标准。若使用 show()（非模态），则不会禁用背景，也不限制 Tab 流——此时手动实现焦点陷阱反而违反无障碍原则，因为用户本应能自由切换上下文。
❌ 错误认知：试图用纯 CSS/HTML 实现“无 JS 焦点循环”
问题中提到的“非 JS 方式让 Tab 回到第一个元素”，本质上是对模态模式的误解。HTML 和 CSS 无法主动干预焦点流转逻辑：:focus 是状态伪类，tabindex 仅控制可聚焦顺序，但没有任何纯 CSS 或 HTML 属性能够监听 Tab 键按下并重定向焦点。所谓“无 JS 焦点循环”在技术上不可行，也不符合 WCAG 要求——真正的解决方案是交由浏览器通过语义化模态机制（如
若因兼容性需降级支持旧浏览器，则必须使用 JavaScript 实现合规焦点陷阱，但应遵循以下规范：
- 打开时：firstFocusableElement.focus()；
- 监听 keydown（非 keyup），捕获 Tab 键；
- 当焦点在最后一个可聚焦元素且按 Shift+Tab 时，跳至最后一个；按 Tab 时，跳回第一个；
- 所有可聚焦元素显式声明 tabindex="0" 或使用原生可聚焦标签（
- 关闭后：triggerElement.focus() 恢复焦点。
✅ 替代方案：inert 属性用于轻量级非模态遮蔽
当场景不满足
主页面内容
此链接不可聚焦、不可点击、对读屏器不可见菜单
inert 的优势在于：它从 DOM 层面移除交互能力与可访问性暴露，比 aria-hidden="true" + pointer-events: none + tabindex="-1" 组合更可靠、更简洁，且已被主流浏览器（Chrome 113+, Firefox 126+, Safari 17.4+）广泛支持。
总结：无障碍模态的核心是“信任浏览器”，而非“控制焦点”
- ✅ 推荐首选：
- ✅ 必须设置：
标题 + aria-labelledby（或 aria-label），确保屏幕阅读器准确播报；
- ✅ 关闭后：焦点自动回归触发源，无需额外 JS；
- ❌ 避免手动焦点循环逻辑，除非你正在 polyfill
- ? 兼容性兜底：对不支持
真正的无障碍不是“模拟行为”，而是“声明意图”——用
