tabindex合法值仅有-1、0和正整数：-1使元素不可Tab聚焦但可JS聚焦；0按DOM顺序加入焦点流；正整数强制排序但易破坏可访问性，WCAG不推荐使用。
tabindex 属性值有哪些合法取值
tabindex 不是随便填数字就行，浏览器只认三种值：-1、0 和正整数（如 1、2）。填 999 或负数（除 -1 外）会被忽略，等同于没设。
-
tabindex="-1"：元素不可通过 Tab 键进入，但可通过 JavaScript 调用.focus()主动聚焦 —— 常用于模态框关闭按钮或临时可聚焦的提示元素 -
tabindex="0"：元素按 DOM 顺序加入默认焦点流，不改变原有 tab 序，但能让原本不可聚焦的元素（比如<div>）支持键盘聚焦 -
tabindex="n"（n > 0）：强制插入焦点序列，数值越小越靠前；但多个正数会打乱自然 DOM 顺序，且不同浏览器处理细节有差异，容易出错
为什么给 div 设置 tabindex="0" 后仍无法聚焦
常见原因是 CSS 阻断了焦点能力：如果元素设置了 visibility: hidden、display: none，或者父级有 pointer-events: none，即使 tabindex="0" 也无效。另外，contenteditable="false" 会覆盖 tabindex 行为。
- 检查 computed style 中
visibility和display是否为可见状态 - 确保元素没有被
outline: none彻底隐藏焦点样式（这不影响聚焦能力，但会让用户看不到焦点位置） - 避免在
<button>或<a href>上重复加tabindex="0"—— 它们本就可聚焦，加了反而可能干扰默认行为
tabindex 正整数排序的实际表现
写 tabindex="2" 并不意味着它一定在 tabindex="1" 之后聚焦 —— 浏览器先收集所有正整数 tabindex 元素，按数值升序排列；再拼接所有 tabindex="0" 元素（保持 DOM 顺序）；最后才处理自然可聚焦元素（如 <input>）。这意味着：tabindex="100" 的元素会比所有 tabindex="0" 元素更早获得焦点。
- 正整数 tabindex 容易导致 tab 流跳转突兀，用户难以预测，WCAG 不推荐使用
- 若必须控制顺序，优先用 DOM 顺序 +
tabindex="0"，而不是硬编码正数 - React/Vue 等框架中动态渲染时，tabindex 正数可能因重排失效，
tabindex="-1"+ 手动 focus 更可靠
无障碍场景下 tabindex 的关键陷阱
屏幕阅读器（如 NVDA、VoiceOver）依赖 tabindex 和语义 HTML 协同工作。单纯加 tabindex="0" 到一个 <div> 上，不会自动赋予其按钮或链接的语义，AT（辅助技术）仍会读作“div”，用户不知道该做什么。
立即学习“前端免费学习笔记（深入）”；
- 可交互元素必须配合适当的 ARIA 属性，例如：
role="button"+aria-label -
tabindex="-1"常用于通过 JS 控制的焦点管理（如模态框首次打开时聚焦第一个表单控件），但需配合aria-modal="true"和焦点囚禁逻辑 - 移除
tabindex比设置错误值更安全 —— 默认可聚焦元素（<a>、<button>、<input>）已有合理焦点顺序和语义
真正难的不是写对 tabindex，而是判断某个元素是否「应该」出现在焦点流里，以及它被聚焦时用户能否理解上下文。很多 tabindex 问题，根源不在属性本身，而在交互意图没被正确表达。
