为什么 HTML5 中的导航栏采用列表形式？

自从我开始使用 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>

^{Also with <li> inside the <a>}

CSS:

ul {
    list-style-type: none;
}

li {
    display: inline-block;
}

和现在的HTML5基本是一样的，只是塞进了一个<nav>标签或任何向浏览器/屏幕阅读器显示“这是一些导航内容”的内容。

我的问题是它们是否需要包含在现代 HTML5 语义和 ARIA 可访问性角色的列表中，还有哪些好处？当然它是一个链接列表，但是还有其他实际原因吗？

我发现的原因：

• 语义、屏幕阅读器和辅助功能：对于如何让屏幕阅读器变得更好（或更糟……）的观点各不相同。但不应该使用 HTML5<nav>和/或链接周围的相关 ARIA 角色会执行此操作吗？它是否还需要专门显示为链接列表（无序或其他）？

• 美学：在带有默认项目符号点的垂直列表中，或者没有 CSS， 是的。但其他替代标记（例如<a> in <nav>） 代替<li> in <ul>将根据需要轻松或更容易地设计风格。

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

• W3C <nav> spec：表示链接不必位于列表中，但可以是。但它也指定了内容<nav>作为“链接的一部分”，它是否也需要是“链接列表”？

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

各种参考帖子：

• CSS 技巧 https://css-tricks.com/navigation-in-lists-to-be-or-not-to-be/- 2013年01月 -说他们不会使用列表。然后在导航中使用列表:-S
• 达斯汀·布鲁尔文章（已存档） https://web.archive.org/web/20110610170958/http://dustinbrewer.com/the-importance-of-using-lists-for-navigation/- 2011年06月 -广泛提及
• 堆栈溢出：为什么要在 HTML 中使用 UL/LI？ https://stackoverflow.com/questions/13416866/why-should-i-use-ul-li-in-my-html and 导航栏是否应该始终以列表的形式实现？ https://stackoverflow.com/questions/12476672/should-navigation-bars-always-be-implemented-as-lists- 2012 -“是的，它是一个列表中的链接列表”.
• HTML5 规范 https://www.w3.org/TR/html5/sections.html#the-nav-element
• 布鲁斯·劳森文章 http://www.brucelawson.co.uk/2005/navigation-lists/- 2005年 -实际上显示列表工作得更好（尽管经常说“子弹”），但是很旧......（我将尝试进行类似的测试<nav>)
• B 免费更多文章 http://bfreemore.blogspot.co.uk/2011/01/web-accessibility-with-reinhard-stebner.html, VJAKYSQQ文章 http://vjakysqq.blogspot.co.uk/2011/01/january-refresh-baltimore-reinhard.html and 吉姆·多兰文章 http://jimdoran.net/joy/webdesign/refresh-web-accessibility- 2011 -基于 JAW 的盲人用户的讲话，并表示使用列表会使情况变得更糟，并且<div>的&<span>应该使用 s （从 HTML5 之前开始）。更糟糕的是，否则它会尝试读出所有导航列表而不是页面的实际内容。

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

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

等级制度！

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

• Home
• Products
  • 实物产品
  • 数码产品
• Contact

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

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

列表的更多好处。

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

If only div使用时，很容易发生用户“跳出”导航而没有注意到导航已经结束的情况。通过使用ul，非常清楚起点和终点在哪里，这对于导航菜单尤其重要，因为导航条目通常只有与所有其他条目相比才有意义（通常只有通过检查所有内容才能找到适合您目标的正确链接）可用的导航链接并排除它们）。

这一切都与nav.

The nav元素只是传达该部分包含导航链接。没有nav（即 HTML5 之前），用户代理只知道有一个列表。和nav，用户代理知道有一个列表 + 它用于导航。

此外，nav当然不应该always包含一个ul，因为并非所有导航都是链接列表。看到这个navHTML5 规范中的示例 https://www.w3.org/TR/2014/REC-html5-20141028/sections.html#the-nav-element:

A 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>