为什么 HTML5 中的导航栏作为列表？

Question

自从我开始使用 HTML、CSS 等以来，我一直注意到的一件始终如一的事情是，导航栏几乎总是以列表的形式呈现，有以下几种变体：

HTML：

<ul>
 <li><a href="link1.html">link 1</a></li>
 <li><a href="link2.html">link 2</a></li>
 <li><a href="link3.html">link 3</a></li>
 <li><a href="link4.html">link 4</a></li>
</ul>

^{在<a>内也有<li>}

CSS：

ul {
    list-style-type: none;
}

li {
    display: inline-block;
}

现在与 HTML5 基本相同，但在浏览器/屏幕阅读器中添加了 <nav> 标签或任何说“这是一些导航内容”的内容。

我的问题是，它们是否需要在具有现代 HTML5 语义和 ARIA 可访问性角色的列表中，还有什么好处？确定是链接列表，但还有其他实际原因吗？

我发现的原因：

• 语义、屏幕阅读器和可访问性：意见各不相同，特别是它如何使屏幕阅读器变得更好（或更糟……）。但是不应该在链接周围使用 HTML5 的<nav> 和/或相关的 ARIA 角色吗？它是否也需要专门显示为链接列表（无序或其他）？

• 美学：在带有默认项目符号或没有 CSS 的垂直列表中，是的。但除此之外，替代标记（例如 <nav> 中的 <a>）而不是 <ul> 中的 <li> 将根据需要轻松或更容易地设置样式。

• 现有用途：在现有网站中大量使用（例如 StackExchange 网站、MDN 等等……）。

• W3C <nav> 规范：表示链接不必在列表中，但可以。但是它也将<nav>的内容指定为'a section of links'，是否也需要是'list of links'？

• 向后兼容性：经常使用，应该得到广泛支持，HTML5 和 ARIA 可能不适用于旧浏览器/屏幕阅读器。

各种参考帖子：

• CSS Tricks - 2013-01 - 说他们不会使用列表。然后在导航中使用列表：-S
• Dustin Brewer article (archived) - 2011-06 - 广泛提及
• 堆栈溢出：Why should I use UL/LI in my HTML? 和 Should navigation bars always be implemented as lists? - 2012 - “是的，它是一个列表中的链接列表”。
• HTML5 spec
• Bruce Lawson article - 2005 - 实际上显示列表工作得更好（尽管经常说“子弹”），但已经很老了……（我会尝试用 <nav> 进行类似的测试）
• B Free More article、VJAKYSQQ article 和 Jim Doran article - 2011 - 基于 JAW 盲用户的讲话，并表示使用列表会使情况变得更糟，应该使用 <div> 和 <span>s (从 HTML5 之前开始）。更糟糕的是，它会尝试读出所有导航列表而不是页面的实际内容。

我可能会继续使用列表，因为这似乎是当前的现状，并希望能够向后（和向前？）兼容，我将尝试使用现代屏幕阅读器使用我自己的代码进行更多研究*。但是是否有理由在导航中使用更符合 HTML5 语义的列表？

此外，除了 JAWS，我还应该尝试哪些屏幕阅读器？

Answer 1

层次结构！

许多导航菜单包含多个级别（通常用于下拉菜单），即层次结构：

• 首页
• 产品
  • 物理产品
  • 数码产品
• 联系方式

如果不使用ul（带有嵌套的ul），则无法在标记中表示此层次结构（除非导航很复杂/很长，在这种情况下，您可以使用带有标题元素的子部分） .

您的导航（当前）不超过一个级别？这并没有突然改变它的语义，它仍然是相同的信息结构，只是只有一层而不是两层或更多。

列表的更多好处。

通过使用ul，用户代理（如屏幕阅读器）有机会提供利用该结构的功能。例如，屏幕阅读器可以宣布列表有多少项目，并提供其他方式来导航该列表（例如，跳转到第一个/最后一个项目）。

如果只使用div，很容易发生用户“跳出”导航而没有注意到导航已经结束的情况。通过使用ul，可以非常清楚地知道开始和结束的位置，这对于导航菜单尤其重要，因为导航条目通常只有与其他所有条目相比才有意义（找到适合您目标的正确链接是通常只能通过检查所有可用的导航链接并排除它们来实现）。

这一切都与nav无关。

nav 元素只是表示此部分包含导航链接。如果没有 nav（即 HTML5 之前的版本），用户代理只知道有一个列表。使用nav，用户代理知道有一个列表 + 用于导航。

此外，nav 当然不应该总是包含ul，因为并非所有导航都是链接列表。看到这个nav example in the HTML5 spec：

nav 元素不必包含列表，它也可以包含其他类型的内容。在此导航块中，链接以散文形式提供：

<nav>
 <h1>Navigation</h1>
 <p>You are on my home page. To the north lies <a href="/blog">my
 blog</a>, from whence the sounds of battle can be heard. To the east
 you can see a large mountain, upon which many <a
 href="/school">school papers</a> are littered. Far up thus mountain
 you can spy a little figure who appears to be me, desperately
 scribbling a <a href="/school/thesis">thesis</a>.</p>
 <p>To the west are several exits. One fun-looking exit is labeled <a
 href="http://games.example.com/">"games"</a>. Another more
 boring-looking exit is labeled <a
 href="http://isp.example.net/">ISP™</a>.</p>
 <p>To the south lies a dark and dank <a href="/about">contacts
 page</a>. Cobwebs cover its disused entrance, and at one point you
 see a rat run quickly out of the page.</p>
</nav>

Answer 2

为什么将导航栏实现为 html 列表 (ul) 的问题不如不使用列表时如何实现它们重要。

HTML 菜单就像食物菜单，本质上是无序列表。您可以浏览并选择所需元素的内容。人们不会选择将菜单呈现为列表，这是事实：菜单就是列表。那么为什么要使用ul 和li 之外的其他元素呢？

某些浏览器实现的默认 CSS 定义以项目符号呈现它的事实与呈现方式相关，但不会改变标签本身的含义。

例如，这里是根据 W3C 对div 的定义：

div 元素是流内容的通用容器，它本身不代表任何内容。

现在，table 的定义：

table元素代表一个表格；即多维数据。

这是ul的定义：

ul 元素表示一个无序列表的项目；也就是说，改变项目顺序不会改变列表含义的列表。

在 3 个定义中，更适合的标签是 ul。

此外，它还为屏幕阅读器提供导航机制，例如宣布层次结构、转到下一个/上一个元素……

关于屏幕阅读器，您也可以尝试 NVDA、Chromevox 和 Voiceover。