问题描述
WCAG 对功能的定义
可通过用户操作实现的过程和结果
遵循 WCAG 对“功能”的定义，似乎很直观，就像功能元素应该始终是键盘可聚焦一样，非功能元素不应该。 然而，在可访问性问题上，天真的直觉可能会产生误导。由于我在 W3C 网站上找不到任何明确的指导方针或失败标准，我在这里问：
使非功能性元素键盘可聚焦是否是一个好习惯？
如果有 W3C 或其他官方标准支持您的回答，请提及。
注意 1：请不要提供可滚动但非交互式元素作为示例 - 就我们而言，滚动是一种交互。
注意 2：有点相关，但不是问题 "Should text ever be focusable for accessibility? I'm specifically thinking about key-value pairs" 的重复，也有点类似于这个问题："Accesibility vs. read only inputs"，但这是在 2013 年提出的，并且它的单一答案在 IMO 中不够权威（我猜对于今天的可访问性约定来说是不正确的）。
解决方法
使非功能性元素键盘可聚焦是否是一个好习惯？
是的，但在极少数情况下。
哦，你想要更长的答案吗？ ?
标签面板是一个很好的例子（也是我能想到的唯一一个具体例子）tabindex="0" 何时有用。
在这种情况下，除了允许用户轻松导航到面板以便他们可以阅读其内容之外，它没有任何作用。
这在 W3 Example of manual tab activation page 中进行了演示和解释。
建议这样做的原因是它的功能类似于“跳过链接”。
所有标签都可以用方向键操作，但整个标签列表是一个制表位。
然后，当用户打开他们想要阅读的标签时，他们可以按 Tab 以跳转到内容，而不必读出其余的标签选项。
一些“蓬松”的例子
我唯一一次看到这种用法并且感觉正确的是在“实时聊天”应用程序中，当您可以Alt + Tab 浏览对话项时。这比使用标题、部分或其他方式让我们可以使键盘可导航（箭头键感觉不直观）更好。
最后一个想到的是数据表，有时您可能希望一个表获得焦点，以便用户可以通过箭头键导航。因此它获得焦点以激活组件并让人们知道它是通过键盘进行交互的。
我想到的人没有使用辅助技术，但在这种情况下由于行动不便而使用键盘。
然而，这只是推测，我自己从未实现过，如果我这样做了，那可能是因为突出显示的行会改变图形等（我相信你会认为这是交互式的！）
有任何官方指导吗？
关于官方指导，我怀疑你会找到一些具体的东西。显然 WCAG 2.4.3 - Focus Order 确实在这里起作用，因为向所有内容添加 tabindex="0" 不是“逻辑焦点顺序”，但它不会给您明确的答案，因为它必须允许自定义组件等。
恐怕这是一种“最佳实践”而不是规则场景。如果页面上的每个项目都有一个 tabindex="0"，您可能仍然会通过 WCAG，因为 WCAG 不关注用户体验，而是关注是否可以使用某些内容。然而，依赖辅助技术的人都不想使用带有一百个 tabindex="0" 的页面！
如果您采用焦点应该始终可见的原则，那么可能存在实现这一点的唯一方法是将非交互式元素置于焦点上的情况。跳过导航链接需要在导航标题后有一个目的地，但主区域中可能没有任何内容是可交互的。模态对话框在关闭时需要有一个焦点后继元素，但它的关闭可能会导致触发元素消失而不会留下其他元素，或者至少没有直观合理的后继元素，交互性。
另一种情况：用户操作可能会导致在视图的各个点插入信息性消息（提示、线索、注释等）。它们可能都在活动区域，但这并不容易找到它们。使它们可聚焦将允许用户按顺序浏览它们，确保不会遗漏任何一个并且不需要费力的搜索。
,我见过一些以这种方式实现的错误对话框，其中对话框上唯一的交互元素是 OK 按钮，他们决定在消息文本上设置 tabindex="0"。 这意味着他们可以在对话框打开时将焦点放在“确定”按钮上，以便更快地关闭，同时允许屏幕阅读器用户使用 Tab 键访问消息文本。在我们有 role="dialog" 之前，这可能更常见。总的来说，我会说使非交互式元素成为焦点应该是情境性的并且很少见。不要做任何会让用户感到困惑的事情。但如果它产生了更直观且更易于使用的东西，我会说去吧。