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