最近关于 列表中标记导航（或不标记）的帖子引发了近 200 条评论，这些评论大多是对该主题的精彩讨论。 我认为总结重要的要点将会有益。
“反对” 列表中的导航
- 至少有一位屏幕阅读器用户更喜欢没有列表的导航，这正是最初文章的起源。
- 更简单的标记。
nav > a比nav > ul > li > a更简单/更少。 - Div 和 span 可以一样好，特别是与 ARIA 角色一起使用时
“支持” 列表中的导航
- 宣布列表中项目的数量可能会有所帮助
- 对非 CSS 浏览器中结构的益处（Lynx 屏幕截图）
- 长期存在的模式，尚未被证明是一个普遍的大问题
- 列表是屏幕阅读器的“钩子”（例如，按 L 键打开列表）并很好地显示层次结构
- 安全：列表中只能包含列表项，导航则不然
平局
- 额外的标记对于样式设置很有帮助。 我称之为平局，因为它很真实，但有点牵强。 我可以在页面上的每个 div 中包装另一个 div，这可能在将来对样式设置有所帮助。
- 您无法在
<ul>上使用role=navigation（“允许的角色值是 directory、listbox、menu、menubar、tablist、toolbar、tree 和 presentation”。）我称之为平局，因为在这两种情况下，您都应该将导航包装在<nav role="navigation">中。 - 屏幕阅读器的“冗长性”是可选择的。 列表更冗长，但可以进行调整。
- VoiceOver 处理方式完全相同
- 规范也不在乎哪种方式。
相关
- 无障碍不仅仅是屏幕阅读器
“赢家”？
就我个人而言，我认为将导航标记为列表似乎是最好的选择。 不过，您可以查看事实并自行决定。
“将无障碍留给专家”
Dennis Lembree 认为我不应该谈论这些东西，因为我不是专家。 我觉得要点是我在最初的文章中就断定列表不好，而我的煽动性言论会损害互联网。 我不这么认为。 我认为我得到了一套新的事实，这些事实对旧的最佳实践提出了质疑，我将开始对此进行讨论。 我认为，在讨论开始之前就关闭讨论，对互联网的伤害更大。 也就是说，我鼓励任何时候对本博客、我的文章和我本人进行建设性的批评。
感谢您总结，Chris！ 我从未看完那些评论 =)
质疑我们所做的事情以及我们为什么做这些事情对学习很有帮助，
如果不是尝试不同的方法，我们现在仍然会通过偏移文本来隐藏文本 <—– 9999px 在那里。
阅读一些评论后，我开始质疑一些标记标签，例如 UL 与 OL 标签，它们可能只需放在一个 list 标签中，然后通过 CSS 或作为属性来指定它应该是编号、字母还是使用项目符号或方块之类的样式。
Ya，谁会那样做！？
所以，我假设您是指这种方法：http://www.zeldman.com/2012/03/01/replacing-the-9999px-hack-new-image-replacement/ - 不幸的是，我仍然坚持使用 -99999px，因为当您点击 Ctrl+F 并输入使用 text-indent:100%; 方法隐藏的文本时，文本会变得可见。
请参见此 fiddle：http://jsfiddle.net/4d5H6/，在 Webkit 中按 CTRL+F 并输入“Hello”，然后在其中按几次 Enter 键。
这个话题当然不乏意见。 但正如您所知，意见就像 @#%^&*$, 每个人都有自己的意见。 我浏览了大约 5% 的回复。 很想看到一些没有 ul 的下拉菜单解决方案，而不是理论上的解决方案。 再次感谢您提出这个话题。
对于下拉菜单，您有 menu type=”toolbar”。
从语义上讲，它不是“导航”，但如果您能将工具栏包装在 nav 中。
ul 和 menu 标记之间的区别很小 - 两者都只能包含 li 元素，并且基本上是相同的（至少目前是这样）。
但 menu type=”toolbar” 标记具有更好的语义 - 它被视为“交互式内容”，而 ul 元素旨在显示数据（没有交互）。
看看您对这个有什么看法。 我晚了两天，因为我刚读完了关于这个话题的两篇文章，然后在读完第一篇之后做了这个笔。
http://codepen.io/bkbillma/pen/mKkEv
感谢您总结，Chris - 很高兴看到建设性讨论的结果。
很有趣的是，看到这场辩论似乎改变了您对哪种解决方案更好的看法 - 这种事情有助于推动我们的行业向前发展，以便作为一个群体找到做事的最佳方式。
如果我们不讨论，我们就无法互相学习，我认为这次讨论提出了很多超越它与无障碍相关性的问题。
很棒的总结，Chris。 值得一提的是，我真的很喜欢这次特别的讨论，并看到了人们对这个问题的不同观点和看法。
通过学习成为专家，而通过与他人讨论想法来学习。 避免讨论毫无意义。
首先，我认为您开始这次对话是件好事，我们都应该至少对讨论标记内容的新方法持开放态度，但也许像您（Chris）这样的人，由于他们在网络上的强大影响力以及他们花费无数时间与公众分享他们知识，对许多网页开发人员都有很大的影响力，在传播可能不是最佳技术给网页设计师/开发人员使用时应该谨慎一些。
我知道这给您带来了额外负担，但我认为作为网页设计社区中重要角色之一所带来的责任……您所处的影响力地位是实至名归的，这得益于您 5 年多的博客文章以及您分享对网页开发的见解……为此，您应该得到赞扬……我只是认为，当一个人处于这种地位时，应该注意自己发表的内容。
无论如何……请继续分享您的知识……因为我期待阅读它，无论我是否同意它……
我上面的一些评论让我不太舒服……只要继续用心写博客文章……我们会用各种方式告诉你我们的意见……公开讨论和对所有想法的开放态度，以及愿意讨论可能的新技术，都是好事……
只要继续发布……我们会提供反馈……
这是一个很棒的博客，我无法计算我使用它的次数，无论是工作还是纯粹的阅读乐趣……
我们不需要屈服于专家，但我们应该尊重专业知识。吉姆·艾伦的评论说得最好
感谢你整理这些内容，克里斯！要浏览完这 200 条评论一定很辛苦……尽管如此，我也认为将导航标记为列表似乎是最佳选择。
克里斯，这正是我不再关注许多“专家”的原因，因为他们直接停止了允许评论，他们在几天后就关闭了评论，或者他们要求使用 Twitter 或 Disqus 评论（这两个网站在我的工作场所都被屏蔽），或者其他一些障碍。
我需要知道文章的内容是否可靠，其他人对此有什么看法，如果这是一篇旧文章，内容是否仍然相关。评论区就是关键所在。除非某位专家的输出经受住观众、其他公认专家或其他方面的审查，否则我不会将其视为有效。通常情况下，开始讨论的人是否是该主题的专家并不重要。
将任何事情都“留给专家”很容易导致完全遗漏，它可能与完全隐藏和被大众忽视没有什么区别。
我认为，拥有相当多的读者群可以证明偶尔的多样化是合理的，这并不完全无关（根本就不是）。对我来说，你的所有文章都很有趣，因为我喜欢追随你作为一名网页开发人员的进步，并且它们很容易理解。如果你只写关于 CSS 部分的内容，我认为这将是你所做的事情和你所做之事的 不完整说明。
没错。我一直很好奇为什么人们如此急于关闭他们文章的评论（例如，“对该条目的评论将在两周后自动关闭”。）。在我看来，这会让互联网变得更加毫无价值和一次性。这就像你说你的内容不再有任何特殊价值一样。
克里斯，好文章。我认为最好的策略是无论什么方法最适合当时的那个项目。
对这个主题有深刻见解，克里斯。虽然我仍然认为使用 ul 是最好的选择，但我仍然感谢围绕你的博客文章形成的**讨论**。
至于丹尼斯，他继续发表了一篇冗长的评论，最后写道**“请不要因为我的想法而把我钉在十字架上”**，这似乎有点虚伪，鉴于他的博客文章。
我的一位朋友几周前和我谈过这些，我试图在导航项目中放置列表，但对我来说，它在结构方面并不适合，虽然我相信这更多是个人喜好。我最终在某个项目中使用了 nav > span > a 来进行导航，它很好地完成了它的目的。
列表是最好的方法。
几乎每个人都用它来进行导航是有原因的。
克里斯，你对网络的了解与任何人都差不多。我不确定列表是正确还是错误，但我确实知道，你比大多数人更有资格写任何与网络相关的内容。
感谢你所做的一切！
我收藏了许多幸运饼干。其中一个上面写着
只要我能负担得起，当有多种方法可以做某事时，我都会尽量让自己去研究、思考和讨论，直到我确信哪种方法是最好的，在我已经意识到的选择中，即使它只是稍微好一些。
在这个过程中，我会将一切视为决定因素，甚至主观证据，比如意见、感觉、直觉等。但是，我会尽量让每个因素都得到它应得的权重，不多也不少。
通往结论的思维轨迹与结论本身一样宝贵，甚至可能更宝贵，因为思维轨迹验证和支持了结论。似乎经常出现思维轨迹不存在、丢失或存在漏洞的情况。我认为当思维轨迹找到其结论时，这是一次胜利，并且看到一个完整的、正确的思维轨迹完全支持一个结论。
所以让我们继续前进，在“对细微细节的完善”中，在我们的理解、知识、技艺中，不要让“专家”阻挡我们的道路。
克里斯，我完全支持你的立场。我认为使用创建网络的工具（HTML/CSS/JS/等等）的人是应该开始挑战“现状”的辩论的人，并且这些辩论应该公开且对专家和“非专家”都开放。请不要有象牙塔。
你的文章引发了许多反应（包括丹尼斯的文章），这些反应帮助了许多谦虚的从业者（包括我自己）了解了一些常用实践背后的无障碍问题。我认为互联网这次做对了！
嘿。我睡了一觉。一个 CSS 专家没有资格写关于无障碍性的文章，这种想法纯粹是令人不齿的、令人厌恶的胡说八道。
正如我不得不时不时地提醒我的开发团队成员一样，CSS 不是魔法。你不能把任何垃圾扔进你的 HTML 中，然后期望可重复使用的企业级 CSS 可以正确地渲染它。HTML 结构必须被规定并遵循。
因此，鉴于在开始编写 CSS 之前对 HTML 进行相当多的预先思考是合理的，在编写 CSS 之前对 HTML 进行相当多的预先思考是合理的，考虑到无障碍性将是负责任的做法。
你不是专家？！好吧，对我来说，列表永远都是最好的。
克里斯，
我同意你的文章，并不同意丹尼斯关于将无障碍性留给“专家”的观点。挑战当前的流程或一系列流程，让社区参与其中，并没有什么错。每个流程都可以不断改进。
丹尼斯说得有道理，ul 主题已经被反复讨论过，但这里的区别在于，你并没有宣称自己是该主题的专家，而是创造了一个平台，让其他人讨论他们对该主题的看法。这不是你用指责的方式告诉每个人按照你的方式去做，而是你说的“挑战”这个主题。真正的专家欢迎挑战和逆境。虽然这可能是一个有点极端的对比，但你认为医学和医疗实践是如何改进的？我们有一个基本的成功公式，然后我们在其基础上进行改进。
我有一句格言我一直奉行，那就是“我不是专家，我只是把所有可能出错的事情都做了一遍”。在我看来，只有当专家尽其所能地挑战各种事物时，他们才是真正的专家。
这篇文章的第二部分甚至表明你承认列表实际上是更好的选择。所以你不仅用一种特定的信念/理解参与了论坛，而且你调整了你对该主题的理解。
我喜欢这些文章。继续挑战社区，以及我们每天作为开发人员/前端开发人员所面临的工作。我期待着它。
嗨！很久以前，在我进入无障碍世界时，大约 9 或 10 岁的时候，我还没有用列表标记菜单，将链接一个接一个地排列，这确实会导致一个致命的错误，因为无障碍屏幕阅读器只读取第一个链接，而其他链接则不会被读取，因此必须用可打印字符分隔连续的链接，这样做会导致在网站中引入额外的字符，给网站带来噪音，因此解决这个问题的最佳方法是使用列表。无论如何，仅仅为了拨打一段话，一个标题，等等……如果一系列元素是相互关联的，我们应该创建一个列表吗？
我觉得我的英语……
所以我们是否可以期待另一篇总结文章，总结一下这里评论中讨论的内容呢？
首先他说：“在我看到一些可靠的研究表明这样做很蠢之前，我会坚持下去。”
然后他说：“就我个人而言，我认为将导航标记为列表似乎是最佳选择。”
...
…而我则说：“随便吧！”
感谢你Chris总结了这个主题，并在主流的网页开发博客上引发了有关可访问性的讨论！
上一篇文章真的激发了我的思考。我以为少写点代码会很有价值，但我认为列表中的导航要好一些，仅仅为了样式。我认为你可以用li和a一起做更多的事情，而不仅仅是为超链接设置样式。
此外，在Joomla！或任何带有CMS的生成的导航中使用这种导航方式需要大量的编码。
我坚持使用老式的方式。ul > li > a。
感谢你分享了这个很棒的话题！
感谢你Chris之前的那篇文章几乎说服了我。对我来说，列表是导航的事实标准，但没有真正需要或好处，这似乎很奇怪。我很高兴你得出的结论是，无论如何使用它都是可以的 ;-)
感谢你总结了这个主题。它非常有帮助，非常感谢。
Chris说得太好了！感谢你出色的总结！
很棒的总结Chris……感谢！！！
我同意你的结论Chris，纯粹是为了语义。在我看来，任何可以定义为列表的项目（例如链接列表）都应该标记为列表。我接受这种方式标记导航需要更多代码，但是如果你要关闭样式表以查看最原始的HTML，链接列表更像是文档的目录。列表更有意义。
同意你的立场:-)
你提到的这个问题真是太微不足道了。
我知道吧？！为什么我们讨论几乎所有网站都会用到的标记模式，而碧昂斯的裙子可能用了鬣蜥。
最重要的是“为了”这个点，在原始文章中没有被包含进来，即使原始文章中的许多评论都提到了它，那就是链接列表仍然是一个列表，无论NAV元素是否存在。列表就是列表。NAV元素表征它在DOM中占据的整体块。它给出了关于内部内容的提示，但这并不意味着内部内容现在可以没有结构。正如我之前所说，仍然有许多方法可以在NAV中处理内容和链接；只是不要认为列表突然不再是列表，仅仅因为HTML5给了我们NAV。
非常振奋人心的态度。这里讨论的是原则，而不是人，而且讨论本身没有什么问题。
如果是一个简单的网站，我会在.中使用一个经典的列表。如果网站很复杂，需要一些浏览，我会将列表分类到div中，并将链接转换为下拉菜单。这使得设计最小化，但更重要的是，盲人用户或屏幕阅读器不必在每次页面加载时都遍历整个导航栏。
我的意思是，在导航栏里。
我认为使用列表更容易。这意味着对于使用CMS编辑器的网站，你可以轻松地为导航创建一个无序列表。
多年来，银行和金融机构一直在告诉我们，把银行和金融问题交给他们处理。看看最近的结果。食品行业也是如此。孟山都怎么样？是的，把事情交给“专家”在过去对我们来说真的非常有效……
我是可访问性社区的一员，我个人认为可访问性问题开始在通常的“可访问性专家”圈子之外被讨论和辩论，这是件好事。这个博客是这些受欢迎的地方之一，它从网页开发者那里获得了许多积极的关注，因此在这里讨论可访问性问题对于数字包容性来说是件好事。网页开发者接触到这些问题越多，他们将这些问题整合到工作中的可能性就越大。
当然，他们可能不会一开始就总是做对，但是只要有一点指导，我们可以希望他们随着时间的推移而调整，就像网页开发的其他方面一样。
就像任何其他事情一样，可能会不时出现错误的假设，我认为这里提出的关于列表和导航的问题就是一个例子，不幸的是，这个问题失控了。但我认为即使是最顶尖的专家也不能免受犯错。
我不想为任何人辩解，因为这不是我的职责，但是可访问性社区中的许多人，包括我自己，都对这个主题充满热情，因为它呼吁了人的本性和排斥。有时，这会激发情感，进而引发比预期更大的反应。
我觉得这一切都是每个人积极学习曲线的一部分：有些人获得新技能，而另一些人则学会放手。
因此，尽管博客文章中写着将可访问性留给专家，但我鼓励你继续将可访问性视为值得考虑的事情。首先，思考它会让这里每个人都更加关注这个话题，其次，它迫使每个人跳出思维定式去思考。
毕竟，我们都想要一样东西，那就是创造尽可能多的网页浏览体验，使最广泛的受众和尽可能多的平台能够使用。所以请继续探索新的思路，并始终将可访问性放在首位。你做得很好。正如你可能已经猜到的，一些可访问性人员也会在关注！;p
希望我们大家能够齐心协力，为我们都深深关心的这个网络做出积极而有建设性的贡献，让它变得更好。
Chris，感谢你愿意学习，一个人很少（甚至从来没有？）代表所有人说话。正如我在第一篇文章的评论中写的那样，我鼓励每个人确保他们至少对演讲者的资格有一些了解。我们是否应该这样做，无论这个人是否残疾，对吧？
我还想鼓励那些有兴趣了解和学习更多可访问性知识的人，定期阅读 WebAxe 博客，网址为http://www.webaxe.org。Dennis 为让网络变得更美好做出了很多贡献，我相信如果你阅读更多内容，你也会同意的。
虽然讨论很有趣，但是当前的导航标记技术既不过时也不存在问题。我认为这个问题很简单，如果定义的是项目列表，那么将其标记为列表。为了减轻添加额外标记的几秒钟而声称传统的导航模式不是项目列表，这让人想起表格布局和省略结束标签的时代。但是，如果网站的导航显然不是列表，那么使用HTML5 NAV标签并使用适当的语义标记。我认为不使用列表最大的缺陷是，当导航包含数十个项目并且没有为屏幕阅读器提供跳过内容链接时。我大学的网站就是一个很好的例子（tccd.edu；在Lynx中查看），它说明了放弃适当结构是多么荒谬。
完全正确。
可访问性不仅仅是屏幕阅读器。我在摘要中还没有看到的是，链接默认情况下是内联元素，而你需要为每个新的导航项目进行块级分离，所以仅仅使用a标签是不够的。
此外，我可能错了，但我一直认为ARIA角色是次要的，好的html是主要的。当标准HTML结构/语义无法满足时，可以使用它。
这有点偏离主题，但也与讨论相关。我们忽略的一点是，理想情况下，网页应该首先用 HTML 创建，内容应该包含在适当且逻辑的标签中（“这是一个列表吗？那就用列表标记它。这是一个段落吗？那就用段落标记它。这是一个标题吗？那就用标题标记它。”）。这些考虑因素应该在考虑“它在浏览器中的显示效果”之前进行。这就是 CSS Naked Day 的意义所在。在您正确地标记了内容之后，就可以开始应用样式了。我们甚至可以说，先标记您的内容，然后在只应用 UA 样式表的浏览器中检查它，然后再应用您自己的样式。如果您现在在导航中放弃 UL > LI，因为您认为您的链接列表不再是列表，那么在您应用自己的样式之前，您的页面在浏览器中查看时至少在逻辑上对您来说是清晰的吗？
不知为何，我不愿意被一位自称专家的家伙告诉我们其他人要闭嘴，好像担心我们会得出与他已决定的结论不同的结论。事实是，专家就在我们周围。真正的创新可以来自各种观点的融合，成为同行之间讨论的结果，而不是单一的、自以为是的观点。
在阅读了提交的优缺点之后，我发现这实际上无关紧要。我发现这一点很令人振奋。每个人都应该尝试两种方法，看看哪种方法更符合他们的语义观。
对于有序的目录式导航（例如维基百科条目跳转链接到主要标题），我会倾向于使用有序列表来快速以数字形式直观地显示各个小节。但在我看来，其他所有内容都可以随意实验。
尽管丹尼斯和其他一些人声称，“列表”的语义意义非常轻，在这种情况下几乎没有意义。“导航”另一方面，意义重大。但是，将项目分组在一起的“列表”——为了什么目的？导航。
您需要完成此项目的项目列表？显然是列表。
您可以点击以导航到该网站的项目列表？并不完全是。它不是我们通常认为的列表。——它不是待办事项清单，也不是愿望清单，也不是大卫·莱特曼的十强清单。它只是一堆分组在一起的导航项目，您可以选择将其视为列表或不视为列表。
感谢您给我们机会重新评估这一点。
列表或非列表都是有效的，我不会因为其他网页开发者选择的不同而批评他/她。但是，允许进行讨论非常重要。谢谢，Matth
克里斯蒂安在上面的观点非常有说服力，说明了为什么应该将导航列表视为列表。然而，我不得不注意到，其理由完全基于它在浏览器中呈现的视觉效果，尽管没有应用 CSS，就像在裸日一样。
我们是否以此来定义语义？不，不是。不过 YMMV。
“然而，我不得不注意到，其理由完全基于它在浏览器中呈现的视觉效果，尽管没有应用 CSS，就像在裸日一样。”
我的意思并不完全如此。我的意思是，首先应该正确地标记内容，然后再考虑它在浏览器中的外观。克里斯·科伊尔最初的文章建议，“也许我们可以将
DIV#nav > UL > LI >A的常见用法更改为NAV > A”，但NAV只应该取代DIV#nav，而不是DIV#nav > UL > LI。因此，如果以前是链接列表，那么现在它可能仍然是列表，甚至可能更确切地说是列表。如果我们现在要切换到
NAV > A（而且目前的趋势似乎不是这样），那么为什么根据完全相同的逻辑，我们以前不只使用DIV#nav > A呢？我在此处的许多帖子都指出，链接组可以是列表以外的东西，但链接列表仍然是列表。这是主要观点（重点是“主要”）。次要观点（重点是“次要”）是在您标记了内容之后，在您应用自己的样式之前，在浏览器中查看它时，它在逻辑上对您来说是清晰的吗？我从来没有暗示人们将所有链接都标记在列表元素中，这样我就可以过来看到他们机器上或甚至是我自己的机器上在 CSS Naked Day 上的漂亮、缩进、带项目符号的链接列表。
希望这个澄清能够有所帮助。
我写这段话不是为了引起争议，但是——为什么导航中的链接应该被认为是“列表”而不是组或集合呢？如果只有两个项目，那算不算列表呢？我完全明白这一点的目的，但似乎我们正在讨论语义，无论是代码还是含义。
我们使用列表是因为它被认为是语义的，并且屏幕阅读器可以处理它。我要指出，当时，额外的元素确实会导致一些浏览器问题，而列表式的导航更加困难，但是我们都学会了处理它，浏览器也得到了改进。
除非您的所选方法或偏好的细微差别能够被现在或将来的各种设备（过去已成历史）解释，否则这种讨论的语义实际上没有任何价值。
虽然在实践中许多讨论的内容都是可以接受的，但我认为，新的标签比它们是否为列表更能描述容器中的链接是什么。只有时间才能证明设备是否能够学会使用这些标签来理解其中的链接。
是的，这绝对是关于语义的。是的，两个项目构成了一个列表……假设它本身就是一个列表。如果它是一个列表，那么项目数量无关紧要。
购物清单
牛奶
鸡蛋
不，导航中的链接不必被认为是列表。问题不在于是否必须将它们视为列表。问题是：如果您的导航中的链接是链接列表，那么它就是一个列表。如果它是其他东西，那么它就是其他东西。尽管如此，如果您将它们视为一个组或一个集合，那么您是否有
GROUP或COLLECTION标签来包裹这些项目？请记住，
NAV只应该取代DIV#nav，而不是DIV#nav > UL > LI。克里斯，继续努力。
任何一种方法都可以，您与社区就此事进行讨论很好。
我越来越厌倦那些自认为是 UI、UX 和语义专家的人，他们告诉您应该如何标记您的页面，好像“只有一种方式”可以做到这一点。
最佳实践并不总是规定页面应该如何标记。努力在标记和设计方面保持一定的创造性自由，谁知道有一天您的方法可能会成为最佳实践。否则，一切都会变得千篇一律。
特别是现在 HTML 5 推出后，许多被认为是标记最佳实践的内容已经不再适用。
将松散的
A元素放入NAV元素中是可以的，但这就像将松散的鸡蛋放入没有单个杯子的鸡蛋盒一样。是的，它包含了它们。它能很好地包含它们吗？不。我不是无障碍方面的专家，但从列出的结果来看，上下文再次至关重要。我可以想象，如果存在大量导航，主导航可能是列表，而子导航则省略列表，或者反过来，如果您希望能够使用“L”键快速导航到子列表/导航。
对于较小的网站，无论您使用哪种方法，这都不会是一个大问题。它实际上取决于应用程序和上下文，就像大多数事情一样。
我认为应该更重视网站地图、访问键和标签索引的实现，而不是导航标记本身。