是的，tabindex="-1" 元素在 VoiceOver 中可被聚焦但不参与自然 Tab 顺序；能否实际访问取决于是否可见、是否有语义（如 role）、是否被显式聚焦（focus() 或交互模式）。
tabindex="-1" 元素在 VoiceOver 中是否可聚焦？
是的，
元素在 VoiceOver（macOS/iOS）中仍可被聚焦，但**不会出现在自然 Tab 顺序中**，也不通过连续按 Tab 键到达。它能否被 VoiceOver 用户实际访问，取决于三个关键条件：是否可见、是否有语义、是否被显式聚焦（例如 via
或 VoiceOver 的「交互模式」）。
VoiceOver 用户如何触达 tabindex="-1" 元素？
VoiceOver 不依赖
值决定朗读范围，而是基于 DOM 结构、语义角色和可访问性树。只要元素满足以下任一条件，VoiceOver 就可能朗读并允许聚焦：
有明确语义（如
、
），且未设
内容非空、未被
或
隐藏
被 JavaScript 主动调用
（例如模态框打开后聚焦关闭按钮）
用户手动进入「交互模式」（VO+Space），再用方向键移动到该元素
常见误判场景：为什么有时 VoiceOver “跳过”了 tabindex="-1" 元素？
不是
失效，而是它被其他更优先的可访问性问题掩盖了：
与
同时存在 → 屏幕阅读器直接忽略该元素（
优先级更高）
父容器设置了
但未限制焦点 → VoiceOver 可能跳转到页面顶部或其他默认焦点位置
元素初始不可见（如
+
），但未同步设置
→ 可访问性树中状态不一致
动态插入的元素未在插入后立即调用
，也未触发
→ VoiceOver 不感知变化
实操建议：确保 tabindex="-1" 在 VoiceOver 中可靠可用
别只靠
，要配合语义和时机控制：
给元素添加明确
和
（如
tabindex="-1"focus()tabindexrole="button"role="dialog"aria-hidden="true"display: nonevisibility: hidden.focus()tabindex="-1"aria-hidden="true"tabindex="-1"aria-hiddenaria-modal="true"opacity: 0pointer-events: nonearia-hiddenfocus()aria-livetabindex="-1"rolearia-label
）
模态框打开后，立刻执行
closeButton.focus()
，而非仅靠 HTML 属性
避免在
tabindex="-1"
元素上叠加
aria-hidden="true"
或隐藏样式
用 Safari + VoiceOver 测试真实路径：启用 VoiceOver → 按 VO+Shift+Down 进入“组”→ 用方向键遍历，确认能否停驻并触发操作
最易被忽略的一点：VoiceOver 的「自动聚焦」行为高度依赖上下文——比如表单提交后跳回顶部，往往不是
tabindex
的问题，而是缺少对新焦点位置的主动声明。别假设屏幕阅读器会“猜”你想聚焦哪，每次状态变更都要明确告诉它。