具有不可选项元素的 VoiceOver 转子

Question

我刚刚意识到 VoiceOver 的转子并不那么实用。当我用它来导航时，例如。到一个特定的标题，我希望它也能将本机焦点移到那里，这样当我向前滑动时，我会从标题的正下方开始。

然而，只有当我在转子中选择的元素具有隐式或显式 tabindex 时，这才有效。如果没有，焦点不会移动并停留在之前的位置。我的问题是：

• 这是设计使然，这还是一个问题吗？
• 对于我们开发人员来说，让屏幕阅读器用户尽可能流畅的最佳技术是什么。

Answer 1

这当然是一件有趣的事情。这不是 NVDA 和 JAWS 在 Windows 上的行为方式，它们都将键盘焦点与屏幕阅读器标题导航功能一起移动。但您观察到的是 iOS 上 VoiceOver 的行为，它将键盘焦点与 VoiceOver 的虚拟光标分开。 macOS 上的 VoiceOver 也表现出这种行为，只不过每当使用标题导航时，它似乎都会将键盘焦点重置到网页内容的顶部，这对我来说似乎是一个错误。

在iOS应用程序中，Tab将继续执行循环容器的键盘导航行为。在网页中，使用了预期的类似网页的 Tab 导航行为，并且键盘焦点与 VoiceOver 的虚拟光标分开。由于 Rotor 导航是 VoiceOver 功能，因此浏览器不会移动键盘焦点并不奇怪，因为如果不使用

tabindex

属性，目标元素不会被视为可聚焦元素。这就是某些跳过链接实现失败的原因：跳过链接目标通常不可聚焦。也就是说，这不是其他屏幕阅读器软件的工作原理。