Yishan

Search

SearchSearch

选项卡

May 17, 2023, 14 min read

选项卡式界面可以堆叠信息，就像在一堆索引卡中一样。 选择一个选项卡会显示相应的卡片（选项卡面板）。

选项卡式界面中的选项卡通常水平排列，有时垂直排列。

常见选项卡

视频：选项卡的实际应用

Video description

On the page in the sas.com website, a tabbed interface shows different data visualisations.

  • The user tabs to the first tab in the tab list, which announces “Registerkarte” (German for tab)
  • The screen reader then announces the name of the tab (“Net Operating Income”) as well as the role (tab) and the state and the total number of tabs in the tablist.
  • The user uses the right arrow key → to focus the next tab.
  • The user hits enter ENTER to select the tab and show the corresponding tab panel.

不同类型的选项卡式界面

有两种类型的选项卡式界面：自动激活的选项卡和手动激活的选项卡。

当使用自动激活的选项卡式界面时，聚焦一个标签会立即显示相应的标签面板。而在手动激活的选项卡式界面上，用户必须选择焦点中的选项卡（通过按下空格键或回车键）才能显示相应的选项卡面板。

此外，有一个重要的区别。您可以根据 ARIA 创作实践构建选项卡式界面，使之在应用程序中表现得像选项卡小部件。在这种情况下，选项卡通过箭头键而不是 Tab 键获得焦点。或者，您可以选择将选项卡实现为链接（或按钮）列表，这些链接（或按钮）可以通过 Tab 键聚焦。后者仍然是当今网络上选项卡式界面更常见的键盘行为。

选项卡式界面的典型可用性问题

选项卡式界面对许多用户来说很困难。

意识到箭头键应该用于聚焦选项卡

当键盘用户遇到根据 ARIA Authoring Practices 1.1 构建的选项卡式界面时，默认情况下跳转到 tablist 会聚焦第一个选项卡（或之前最后选中的选项卡），然后可以通过箭头键 ← → 聚焦其他选项卡。然而，用户可能没有意识到他们需要切换到箭头键，尤其是当选项卡式界面看起来与传统选项卡式界面不同。为了解决这个可用性问题，有些网站作者会使每个选项卡都可以通过 Tab 键选择。

然而，这种实现方式也会带来问题，尤其是当选项卡面板中有可聚焦元素时。这些元素可能不是选项卡之后的下一个可聚焦元素。因此，在进入选项卡面板之前，您必须先浏览选项卡列表中的其他选项卡。可以通过比较 Heydon Pickering 的页面来更好地理解选项卡式界面的实现。

屏幕阅读器用户和选项卡面板

当屏幕阅读器遇到 tablist 元素（或者更确切地说，焦点移动到 tablist 元素内）时，它会进入表单/应用程序模式，在该模式下屏幕阅读器导航（使用箭头键/快捷键）是不可用。

这使得没有可聚焦元素的 tabpanel 元素更难被屏幕阅读器用户发现，因为他们必须在激活 tab 后手动强制屏幕阅读器退出表单/应用程序模式。

这就是为什么将 tabindex="0" 放在 tabpanel 元素上的想法已经浮出水面，并且在这个特定的上下文中可以接受（这并不理想，因为它代表一个可聚焦但没有交互属性的元素）。

不推荐使用 JavaScript 在相应选项卡获得焦点后立即将焦点发送到选项卡面板的解决方案。这就像在下拉列表中有一个 onchange 事件，自动将焦点发送到其他地方。假设用户想要激活的选项卡是 5 个选项卡列表中的最后一个。您不希望用户必须先按箭头键，然后按 shift-tab 键才能返回到选项卡列表，然后重复此操作四次才能到达所需的选项卡。

了解用于与选项卡式界面交互的屏幕阅读器说明

正如 Alastair Campbell 指出的那样，可用性测试表明许多非专业的屏幕阅读器用户不熟悉 ARIA 选项卡面板构造（因为符合规范的实现在已发布的 Web 内容中非常罕见）。

一些用户将制表符（带有 role=tab" 的元素）与制表符操作（使用制表键）混淆。

隐藏面板中可能缺少内容

如果选项卡式界面未根据 WAI ARIA 最佳实践正确标记，盲人用户可能无法意识到他们遇到的内容类型，并可能绕过当前隐藏面板中的内容。如果用户在使用旧版浏览器或旧版辅助技术的旧系统上工作，可能不会公开 tablist 和 tab 角色，也会出现同样的问题。

绕过可见的面板内容

