Mac启用Full Keyboard Access前后的键盘导航差异及问题咨询

是的，这确实是Mac启用**全键盘访问（Full Keyboard Access）**导致的行为差异。

问题原因 #

当开启全键盘访问后，macOS会接管Tab键的核心导航逻辑——此时Tab键会被系统用来在所有可交互元素（包括系统UI组件）之间跳转，而非完全交由网页的JavaScript事件处理。这种系统级的事件拦截会导致你的keydown监听器无法捕获到Tab键事件，自然无法触发焦点回跳div1的逻辑，最终出现导航混乱的现象。

解决方案 #

1. 强化事件拦截逻辑

尝试在监听Tab键时同时阻止事件冒泡，减少系统优先处理的概率：

div5.addEventListener('keydown', (evt) => {
    if (evt.key === 'Tab') {
        console.log("keydown callback");
        evt.preventDefault();
        evt.stopPropagation();
        div1.focus();
    }
});

2. 改用focusout事件实现循环

绕开系统对Tab键的拦截，监听元素失去焦点的事件来强制跳转焦点：

div5.addEventListener('focusout', (evt) => {
    console.log("focusout callback");
    // 微任务延迟确保系统导航逻辑执行完毕
    setTimeout(() => {
        div1.focus();
    }, 0);
});

3. 自定义tabindex控制导航顺序

通过设置不同的tabindex数值，确保5个div内部的导航顺序符合预期（全键盘访问模式下仍可能跳出到系统元素，但内部顺序可控）：

<div tabindex="1" id="1">Hello 1</div>
<div tabindex="2" id="2">Hello 2</div>
<div tabindex="3" id="3">Hello 3</div>
<div tabindex="4" id="4">Hello 4</div>
<div tabindex="5" id="5">Hello 5</div>

补充说明 #

全键盘访问模式下，macOS的键盘事件优先级高于网页脚本，部分按键会被系统劫持，这是系统级的行为限制。上述方案属于适配手段，无法完全消除系统行为带来的影响，建议结合实际场景选择最合适的实现方式。

内容的提问来源于stack exchange，提问作者R.S.S.H KRISHNA