模态框产生焦点陷阱因默认浏览器行为未限制焦点范围，导致键盘用户焦点逃逸至背景内容，影响可访问性；需通过捕获初始焦点、限制内部循环及正确使用ARIA属性来解决。
HTML焦点陷阱，尤其在模态框（Modal Dialog）里，核心问题是键盘用户和屏幕阅读器用户在打开模态框后，焦点可能会意外地跳出模态框，或者在模态框内部无法正常循环，导致他们无法有效操作或退出。避免这种陷阱的关键在于，通过编程方式将焦点限制在模态框内部，并在模态框关闭时将焦点准确地归还到它最初被激活的地方。
要彻底解决模态框的焦点陷阱问题，我个人在处理这类问题时，通常会从几个核心点入手，这基本上能覆盖所有关键场景，并且是构建一个真正可访问模态框的基础。
一个关键的步骤是焦点捕获与限制。当模态框被激活时，必须确保用户的键盘焦点被“锁”在模态框内部。这意味着当用户按下
Tab键时，焦点应该从模态框的最后一个可聚焦元素跳回到第一个可聚焦元素，而不是跳到模态框背后的页面元素。反之，
Shift + Tab也需要实现逆向循环。这通常需要监听模态框内部的
keydown事件，特别是
Tab键。你需要获取模态框内所有可聚焦的元素（比如按钮、输入框、链接等），找出其中第一个和最后一个，然后根据当前焦点的位置进行判断。如果焦点在最后一个元素上按下
Tab，就将焦点移到第一个；如果焦点在第一个元素上按下
Shift + Tab，就移到最后一个。别忘了
event.preventDefault()来阻止浏览器的默认行为。
焦点归还机制也是一个经常被忽略但对用户体验至关重要的细节。当模态框关闭时，焦点应该自动回到打开模态框的那个元素上。想象一下，你点击一个按钮打开了模态框，操作完关闭后，焦点却回到了页面的顶部或者某个随机的位置，这会让用户感到非常困惑，尤其对于依赖键盘导航的用户来说，这简直是灾难。所以，在模态框打开前，记录下当前拥有焦点的元素（通常是触发模态框的那个按钮），然后在模态框关闭时，将焦点重新设置回这个元素。
立即学习“前端免费学习笔记（深入）”；
ARIA属性的正确使用不只是为了屏幕阅读器，更是为了让整个交互模型更加清晰和语义化。给模态框设置
role="dialog"或
role="alertdialog"，以及
aria-modal="true"，这能明确告诉辅助技术这是一个模态组件，并且它会阻止与页面其他部分的交互。同时，使用
aria-labelledby和
aria-describedby将模态框的标题和描述与模态框本身关联起来，提供语义化的上下文，这对于屏幕阅读器用户理解模态框内容至关重要。
还有，一个好的模态框应该允许用户通过按下
Esc键来关闭。这同样需要监听
keydown事件，并在检测到
Esc键时触发关闭逻辑。这是一种非常普遍的用户习惯，不提供这个功能会让人觉得模态框很“硬”。
这些步骤虽然看起来有些繁琐，但却是构建一个真正可访问的模态框不可或缺的。我个人通常会把这些逻辑封装成一个可复用的组件或钩子（比如在React或Vue中），这样在不同的项目中就能保持一致性，避免重复造轮子，也能确保每次的实现都符合可访问性标准。
为什么模态框会产生焦点陷阱，这有什么影响？
说白了，焦点陷阱的产生，很多时候是因为我们太习惯于用鼠标操作了，而忽略了键盘和辅助技术用户的视角。默认情况下，浏览器并不知道你弹出的一个
div是一个“模态框”，它只是一个浮在页面上层的元素。当你用键盘按下
Tab键时，浏览器的默认行为是按照文档流的顺序来移动焦点。如果模态框的HTML结构只是简单地叠在页面上，那么当焦点移动到模态框的最后一个可聚焦元素之后，它就会继续移动到模态框“下方”的页面元素上。这就是焦点“逃逸”了。
这种“逃逸”对依赖键盘操作的用户来说简直是噩梦。想象一下，一个用户用
Tab键试图在一个表单模态框里填写信息，结果填到一半，焦点突然跳到了模态框背后的导航栏或者页脚，他根本不知道发生了什么，也无法再回到模态框继续操作。对于屏幕阅读器用户，情况更糟，他们可能根本无法感知到模态框已经打开，或者即使感知到了，也无法正常地在模态框内部进行导航，因为屏幕阅读器会错误地将焦点导向背景内容。
这直接违反了Web内容可访问性指南（WCAG）的一些核心原则，比如2.4.3焦点顺序（Focus Order）和2.4.7焦点可见（Focus Visible）。如果焦点无法被正确地管理和限制，用户就无法理解当前界面的状态，也无法完成预期的任务，最终导致用户体验的严重下降，甚至完全无法使用你的应用。
如何在模态框内部有效地管理焦点循环？
这部分是技术实现的核心。我通常会这样做：当模态框打开时，你需要动态地获取模态框内部所有可聚焦的元素。这些元素通常包括
<a>标签（有
href属性）、
<button>、
<input>、
<textarea>、
<select>，以及任何设置了
tabindex属性的元素。一个常用的CSS选择器组合是
a[href], button, input, textarea, select, [tabindex]:not([tabindex="-1"])。
拿到这些元素后，你就有了它们的集合。然后，你需要给模态框本身（或者它的一个父容器）添加一个
keydown事件监听器。在这个监听器里，我们主要关注
Tab键的按下事件。
// 假设 modalElement 是你的模态框 DOM 元素
modalElement.addEventListener('keydown', function(event) {
if (event.key === 'Tab') {
const focusableElements = Array.from(
modalElement.querySelectorAll('a[href], button, input, textarea, select, [tabindex]:not([tabindex="-1"])')
);
// 如果没有可聚焦元素，直接返回
if (focusableElements.length === 0) return;
const firstFocusableElement = focusableElements[0];
const lastFocusableElement = focusableElements[focusableElements.length - 1];
if (event.shiftKey) { // Shift + Tab (反向)
if (document.activeElement === firstFocusableElement) {
lastFocusableElement.focus();
event.preventDefault();
}
} else { // Tab (正向)
if (document.activeElement === lastFocusableElement) {
firstFocusableElement.focus();
event.preventDefault();
}
}
}
});这段代码的核心逻辑是：当用户按下
Tab键（
event.key === 'Tab'）时，我们检查
event.shiftKey来判断是正向还是反向导航。如果是
Shift + Tab并且当前焦点在第一个可聚焦元素上，我们就把焦点强制移到最后一个元素。反之，如果是
Tab并且当前焦点在最后一个可聚焦元素上，就移到第一个。
event.preventDefault()至关重要，它阻止了浏览器执行默认的
Tab键行为，从而实现了焦点在模态框内部的循环。
实际项目中，你可能还需要处理一些边缘情况，比如模态框内部没有可聚焦元素，或者动态添加/移除元素时需要重新计算
focusableElements列表。但上述逻辑是构建焦点循环的基础。
模态框关闭后，焦点应该如何安全地返回到原始位置？
这个问题听起来简单，但处理不好会极大地影响用户体验的连贯性。我的做法是，在模态框被激活（也就是打开）之前，记录下当前拥有焦点的那个元素。这通常就是用户点击打开模态框的那个按钮或者链接。你可以简单地用一个变量来存储
document.activeElement的引用。
let elementBeforeModalOpened = null;
function openModal() {
elementBeforeModalOpened = document.activeElement; // 记录当前焦点
// ... 打开模态框的逻辑
// 确保将焦点设置到模态框内的第一个可聚焦元素
const firstFocusableInModal = modalElement.querySelector('button, input, a[href], [tabindex]:not([tabindex="-1"])');
if ( 