另一个问题是屏幕阅读器用户可能会绕过可见面板的内容，尤其是在其中没有可聚焦元素的情况下。当他们通过箭头/阅读内容进入标签列表时，屏幕阅读器会切换到表单模式。要阅读面板内容，用户必须切换回阅读模式。

JAWS 宣布了一个跳转到面板的快捷方式，而 NVDA 和 VoiceOver 等其他屏幕阅读器则没有。因此，按 Tab 键会将用户带到面板之后的第一个交互式内容。这就是为什么一些作者建议使面板本身可聚焦的原因。

一种简单的方法是在面板上使用 tabindex="0" ，但许多人建议不要让非交互元素通过 Tab 键接收键盘焦点。另一种方法是在面板上使用 tabindex="-1" 并以编程方式将焦点移至它。 Heydon Pickering 的选项卡式界面建议使用向下箭头键将焦点移至面板。

线性阅读问题

在屏幕阅读器的浏览模式下，或使用自己的 CSS 从上到下线性阅读内容的用户，通常会首先看到一个部分中的选项卡，然后是下面单独部分中的面板内容。这可能会导致难以关联选项卡和相应的面板内容。在面板中实现为跳过链接和适当标题的选项卡可以缓解这个问题。

视频示例

在这个页面中，展示了多种用户实际使用网页时存在的问题

  1. 键盘使用：无法访问内容
  2. 键盘和屏幕阅读器使用：意外的键盘行为
  3. 屏幕阅读器的使用，认知问题：了解选项卡式界面的结构

选项卡式界面的可用性功能提示

根据 WAI-ARIA 创作实践构建的选项卡式界面

  • 显示自动或手动激活面板。考虑您的面板是应在用户遍历选项卡时自动显示，还是仅在手动激活选项卡后显示。
  • 使用适当的角色（ tablist 、 tab 、 tabpanel ）和属性，尤其是 aria-selected 来反映当前选项卡的状态。使用 aria-controls 指向相应面板的 id 也没有任何坏处，即使 aria-controls 目前支持不佳。
  • 在将 role="tab" 分配给列表元素内的链接时，在列表元素 ( li ) 上使用 role="presentation" 。这删除了列表语义，只有在将 ARIA 角色用于选项卡式界面时才会妨碍列表语义。
  • 实现键盘行为。用于遍历选项卡列表的左/右箭头导航。焦点应在列表中循环。如果您的选项卡是链接，请考虑为空格键包含一个 JavaScript 事件键处理程序，这样按空格键也会选择选项卡。
  • 在面板上，使用 aria-labelledby 属性来引用相应的选项卡。当屏幕阅读器用户进入面板时，选项卡名称将作为面板的标签读出，因此很明显接下来的面板内容属于该选项卡。
  • 使面板内容可聚焦。如果面板中没有可聚焦元素，或者第一个可聚焦元素之前有重要内容，请考虑将 tabindex="0" 放在面板上。另一种方法是使用向下箭头将焦点移至面板。当以用户必须按回车键激活选项卡的方式实现选项卡式界面时，脚本可以将焦点设置到相应面板的开头。
  • 给出指示。一些作者建议在获得焦点时使用在选项卡列表上方插入的可见提示，例如“使用箭头键选择选项卡”。此文本可以通过 aria-describedby 链接到标签列表。

选项卡式界面，其中选项卡可以被标记为

与 ARIA 选项卡不同，选项卡式界面基于（通常水平排列的）链接或按钮列表，以确保用户可以通过 Tab 键而不是箭头键来遍历选项卡。

  • 使用适当的 ARIA 角色（ tablist 、 tab 、 tabpanel ），即使键盘处理偏离规范。
  • 如果面板有交互式内容，请选择手动激活而不是自动激活。当您显示焦点面板（自动激活）时，您将无法直接在面板中输入交互式内容，除非您将每个面板直接放在其选项卡之后（按源代码顺序）。在这种情况下，您需要在到达下一个选项卡之前浏览所有交互式内容。
  • 在激活选项卡链接或按钮时，通过页内链接或脚本将焦点移动到面板到面板开头的内容元素。如果这是像标题这样的非交互式内容，当您在此元素上设置 tabindex="-1" 时，跨浏览器和辅助技术的支持会得到改进。
  • 在选项卡上设置一个属性以反映当前状态（即，传达相应面板当前是可见还是隐藏）。在链接上，您不能使用 aria-selected ，但您可以在已指定 role="tab" 的按钮或链接上使用它。

延展阅读

最佳实践

选项卡的优势与劣势，以及最佳应用

Backlinks

Graph View