tabindex调节Tab键顺序_HTML键盘导航访问优化

tabindex 的核心作用是控制元素能否被 Tab 键聚焦及是否支持脚本聚焦，而非微调顺序；tabindex="0" 使非表单元素按 DOM 顺序进入 Tab 流，需配合 role 和键盘事件；tabindex="-1" 仅允许脚本聚焦；严禁使用正数 tabindex，以免破坏可访问性。

tabindex 不是用来“微调” Tab 顺序的工具，而是决定一个元素“能不能被 Tab 到”以及“是否该由脚本控制聚焦”的开关。滥用正数 tabindex 会破坏键盘导航的可预测性，尤其在组件复用或动态渲染场景下，几乎必然导致焦点跳转混乱。

tabindex="0" 是让非表单元素支持键盘导航的正确起点

div、span、article 等默认不参与 Tab 流，加 tabindex="0" 才能让它按 DOM 顺序自然进入 Tab 键循环。这不是“增强功能”，而是补足语义缺失——比如一个自定义 <div role="button">，没 tabindex="0" 就等于对键盘用户不可见。

• 只对有明确交互意图的容器使用，如可点击卡片、折叠面板标题、标签页按钮
• 必须配套实现 Enter 和 Space 键响应，否则键盘用户点不动
• role="button" 不自动带来聚焦能力，tabindex="0" 和 role 要成对出现
• 避免给纯装饰性元素（如图标 <span class="icon">）加 tabindex="0"，这会让屏幕阅读器多读一遍无意义内容

tabindex="-1" 是脚本聚焦的唯一安全通道

tabindex="-1" 的作用很窄：禁止 Tab 键到达，但允许 JavaScript 调用 .focus()。这是模态框、展开面板、快捷跳转等场景的刚需。

• 模态框打开后，立即对第一个可操作元素（如确认按钮）调用 .focus()，它必须已设 tabindex="-1"
• Accordion 展开后，焦点应移至其内部首个可交互子项，不是父容器本身
• 用 aria-hidden="true" 隐藏的区域，仍需显式设 tabindex="-1"，否则可能意外被 Tab 到
• 仅靠 opacity: 0 或 position: absolute; left: -9999px 隐藏的元素，仍会出现在 Tab 流中，必须加 tabindex="-1" 或现代 inert 属性

绝对不要用正数 tabindex（如 tabindex="1"）

浏览器默认按 HTML 源码顺序进行 Tab 导航。强行插入 tabindex="1"、tabindex="2" 会打乱这个顺序，造成焦点跳跃不可预测——尤其是当 DOM 动态更新、组件被多次挂载时，Tab 流会彻底失控。

立即学习“前端免费学习笔记（深入）”；

• 导航栏在源码顶部，就让它第一个被 Tab 到；主内容区紧随其后，别因视觉权重高就设 tabindex="1"
• 侧边栏、页脚等结构性次要区域，天然应在 Tab 流靠后位置，保持源码顺序就是最佳实践
• 正数 tabindex 在 SSR + hydration 场景下极易与服务端生成的顺序冲突，引发焦点错位
• 屏幕阅读器用户依赖文档流理解页面结构，人为打乱顺序等于剥夺他们的上下文感知能力

禁用/隐藏状态下的 tabindex 处理最容易出错

很多 bug 出现在“以为设了 tabindex 就万事大吉”，却忽略了元素实际是否可用、是否可见。

• <button disabled> 自动脱离 Tab 流，无需额外设置 tabindex
• display: none 或 visibility: hidden 的元素，即使有 tabindex="0" 也不会被 Tab 到
• aria-hidden="true" 不影响 tabindex 行为，若同时存在，必须显式设 tabindex="-1" 或移除
• 用 inert 属性（Chrome 105+、Firefox 111+ 支持）比手动管理 tabindex 更可靠，它会递归禁用整个子树的焦点和交互

真正难的不是写对那行 tabindex="0"，而是在组件生命周期中持续维护焦点逻辑：展开时聚焦哪、关闭后回哪、错误时跳哪、移动端虚拟键盘弹出时如何稳住焦点——这些细节一旦松动，键盘用户的体验就断在了最基础的一环。