我从辅助功能专家那里得到反馈，称我在地标区域上使用选项卡索引会让屏幕阅读器用户感到恼火。我添加了选项卡索引，以便用户可以使用跳过链接来访问导航或主要内容。我被告知，非交互式元素出现在页面的选项卡顺序中是令人沮丧的。我现在对此进行了更改，以便跳过链接将您发送到这些区域内的第一个可聚焦元素，而这些区域本身不可聚焦。我已经为我的导航地标、主要地标以及某些不是地标但包括选项卡列表、选项卡等的区域实现了此功能。
但是，我看到许多 ARIA 设计模式，其中具有“region”角色的 div 具有选项卡索引，即使它们不是交互式的。例如，选项卡模式和菜单模式具有带有选项卡索引的区域。 https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation/ https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
咏叹调标签模式说
为了让屏幕阅读器用户能够轻松地从选项卡导航到 活动选项卡面板中内容的开头，建议 选项卡集中的所有 tabpanel 元素都是可聚焦的（如果有） 集合中包含第一个元素的内容的面板 面板不可聚焦。
那么这是否意味着导航地标不应该有选项卡索引，因为它只包含可聚焦元素，但我的主要内容地标应该有一个选项卡索引，因为它可能在任何按钮等之前包含标题？ 这意味着从跳过链接导航到每个地标的体验并不一致。
没错，它们不应该出现在页面的 Tab 键顺序中。正如交互式组件所述：
一般规则是不允许用户聚焦非交互式元素，因为期望每个可聚焦元素实际上会做某事
但你也是对的，将焦点集中在刚刚更改内容的目标元素上是一个很好的做法。由于焦点始终需要可见，并且跳过链接可能会导致您在页面中走得很远，因此将焦点放在视口中会很有帮助。
我认为某些浏览器甚至会从跳过链接而不是目标继续按 Tab 键顺序。至少一年前是这样。
细微差别是您需要使用负选项卡索引。这允许以编程方式设置焦点，但不会在选项卡顺序中包含该元素。
<section id="jumphere" tabindex="-1" aria-labelledby="jumphere-title">
<h2 id="jumphere-title">…
对于诸如 tabs 之类的模式，最佳做法是面板紧跟在选项卡后面。这样，就不需要焦点控制。通常可以以任何方式完成，并且对于面板是否应该通过键盘进行聚焦似乎有不同的意见。 APG 选项卡是，包容性组件的选项卡 和 UK.GOV 的选项卡 不是。
跳过链接可能与这些模式不同，因为它们的目标彼此相距很远，并且距跳过链接也很远。当用 Tab 键浏览页面时，跳过链接很快就会被忘记。
实际用户的想法只能通过实际键盘和屏幕阅读器用户的可用性测试来确定。