为什么 HTML5 中的导航栏是列表？
Why do navigation bars in HTML5 as lists?
自从我开始使用 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>
还有<li>里面的<a>
CSS:
ul {
list-style-type: none;
}
li {
display: inline-block;
}
现在与 HTML5 基本相同，但在 <nav> 标签或任何表示 'This is some navigation stuff' 的 browser/screen reader 中被推入。
我的问题是他们是否需要在具有现代 HTML5 语义和 ARIA 可访问性角色的列表中，还有什么好处？当然是链接列表，但还有其他实际原因吗？
我发现的原因：
语义、屏幕 readers 和可访问性： 意见各不相同，关于它如何使屏幕更好（或更糟……）的特殊性reader秒。但是不应该在链接周围使用 HTML5 的 <nav> and/or 相关的 ARIA 角色吗？它是否也需要专门显示为链接列表（无序或其他方式）？
美学：在带有默认项目符号点的垂直列表中，或者没有CSS，是的.但是其他替代标记（例如 <nav> 中的 <a>）而不是 <ul> 中的 <li> 将根据需要轻松或更容易地设置样式。
现有使用：它在现有网站中被大量使用（例如 StackExchange 站点、MDN，还有很多很多……）。
W3C <nav> 规范：说链接不必在列表中，但它可以。但是它还把<nav>的内容指定为'a section of links'，是不是也需要是一个'list of links'？
向后兼容: 经常使用所以应该得到广泛支持，HTML5和ARIA可能旧版不可用browsers/screen readers.
各种参考帖子：
- CSS Tricks - 2013-01 - 表示他们不会使用列表。然后在他们的导航中使用列表：-S
- Dustin Brewer article (archived) - 2011-06 - 广泛引用
- Stack Overflow：Why should I use UL/LI in my HTML? and Should navigation bars always be implemented as lists? - 2012 - “是的，它是一个链接列表”。
- HTML5 spec
- Bruce Lawson article - 2005 - 实际上显示列表效果更好（尽管经常说“Bullet”），但是很旧......（我会尝试用
<nav>)
- B Free More article, VJAKYSQQ article and Jim Doran article - 2011 - 基于一位 JAW 盲人用户的讲话，并表示使用列表会使情况变得更糟
<div> 和 <span>应该使用 s（从 HTML5 之前开始）。更糟糕的是，否则它会尝试读出所有导航列表而不是页面实际内容。
我可能会继续使用列表，因为这似乎是当前的现状，希望能够向后（和向前？）兼容，我会尝试使用现代屏幕对自己的代码进行更多研究 readers*。但是是否有理由在导航中使用具有 HTML5 语义的最新列表？
此外，除了 JAWS，我还应该尝试 reader 哪个屏幕？
为什么将导航栏实现为 html 列表 (ul) 的问题不如不使用列表时如何实现它们重要。
HTML 菜单就像食物菜单，本质上是无序列表。您可以浏览并选择所需元素的内容。人们不会选择将菜单呈现为列表，这是事实：菜单就是列表。那么为什么要使用 ul 和 li 之外的其他元素？
某些浏览器实现的默认 CSS 定义用项目符号显示它的事实与表示有关，但不会改变标签本身的含义。
例如，根据 W3C，这里是 div 的定义：
The div element is a generic container for flow content that by itself does not represent anything.
现在定义一个table:
The table element represents a table; that is, data with more than one dimension.
这是ul的定义：
The ul element represents an unordered list of items; that is, a list in which changing the order of the items would not change the meaning of list.
3个定义中，比较合适的标签是ul.
此外，它还为屏幕阅读器提供导航机制，例如宣布层次结构、转到 next/previous 元素、...
关于屏幕阅读器，您还可以尝试 NVDA、Chromevox 和 Voiceover。
层次结构！
许多导航菜单包含不止一个级别（通常用于 drop-down 菜单），即层次结构：
- Home
- Products
- Physical products
- Digital products
- Contact
如果不使用 ul（带有嵌套的 ul），您将无法在标记中表示此层次结构（除非导航是 complex/long，在这种情况下您可以将 sub-sections 与标题元素一起使用。
您的导航（当前）不超过一级？这并没有突然改变它的语义，它仍然是相同的信息结构，只是只有一层而不是两层或更多层。
列表的更多好处。
通过使用 ul，用户代理（如屏幕阅读器）有机会提供利用该结构的功能。例如，屏幕阅读器可以宣布列表有多少项目，并提供其他方法来导航该列表（例如，跳转到first/last项目）。
如果只使用div，很容易发生导航用户"tab out"没有注意到导航已经结束的情况。通过使用 ul，开始和结束的位置非常清楚，这对于导航菜单尤其重要，因为导航条目通常只有与所有其他条目相比才有意义（找到正确的 link 通常只有检查所有可用的导航 link 并排除它们才能实现您的目标。
这一切与nav无关。
nav 元素仅表示此部分包含导航 link。没有 nav（即 HTML5 之前），用户代理只知道有一个列表。使用 nav，用户代理知道有一个列表 + 它用于导航。
此外，nav当然不应该总是包含ul，因为并非所有导航都是link的列表。看到这个 nav example in the HTML5 spec:
A nav element doesn't have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose:
<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>
自从我开始使用 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>
还有<li>里面的<a>
CSS:
ul {
list-style-type: none;
}
li {
display: inline-block;
}
现在与 HTML5 基本相同，但在 <nav> 标签或任何表示 'This is some navigation stuff' 的 browser/screen reader 中被推入。
我的问题是他们是否需要在具有现代 HTML5 语义和 ARIA 可访问性角色的列表中，还有什么好处？当然是链接列表，但还有其他实际原因吗？
我发现的原因：
语义、屏幕 readers 和可访问性： 意见各不相同，关于它如何使屏幕更好（或更糟……）的特殊性reader秒。但是不应该在链接周围使用 HTML5 的
<nav>and/or 相关的 ARIA 角色吗？它是否也需要专门显示为链接列表（无序或其他方式）？美学：在带有默认项目符号点的垂直列表中，或者没有CSS，是的.但是其他替代标记（例如
<nav>中的<a>）而不是<ul>中的<li>将根据需要轻松或更容易地设置样式。现有使用：它在现有网站中被大量使用（例如 StackExchange 站点、MDN，还有很多很多……）。
W3C
<nav>规范：说链接不必在列表中，但它可以。但是它还把<nav>的内容指定为'a section of links'，是不是也需要是一个'list of links'？向后兼容: 经常使用所以应该得到广泛支持，HTML5和ARIA可能旧版不可用browsers/screen readers.
各种参考帖子：
- CSS Tricks - 2013-01 - 表示他们不会使用列表。然后在他们的导航中使用列表：-S
- Dustin Brewer article (archived) - 2011-06 - 广泛引用
- Stack Overflow：Why should I use UL/LI in my HTML? and Should navigation bars always be implemented as lists? - 2012 - “是的，它是一个链接列表”。
- HTML5 spec
- Bruce Lawson article - 2005 - 实际上显示列表效果更好（尽管经常说“Bullet”），但是很旧......（我会尝试用
<nav>) - B Free More article, VJAKYSQQ article and Jim Doran article - 2011 - 基于一位 JAW 盲人用户的讲话，并表示使用列表会使情况变得更糟
<div>和<span>应该使用 s（从 HTML5 之前开始）。更糟糕的是，否则它会尝试读出所有导航列表而不是页面实际内容。
我可能会继续使用列表，因为这似乎是当前的现状，希望能够向后（和向前？）兼容，我会尝试使用现代屏幕对自己的代码进行更多研究 readers*。但是是否有理由在导航中使用具有 HTML5 语义的最新列表？
此外，除了 JAWS，我还应该尝试 reader 哪个屏幕？
为什么将导航栏实现为 html 列表 (ul) 的问题不如不使用列表时如何实现它们重要。
HTML 菜单就像食物菜单，本质上是无序列表。您可以浏览并选择所需元素的内容。人们不会选择将菜单呈现为列表，这是事实：菜单就是列表。那么为什么要使用 ul 和 li 之外的其他元素？
某些浏览器实现的默认 CSS 定义用项目符号显示它的事实与表示有关，但不会改变标签本身的含义。
例如，根据 W3C，这里是 div 的定义：
The div element is a generic container for flow content that by itself does not represent anything.
现在定义一个table:
The table element represents a table; that is, data with more than one dimension.
这是ul的定义：
The ul element represents an unordered list of items; that is, a list in which changing the order of the items would not change the meaning of list.
3个定义中，比较合适的标签是ul.
此外，它还为屏幕阅读器提供导航机制，例如宣布层次结构、转到 next/previous 元素、...
关于屏幕阅读器，您还可以尝试 NVDA、Chromevox 和 Voiceover。
层次结构！
许多导航菜单包含不止一个级别（通常用于 drop-down 菜单），即层次结构：
- Home
- Products
- Physical products
- Digital products
- Contact
如果不使用 ul（带有嵌套的 ul），您将无法在标记中表示此层次结构（除非导航是 complex/long，在这种情况下您可以将 sub-sections 与标题元素一起使用。
您的导航（当前）不超过一级？这并没有突然改变它的语义，它仍然是相同的信息结构，只是只有一层而不是两层或更多层。
列表的更多好处。
通过使用 ul，用户代理（如屏幕阅读器）有机会提供利用该结构的功能。例如，屏幕阅读器可以宣布列表有多少项目，并提供其他方法来导航该列表（例如，跳转到first/last项目）。
如果只使用div，很容易发生导航用户"tab out"没有注意到导航已经结束的情况。通过使用 ul，开始和结束的位置非常清楚，这对于导航菜单尤其重要，因为导航条目通常只有与所有其他条目相比才有意义（找到正确的 link 通常只有检查所有可用的导航 link 并排除它们才能实现您的目标。
这一切与nav无关。
nav 元素仅表示此部分包含导航 link。没有 nav（即 HTML5 之前），用户代理只知道有一个列表。使用 nav，用户代理知道有一个列表 + 它用于导航。
此外，nav当然不应该总是包含ul，因为并非所有导航都是link的列表。看到这个 nav example in the HTML5 spec:
A
navelement doesn't have to contain a list, it can contain other kinds of content as well. In this navigation block, links are provided in prose:<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>