roving tabindex是一种键盘导航模式，要求复合组件内同一时刻仅一个子元素tabindex="0"、其余为"-1"，以实现Tab键进出组件、方向键内部漫游；若全设"0"会破坏语义和ARIA规范。
roving tabindex 是什么，为什么不能直接写 tabindex="0" 给所有元素
roving tabindex 不是 HTML 原生功能，而是一种键盘导航模式（尤其用于复合组件如 RadioGroup、TabList、Menu），它的核心规则是：同一时刻，组件内**只有一个可聚焦子元素拥有 tabindex="0"**，其余子元素必须是 tabindex="-1"。这样既保证 Tab 键能「进出」整个组件（靠容器或首个子项的 tabindex="0"），又让方向键（→/←/↑/↓）能在内部「漫游」焦点而不跳出组件。
如果给所有子项都设 tabindex="0"，Tab 键会逐个跳过每个子项，破坏组件语义，也违背 WAI-ARIA 实践指南（例如 role="radiogroup" 要求仅一个 radio 可被 Tab 到）。
手动实现 roving tabindex 的关键三步
以一个 div 包裹的按钮组为例（模拟 TabList）：
- 初始时，只给第一个子元素设置
tabindex="0"，其余为tabindex="-1" - 监听
keydown事件（在容器上捕获），识别方向键（如ArrowRight、ArrowDown） - 在事件处理中：
- 调用
event.preventDefault()阻止默认滚动行为 - 计算下一个应聚焦的索引（循环取模）
- 将当前聚焦项的
tabindex改为-1，目标项改为0 - 调用
target.focus()
- 调用
注意：不要依赖 document.activeElement 判断「当前项」——它可能不是你期望的子项（比如焦点在输入框里）。更可靠的方式是维护一个 currentIndex 状态，或用 element.matches(':focus-within') 辅助判断容器内焦点位置。
立即学习“前端免费学习笔记（深入）”；
roving tabindex 和 aria-activedescendant 的区别在哪
两者都用于控制焦点表现，但机制完全不同：
-
roving tabindex：真实移动 DOM 焦点，每个切换都触发focus事件，浏览器地址栏显示焦点框，完全符合键盘用户预期 -
aria-activedescendant：焦点始终保留在容器上（tabindex="0"），仅通过属性声明「逻辑上活跃的子项」；需手动管理aria-selected、视觉高亮等，且不触发子项的focus事件 —— 这对需要响应focus样式或生命周期的子组件（如自定义Button）很不友好
简单说：要做真正「可聚焦、可交互、样式联动」的漫游，选 roving tabindex；若组件极度复杂（如虚拟滚动列表），且你愿意承担状态同步成本，再考虑 aria-activedescendant。
容易被忽略的边界情况
roving tabindex 表面简单，实际容易在这些地方出问题：
- 容器本身没设
tabindex="0"或没加role（如role="tablist"），导致屏幕阅读器无法识别为导航单元 - 方向键逻辑没处理「循环」（比如最后一个按 → 应跳回第一个），用户卡死在末尾
- 没监听
Home/End键，丧失快速跳转能力 - 子元素动态增删后，没重置
tabindex状态，导致多个0或全-1 - 在移动端 Safari 或旧版 Edge 中，
focus()可能静默失败 —— 建议加setTimeout(() => target.focus(), 0)兜底
真正的难点不在「怎么设 tabindex」，而在「什么时候改、改谁、改完是否真聚焦了、屏幕阅读器是否同步感知」—— 每一步都要验证，不能只看视觉反馈。
