voiceover 的 rotor 在跳转到标题等非可聚焦元素时不会自动移动键盘焦点，导致 tab 导航无法从目标位置继续；本文解析该行为成因，并提供符合无障碍标准的修复方案。
voiceover 的 rotor 在跳转到标题等非可聚焦元素时不会自动移动键盘焦点，导致 tab 导航无法从目标位置继续；本文解析该行为成因，并提供符合无障碍标准的修复方案。
VoiceOver（尤其是 iOS 和 macOS 上的 Web 浏览场景）将「虚拟光标」（VoiceOver cursor）与「键盘焦点」（keyboard focus）视为两个独立系统：Rotor 导航仅移动虚拟光标，而 Tab 键始终遵循 HTML 焦点流——这意味着，若目标元素（如 <h2></h2>）未声明 tabindex，即使 Rotor 选中它，键盘焦点仍停留在上一个可聚焦元素，用户按 Tab 后将跳过该区域，破坏导航连续性。
这并非 bug，而是 Apple 对「语义导航」与「交互焦点」的明确分离设计。但对用户而言，体验割裂：NVDA/JAWS 在 Windows 上会同步移动焦点，而 VoiceOver 不会——这种不一致要求开发者主动弥合。
✅ 最佳实践：为关键语义锚点添加 tabindex="-1"
无需改变 DOM 结构或语义，只需确保所有 Rotor 常用目标（如标题、章节容器、自定义区域）具备程序化聚焦能力：
<!-- 推荐：保持语义，仅增强可聚焦性 --> <h2 id="introduction" tabindex="-1">引言</h2> <section id="features" tabindex="-1" aria-labelledby="features-heading"> <h3 id="features-heading">核心功能</h3> <!-- 内容 --> </section>
tabindex="-1" 的优势在于：
- ✅ 允许 JavaScript 调用
.focus()（如跳转后自动聚焦）； - ✅ 不影响自然 Tab 顺序（不会插入到默认焦点流中）；
- ✅ 完全保留
<h2></h2>等元素的语义角色（仍是 heading，非 button 或 link）； - ✅ 符合 WCAG 2.4.3（Focus Order）与 2.4.7（Focus Visible）隐含要求。
⚠️ 注意事项：
- 避免滥用
tabindex="0"：它会将非交互元素插入 Tab 序列，可能干扰键盘用户的线性浏览； - 若使用
scrollIntoView({ block: 'start', behavior: 'smooth' })，务必紧随其后调用.focus()，否则 VoiceOver 无法感知新焦点位置； - 对于动态加载内容，需在 DOM 插入后手动为新标题添加
tabindex="-1"并绑定聚焦逻辑； - 测试验证：开启 VoiceOver → 使用 Rotor 切换至 Heading → 按
Tab→ 确认焦点落在目标元素正下方（而非跳回顶部或跳过）。
总结来说，VoiceOver 的设计哲学是「虚拟光标优先」，但无障碍体验的终极目标是「用户意图一致」。作为开发者，我们不必等待平台变更，而应主动通过 tabindex="-1" + 显式聚焦，桥接虚拟导航与物理交互——这是当前最轻量、最可靠、最符合标准的解决方案。
