tabindex 属性的核心作用是控制元素的键盘聚焦行为和导航顺序。1. tabindex="-1" 使元素可通过 javascript 聚焦但不参与 tab 导航，适用于临时引导焦点的场景；2. tabindex="0" 使元素按 dom 自然顺序参与 tab 导航，推荐用于可交互的自定义元素；3. tabindex 为正整数时会强制优先聚焦，破坏自然顺序，易导致用户体验混乱和维护困难，应避免使用。确保无障碍的关键是优先使用语义化标签，结合 tabindex="0" 和 aria 属性实现可访问性，通过 javascript 动态管理焦点（如模态框打开时聚焦内部元素），并始终保持 dom 结构与导航逻辑一致，以提供直观、可维护的键盘导航体验。
tabindex 属性的核心作用在于控制 HTML 元素是否能被键盘聚焦，以及在键盘导航（通常是按 Tab 键）时，这些元素被聚焦的顺序。简单来说，它决定了你的用户能不能用键盘“点到”某个东西，以及这个“点”的路径是怎样的。
解决方案
tabindex 属性主要有三种值，每种都有其独特的用途，但用起来得有点讲究，否则一不小心就会把键盘导航搞得一团糟。
-
tabindex="-1": 这个值意味着元素可以被 JavaScript 聚焦（例如通过element.focus()方法），但不能通过键盘的 Tab 键直接聚焦。这在很多场景下非常有用，比如当你想在用户操作后，把焦点移到一个错误信息或者一个模态框的关闭按钮上，但又不希望这个元素在常规的 Tab 顺序中出现。我个人觉得，这是最容易被忽视但又非常实用的一个值，尤其是在做复杂交互时，能有效引导用户焦点。
<div tabindex="-1" id="errorMessage" role="alert"> 请填写所有必填项。 </div> <script> // 当表单提交失败时 document.getElementById('errorMessage').focus(); </script> -
tabindex="0": 任何元素设置了tabindex="0"之后，都可以通过 Tab 键被聚焦，并且它会按照元素在文档流中的自然顺序（也就是它们在 HTML 代码中出现的顺序）参与到 Tab 导航中。这是最安全、最推荐的做法，当你需要让一个本身不可聚焦的元素（比如一个div或span）变得可聚焦时，就用它。它不会打乱你页面的默认 Tab 顺序，这很重要，因为用户通常会期望按照视觉顺序或逻辑顺序来导航。<div tabindex="0" role="button" aria-label="点击这里显示更多信息"> 更多信息 </div> -
tabindex="1" 或任何大于 0 的正整数: 这是一个需要谨慎使用的值。当元素设置了tabindex为正整数时，它们会脱离文档流的自然顺序，按照tabindex值从小到大的顺序优先被聚焦。所有tabindex为正整数的元素会被优先遍历，然后才是那些tabindex="0"的元素，最后才是那些默认可聚焦的元素（比如<a></a>标签、表单控件等）。我见过太多次，开发者为了所谓的“方便”，给元素乱设tabindex正整数，结果整个页面的 Tab 顺序变得毫无逻辑，用户体验灾难。除非你真的对 Tab 顺序有非常特殊且不可替代的需求（这种需求通常是极少数），否则强烈建议避免使用正整数。它会让你未来的维护工作变得异常痛苦，因为一旦页面结构调整，你可能需要重新审视所有这些自定义的tabindex。
<!-- 这是一个不推荐的示例，但为了说明其行为 --> <button tabindex="2">提交</button> <input type="text" tabindex="1" placeholder="用户名"> <a href="#" tabindex="3">帮助</a> <!-- 这里的Tab顺序会是：用户名 -> 提交 -> 帮助 -->
如何使用tabindex确保无障碍键盘导航？
要确保无障碍键盘导航，tabindex 并不是万能药，它更像是一个辅助工具。核心在于尊重和利用好 HTML 语义化。大部分可交互元素，比如链接（<a></a>）、按钮（<button></button>）、表单控件（<input>, <select></select>, <textarea></textarea>），它们天生就具备键盘可聚焦性，并且会按照它们在 DOM 中的自然顺序进行 Tab 导航。这是最符合用户直觉的。
如果你的自定义组件（比如用 div 或 span 模拟的按钮或菜单项）需要被键盘聚焦，那么给它们设置 tabindex="0" 是最恰当的方式。同时，别忘了添加适当的 ARIA 属性（如 role="button"、aria-label、aria-expanded 等），这样屏幕阅读器才能正确地理解这些元素的角色和状态，为视障用户提供必要的信息。
一个常见的陷阱是，开发者为了视觉效果，会用 div 来代替 button，然后只给 div 加个 tabindex="0"。这解决了聚焦问题，但丢失了按钮的语义。用户可能无法通过空格键或回车键触发“按钮”行为，因为 div 默认不响应这些按键。所以，你还需要额外用 JavaScript 监听键盘事件，来模拟 button 的行为。这无疑增加了代码的复杂性和出错的风险。我的经验是，能用语义化标签就尽量用，别给自己挖坑。
tabindex与JavaScript交互：动态控制焦点
tabindex 与 JavaScript 的结合，主要体现在动态地管理页面焦点。最常见的操作是使用 element.focus() 方法。当用户执行某个操作（例如打开一个模态框、提交表单后显示错误信息、或者切换到一个新的视图）时，你可能需要将键盘焦点移动到特定的元素上，以引导用户的注意力或方便他们继续操作。
例如，一个模态框弹出时，你通常希望焦点自动跳到模态框内的第一个可交互元素（比如一个输入框或关闭按钮），而不是留在模态框后面的页面上。这时，你可以在模态框显示后，立即调用目标元素的 focus() 方法。
function openModal() {
const modal = document.getElementById('myModal');
modal.style.display = 'block';
// 确保模态框本身可聚焦，或者聚焦模态框内的第一个可交互元素
// 如果模态框本身要接收焦点，可能需要给它一个 tabindex="-1"
modal.focus(); // 假设模态框有 tabindex="-1"
// 或者聚焦模态框内的某个按钮
document.getElementById('closeModalButton').focus();
}
function closeModal() {
const modal = document.getElementById('myModal');
modal.style.display = 'none';
// 关闭模态框后，可能需要将焦点返回到触发模态框的元素，或者其他逻辑位置
document.getElementById('openModalButton').focus();
}你也可以通过 JavaScript 动态地修改元素的 tabindex 属性。比如，你有一个复杂的导航菜单，在某些状态下，你可能希望某些菜单项暂时不可通过 Tab 键聚焦（例如，它们是禁用状态或者需要先选择父级）。这时，你可以将它们的 tabindex 设置为 -1。当条件满足时，再将其改回 0。这种动态调整在构建复杂的单页应用（SPA）时会比较常见，但要小心处理，避免在用户不知情的情况下突然改变导航行为。
为什么自定义tabindex顺序通常不是最佳实践？
正如前面提到的，给 tabindex 设置正整数来强制改变元素的 Tab 顺序，几乎总是一个糟糕的主意。我见过太多项目因此陷入维护的泥潭。
首先，它违反了用户对 Tab 导航的直觉。用户通常期望 Tab 键能按照元素在屏幕上的视觉顺序或者在 HTML 代码中的逻辑顺序进行移动。一旦你用 tabindex 正整数打乱了这个顺序，用户会感到困惑和沮丧，因为他们的预期被打破了。这种不一致性极大地损害了可用性，尤其是对于那些完全依赖键盘导航的用户来说，简直是噩梦。
其次，它极大地增加了代码的维护成本。设想一下，你的页面结构稍微调整了一下，比如某个元素被移动了位置，或者添加了一个新的元素。如果你的 Tab 顺序是依赖于 tabindex 的具体数值来精确控制的，那么你可能需要重新评估和调整所有相关元素的 tabindex 值。这就像玩一个高难度的拼图游戏，任何一个改动都可能导致整个序列崩溃。相比之下，如果你的 Tab 顺序是基于自然的 DOM 顺序，那么大多数结构调整都不会影响 Tab 键的逻辑流。
最后，它也容易引入难以发现的 Bug。当多个开发者在同一个项目上工作时，如果每个人都随意使用 tabindex 正整数，那么最终的 Tab 顺序可能会变得非常混乱和不可预测。调试这种问题，寻找是哪个 tabindex 值导致了顺序错误，是非常耗时且令人头疼的。所以，除非有极其特殊且无可替代的理由（这种理由几乎不存在），始终坚持使用 tabindex="0" 或 -1，并让浏览器处理其余的默认 Tab 顺序，这样你的代码会更健壮，用户体验也会更好。
