当仅当前活动的选项卡包含在 DOM 中时，选项卡容器的正确角色是什么？答案

【问题标题】：What is the correct role for a tab container when only the currently active tab is included in the DOM?当仅当前活动的选项卡包含在 DOM 中时，选项卡容器的正确角色是什么？
【发布时间】：2022-08-06 23:54:42
【问题描述】：

根据WAI guidelines for tabs，应该在每个包含标签内容的元素上设置角色tabpanel，然后将其触发标签的aria-controls值设置为容器的ID。

这适用于所有选项卡都包含在 DOM 中并且仅使用 CSS 隐藏的情况。
但是，在我的应用程序中，我只使用 JavaScript 将当前选择的选项卡的内容添加到 DOM。这意味着 DOM 中只有一个 tabpanel，所有其他选项卡的 aria-controls 值将设置为不存在的 ID，我怀疑这将是一个好习惯。

所以现在我想知道：我应该完全设置 tabpanel 角色，还是应该只从容器上的选项卡中设置aria-controls，最终在添加aria-live=\"polite\" 和aria-relevant=\"all\" 时显示当前选择的任何选项卡还是这种情况有更好的做法？

我想知道为什么你不能已经包含容器及其 ID，而只是将其内容添加到 DOM，而不是容器本身？您是否通过 Fetch 检索内容？
包括处于空状态的容器也是我的一个想法。内容是使用带有 if..else if.. 等的 React 有条件地渲染的，因此容器已经存在会导致在每次渲染时运行更多的比较操作。这些操作在计算上并不昂贵，但不这样做可能是过早的优化@Andy
我认为问题的标题不适合问题，这完全是关于 aria-controls 属性。你怎么看？
好吧，问题还在于将 tabpanel 角色放置在哪里（如果有的话），而不仅仅是 aria-controls

标签： javascript html tabs accessibility

【解决方案1】：

可以省略aria-control 属性，平板电脑应该放在tabpanel 之前。

一致性

来自ARIA specification on role tabpanel：

作者应该通过使用选项卡上的 aria-controls 属性来引用选项卡面板，或者通过使用选项卡面板上的 aria-labelledby 属性来引用选项卡，将 tabpanel 元素与其选项卡相关联。

因此，您可以跳过aria-controls 部分并且仍然符合要求。

实际影响

由于大多数屏幕阅读器现在不会对aria-controls 进行任何处理，因此最佳做法是简单地将tablist 和tabpanel 放在一起，中间不包含任何内容。

同样来自规范：

tablist 元素通常放置在一系列 tabpanel 元素附近，通常位于其前面。有关实现选项卡集设计模式的详细信息，请参阅 WAI-ARIA 创作实践。

这样用户就知道在更改选项卡后继续阅读，并从选项卡面板返回以更改选项卡。在我阅读的大多数文章中，强烈建议这样做。

当然，我们不应该仅仅因为还没有实现就跳过指示语义（例如，就像大多数开发人员对 inputmode 所做的那样）。但如果它对您的情况造成问题，您可以省略 aria-controls 属性。

【讨论】：

不管大多数屏幕阅读器是否对aria-controls 做出任何贡献，它都受到 JAWS 的支持，它的用户群比其他任何东西都大。我不同意完全省略 aria-controls 是有意义的观点，因为它并非在所有地方都受支持。包括它为某些用户提供了额外的支持，并且不需要任何费用。 a11ysupport.io/tests/tech__aria__aria-controls
“Aria-Controls 是大便”-heydonworks.com/article/aria-controls-is-poop。诚然，这篇文章已有 6 年历史，但仍有一定的效力。它谈到了 JAWS，并且与 @Josh 所说的不谋而合有些支持它。没有其他人支持它使用它并没有真正让你受益。从语义上讲，它是正确的，我通常支持良好的语义，但我喜欢在不编写不会增加任何价值的代码之间取得平衡。
我将理由改写为不那么令人鼓舞（；