如何在HTML中使用 tabindex 属性控制键盘 Tab 键的聚焦顺序

tabindex为负数（如-1）使元素可被脚本聚焦但不进入Tab导航流；常用于模态框、下拉容器等需程序化接管焦点的非原生可聚焦元素，不可替代disabled或aria-disabled。

tabindex 为负数时会发生什么

负值（如 tabindex="-1"）让元素可被脚本聚焦（element.focus()），但不会进入自然 Tab 流。这常用于模态框中临时聚焦某个按钮，或隐藏导航链接又保留程序化访问能力。

常见错误是误以为 tabindex="-1" 能“禁用”键盘访问——它只是跳过 Tab，不阻止 click 或 keydown；若需完全屏蔽，得配合 aria-disabled="true" 和样式 pointer-events: none。

• 只写 tabindex="-1" 不等于禁用交互
• 屏幕阅读器仍可能读取该元素，除非加 aria-hidden="true"
• React/Vue 中动态设置 tabindex="-1" 后，记得在条件变化时同步更新，否则焦点行为会滞后

tabindex 大于 0 的顺序怎么算

正数 tabindex（如 tabindex="2"）会强制元素插入 Tab 流，且按数值升序排列；但所有正数元素都会排在默认可聚焦元素（如 <a href></a>、<button></button>）之后，无论它们在 DOM 中的位置如何。

这意味着：tabindex="1" 的 <div> 一定比 <code><button></button> 更晚获得焦点，哪怕 <button></button> 在它后面渲染。这种“重排序”极易破坏线性阅读逻辑，尤其对屏幕阅读器用户。

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

• 多个相同正数（如都设 tabindex="3"）时，按 DOM 顺序聚焦，不是随机
• tabindex="0" 是最安全的值：保持自然 DOM 顺序，同时让非表单元素可聚焦
• 避免使用 tabindex="99" 这类“最大值思维”，它无法保证最后聚焦，反而制造维护陷阱

哪些元素默认能被 Tab 键聚焦

原生可聚焦元素包括：<a href></a>、<button></button>、<input>、<select></select>、<textarea></textarea>、<iframe></iframe>。它们无需 tabindex 就参与 Tab 流。

而 <div>、<code><span></span>、<p></p> 等默认不可聚焦，加 tabindex="0" 才能进 Tab 流——但必须同步提供键盘操作支持（如 Enter 触发点击、Space 切换状态），否则违反 WCAG 2.1 键盘可访问原则。

• tabindex="0" + role="button" 是常见组合，但必须监听 keydown 处理 Enter/Space
• 用 contenteditable="true" 的 <div> 默认可聚焦，此时再设 <code>tabindex 可能冲突
• CSS 的 outline: none 会隐藏焦点指示，务必用 :focus-visible 替代，否则键盘用户无法感知当前焦点

移动端 Safari 和旧版 IE 的 tabindex 兼容细节

iOS Safari 对 tabindex 支持有限：默认只聚焦表单控件和链接；即使设了 tabindex="0"，<div> 在触摸模式下也不会被 Tab 导航到（除非开启“辅助功能 > 键盘 > 全键盘访问”）。IE11 则完全忽略负值 <code>tabindex 的脚本聚焦能力。

这意味着靠 tabindex 实现的键盘导航，在移动 Safari 上大概率失效；更可靠的方式是用 role="application" 配合手动管理焦点，或直接依赖原生可聚焦元素。

• 不要在 iOS Web App 中依赖 tabindex 构建核心导航流
• IE11 下 element.focus() 对 tabindex="-1" 元素无效，需降级为 tabindex="0" 再聚焦
• Vue/React 中用 ref 调用 focus() 前，先检查 element.tabIndex !== -1，避免 IE 报错
实际项目里最容易被忽略的，是把 tabindex 当成“开关”来用——它只是调节焦点入口的阀门，不解决交互语义、焦点样式、屏幕阅读器播报这些配套问题。一个 tabindex="0" 的 <div>，没配 <code>role、没处理键盘事件、没视觉焦点反馈，比不加还糟糕。