在导航栏上使用“aria-expanded”是否有意义？

Question

_{在长达十年的中断之后，我再次涉足 Web 开发。对我来说，不断变化的标准似乎仍然令人困惑，这让我不清楚哪些浏览器支持什么以及最佳实践是什么。}

目前，我专注于使用new semantic elements of HTML5。我发现 ASP.NET Core 默认引导模板不使用导航栏的 <nav> 元素，因此正在研究如何正确应用它。

default navbar template in Bootstrap确实推荐使用<nav>。但是，我对应用于它的 aria-expanded 属性背后的目的感到困惑。在learning about the benefits it offers to screen readers 之后（指示导航栏是否折叠，在这种情况下，当屏幕尺寸较小时，即智能手机），我仍然对它是否应该存在感到困惑。 （还有whether or not aria-controls should be applied，它不在默认引导模板中。）

让我解释一下：

• 其中一些 aria 属性似乎在描述视觉行为。向盲人描述他们看不到的东西是否有意义？
• 正确应用<nav> 和<main> 语义元素后，屏幕阅读器是否已经掌握了快速跳过导航栏的所有必要信息（相当于为有视力的人隐藏它）？

将导航切换机制完全隐藏给看不见的人难道不是更好的选择吗？那么我的问题是，如何去做。可以隐藏按钮using role="presentation" and/or aria-hidden="true"吗？

Answer 1

使用您在https://getbootstrap.com/examples/navbar/ 引用的示例，它需要aria-expanded。

在较大的视口中，“下拉”菜单隐藏了所有子项。它们不仅在视觉上隐藏，而且对屏幕阅读器也隐藏。 aria-expanded 有助于为用户提供上下文，无论是否有更多可用的，并且还提供了一些关于后续制表位可能会将用户带到哪里的线索。

在狭窄的视口中，导航变成汉堡包，这仍然适用。加倍如此，因为它也适用于汉堡包本身。

这个上下文很重要，因为 aria-controls 支持是便便（引用 Heydon 的话）。

在某些情况下，菜单中的每个项目都可以通过选项卡获得，即使视觉上不存在。在那种情况下，aria-expanded 并不那么重要，但aria-controls 会更有价值。

另外，对于有视力的键盘用户，该菜单需要更好的 :focus 突出显示，以及菜单的 DOM 序列与狭窄视口中的徽标（这是我的看法）。

Answer 2

其中一些 aria 属性似乎在描述视觉行为。向盲人描述他们看不到的东西是否有意义？

这个问题应该是任何 ARIA 教程中最先出现的问题。

正确应用 <nav> 和 <main> 语义元素后，屏幕阅读器是否已经掌握了快速跳过导航栏的所有必要信息（相当于为有视力的人隐藏它）？

这是第二个。

编辑：当我读到这些问题时，我想“那个人已经明白了一切”。 ARIA 教程很少回答这些问题，因为它们与上下文相关，但提出这些问题必须是使用 ARIA 之前的第一步。 例如。图像轮播为盲人提供了非常不同的用户体验。将aria-controls 属性赋予“上一个”按钮并不会为基于视觉效果的系统提供更多智能。 ARIA 不是灵丹妙药。

---

ARIA 可以被视为一种神奇的药水，供那些想要使无法访问的东西变得可访问的人使用。在许多情况下，它会被不明智地使用。

aria-expanded可以为屏幕阅读器提供良好的用户体验，告知是否可以打开一个元素以显示更多元素（例如在下拉菜单中)。

您不能将aria-expanded 直接应用于nav 元素，因为它必须设置在交互式元素（如button）上，以告知这控制同一容器内另一个元素的可见性（可以是一个nav）。

我能看到的更好的选择是不隐藏任何东西来帮助不使用屏幕阅读器的人。无需在小屏幕分辨率下折叠导航栏，完全可以：

1. 总是显示它
2. 显示一个永久菜单图标以跳转到菜单栏（或暂时在视口内显示）

这样做的好处是可以滚动到菜单栏（对于那些不明白带有三条平行线的图标可能表示什么的人）并让屏幕阅读器用户列出所有内部链接。

当然，如果您构想一个 Web 应用程序而不是一个简单的网站，情况就会大不相同，而 ARIA 在这种情况下可能会更有用。