列表中的导航:是还是不是

Avatar of Chris Coyier
Chris Coyier

DigitalOcean 为您旅程的每个阶段提供云产品。立即开始使用 $200 免费信用!

如果您在 Google 上搜索是否应该将列表用作网站导航的标记,您将发现没有争议。每篇文章都建议您应该这样做。您阅读的大多数教程都将使用列表进行导航。您看到的大多数模板都将使用列表进行导航。但这种普遍存在的标记模式绝对正确吗?让我们看看。

注意:请务必查看 总结文章,了解这篇文章发布后我们对所有这些内容的了解。

您今天可能会看到什么

<nav>
  <ul>
    <li><a href="#">Home</a></li>
    <li><a href="#">About</a></li>
    <li><a href="#">Clients</a></li>
    <li><a href="#">Contact Us</a></li>
  </ul>
</nav>

或者,如果是在 HTML5 之前,就不会有 <nav> 标签,而是 <ul class="nav">

替代方案:无列表导航

<nav>
  <a href="#">Home</a>
  <a href="#">About</a>
  <a href="#">Clients</a>
  <a href="#">Contact Us</a>
</nav>

一场老战争

2005 年:布鲁斯·劳森 对屏幕阅读器进行了实际研究。结论是列表是最好的,但它是在将列表与表格中的标记进行比较的情况下得出的,因此这是有道理的。

2007 年:我发布了关于 无列表导航 的内容,达斯汀·布鲁尔 强烈反对 应该永远使用这种方式。达斯汀的文章谈到了语义、无障碍性和屏幕阅读器,但没有进行任何研究,也没有解释为什么无列表导航不具有语义性或会带来屏幕阅读器问题。

雷纳德·斯特布纳的登场

2011 年 1 月,雷纳德在巴尔的摩的一次 Refresh 活动上发表了演讲,显然给观众留下了深刻的印象。他完全失明,并谈论了标记无障碍性。

雷纳德建议 **不要使用列表进行导航,而是使用 divs 和 spans。**

莉亚·沃格利参加了这次活动 并写道

我认为房间里的每个人在听到这句话时都挠了挠头。您学习编码时最先学习的事情之一就是如何构建导航,通常是用无序列表完成的。但是,这种列表结构不利于屏幕阅读器的逻辑。span 标签不被屏幕阅读器识别,因此它可以简化您的内容以实现无障碍性的一种方式。

另一位与会者写道:

Divs 和 spans 是最佳选择,因为它们对屏幕阅读器是不可见的。Stebner 在 mica.edu 上浏览了太多列表,这些列表没有给出他在页面上的位置的任何线索,也没有提供除“列表,10 项。列表,6 项……”之外的任何信息。使用 divs 和 spans,内容可以立即被屏幕阅读器获取。

吉姆·多兰 也在那里

将导航结构(只是一组超链接)放在列表中,应该允许屏幕阅读器在每个链接之间暂停,而不是将所有链接读作一个句子。从语义上来说,这是有道理的。我们使用 HTML 为内容应用有意义的标记 - 将事物标记为列表似乎是一个好主意。但是,没有简单的方法可以识别列表是一组链接,因此具有 12 组链接的页面可能会非常混乱。他用 Jaws 演示了这一点。

我们提到了 ARIA 作为一种解决其中一些问题的方法,并且他不希望使用列表来显示链接,而是希望看到更多 <div><span> 的使用。

雷纳德·斯特布纳说得非常清楚。他使用 JAWS 作为屏幕阅读器,而列表中的导航使他更加困难。

VoiceOver

到目前为止,所有提到的研究都是针对 JAWS 的。据我了解,JAWS 是最流行的屏幕阅读器。还有一种在 OS X 上附带的原生 VoiceOver。在我的测试中,VoiceOver 以完全相同的方式浏览导航,无论它是在列表中还是不在列表中。跨浏览器测试固然重要,跨屏幕阅读器测试也同样重要。

HTML5

其中一些对话早于 HTML5 的广泛使用。HTML5 具有 <nav> 标签,我认为这解决了语义问题。如果您要标记导航,请将其放在 <nav> 标签中。如果没有 HTML5,或者您必须使用其他包装元素,您可以使用 ARIA 角色:<div role="navigation">

更新:询问之后,您应该在 nav 标签上使用 ARIA 角色,即使它已隐式存在,因为某些浏览器没有像应该的那样应用它。因此 <nav role="navigation">。感谢 Dave

规范

表示:

nav 元素不必包含列表……

然后继续展示导航段落的示例。

内联与块

不使用列表进行导航意味着链接将按行排列,而不是像默认列表那样每行一个。我个人觉得这是一个方便的空白画布,并且喜欢不用删除列表的 user-agent 样式表样式。如果您希望链接像列表一样工作,您可以始终通过 CSS 更改链接的 display 属性。

所以

您怎么看?无谓的追求?有价值的讨论?

我个人已经无列表很长一段时间了。在我看到一些可靠的研究表明这是愚蠢的做法之前,我会坚持下去。和以往一样,最好的办法是向雷纳德这样的真正的屏幕阅读器用户了解更多信息。

如果我们继续使用列表,为什么它总是无序列表?我记得瑞安·辛格有一次对此大发雷霆。我们是否应该认为我们非常刻意地选择了该列表的顺序?


请务必查看 总结文章,了解这篇文章发布后我们对所有这些内容的了解。

  • Jason
    评论永久链接#

    应该是 +1 为 标签。

  • Will H McMahan II
    评论永久链接#

    我认为使用列表与否更多地取决于导航内部的类型,而不是什么是一成不变的正确答案。

    如果你把它们看作标签内部的正常内容,你会把它们放在 ul 中吗?或者它只是一个元素序列。
    对于简单的导航,尤其是对于简单的导航,我认为没有理由将其全部包裹在一个额外的元素中。
    此外,导航有很多不同类型,所以我怀疑所有情况都有一种“正确的方式”。

    tl;dr 如果是列表,那么它应该在 nav 中的列表中,但如果它只是一组链接,我看不出将其包裹在 ul 中有什么理由

  • Cameron Spear
    评论永久链接#

    看起来即使在使用屏幕阅读器的人群中,也存在一种偏好。只要你考虑屏幕阅读器,我认为“只有一个正确答案”的说法是错误的。

    如果没有真正使用过屏幕阅读器,仅仅通过观察就很难判断,而且认为所有使用屏幕阅读器的人(或任何群体)都以特定的方式浏览或偏爱浏览互联网是一种危险的态度。

  • Jpop
    评论永久链接#

    我发现很多人的评论很奇怪:“下拉菜单怎么办?”…em 怎么办!?

  • Eric
    评论永久链接#

    所以我非常喜欢这个想法,但我们如何让 WordPress 做到这一点呢?WordPress 想要将所有内容和闪烁标签都放在导航上。有什么想法吗?

  • Chris Coyier
    评论永久链接#

    作为这里的一个路标,我试图在这里保留主要的赞成/反对观点:http://codepen.io/chriscoyier/details/ztxvw

  • Graeme Attkins
    永久链接到评论#

    只是想插一句…

    回到 2005 年左右,我与 RNIB 紧密合作,特别是在重建苏格兰资格认证局网站的无障碍功能时,与盲人测试用户合作。这些测试用户使用 JAWS 和 Supernova 访问网页。

    网站上所有主要的导航都是使用无序列表构建的,并且在任何情况下都没有给用户造成任何导航上的困扰。

    实际上,标签有助于确保链接不会相互重叠(这可能是在 JAWS 中明确宣布链接之前),并且它也为没有打开样式表的用户进行了很好的降级,因为标准的链接列表仍然很好地分隔成唯一的项目,尽管 div 作为块也会做到这一点,但 span 等就不是这样。

    我认为,网站的无障碍功能应该可以通过所有网站的良好编码实践来实现。但是,总有一些奇怪的情况,即使是 RNIB 的家伙也一头雾水…

    我们从未找到一种方法来描述元素周期表的图形,使用 alt 或 longtext 替代方案…

  • 丹尼·墨菲
    永久链接到评论#

    如何创建一个新的导航列表元素,该元素可以被屏幕阅读器分别解释,并且在样式方面有不同的处理方式。

    <nav>
      <nl>
        <li>item one</li>
        <li>item two
          <nl>
            <li>item one</li>
            <li>item two</li>
            <li>item three</li>
          </nl>
        </li>
        <li>item three</li>
      </nl>
    </nav>
  • 安德烈亚斯·布里克斯
    永久链接到评论#

    我经常思考为什么我们会使用列表作为菜单结构,例如。
    这篇文章很有意思。
    我想知道这是否会对 SEO 有任何影响?

  • 达米安·史密斯
    永久链接到评论#

    SEO 怎么说?

    在我上一份工作中,自称是英国最好的 SEO 部门之一始终表示,无论导航列表是主要导航还是页脚导航,都需要使用 li 结构,这样搜索引擎机器人才能轻松识别主要的网站地图结构?

  • Lee Kowalkowski
    永久链接到评论#

    让我感到惊讶的是,很久以前,人们曾经使用 | 字符或其他任何字符来分隔链接,这是根据无障碍建议:http://joeclark.org/book/sashay/serialization/Chapter07.html#h1-2935

    然后,使用列表进行导航的建议也是基于无障碍功能:http://www.brucelawson.co.uk/2005/navigation-lists/

    现在我们有了 nav 元素,我们仍然使用列表:http://www.w3.org/WAI/GL/wiki/Using_HTML5_nav_element

    因此,不再使用列表的想法非常奇怪。

  • 马可·泽赫
    永久链接到评论#

    让我举一个例子,在链接列表被广泛使用无序列表进行适当结构化之前,它们听起来像什么。为了在视觉上将它们分开,它们要么是图形,要么是 80% 的 alt 文本缺失,因为特定的设计师并不在乎,要么是文本链接,要么用方括号 [] 包裹,要么用竖线 | 分隔。因此,“链接列表”可能听起来像这样,请记住,这些是如此特殊的字符,屏幕阅读器只会在最严格的简洁模式下抑制它们

    “左括号主页右括号链接” “左括号产品右括号链接”

    或者,特别是当连续阅读时

    “主页链接竖线产品链接竖线支持链接…”

    随着为这些元素传播适当的结构化标记,对于那些整天不得不他们的电脑喋喋不休的人来说,情况有了很大的改善,特别是对于文本链接来说。所有这些额外的字符都消失了,因为它们不再需要用于视觉上将两个链接彼此分隔开。

    现在,如果突然回到 span 和 div,即使被包裹在 nav 元素中,结构化标记也大多丢失了。span 不仅仅是其他文本中的文本插入,而 div 是弱的节元素。它们经常嵌套得很深,以至于传达缩进级别完全是荒谬的,因此将没有可靠的方法来清楚地传达预期。是的,这就是它归结为:意图必须清晰明了!列表标记是可靠地以明确的方式做到这一点。这不仅对屏幕阅读器很重要,而且如前所述,也需要考虑浏览器正确地解释样式、缩进(这对于各种屏幕尺寸可能很重要)等。

    在我看来,回到使用 div 和 span 来为链接组设置样式的想法,几乎和建议在布局表格中这样做一样糟糕!

    莱因哈德·斯特布纳在说链接列表不应该再使用时,肯定没有代表我的意见。我认为他只是选择了一个用户体验非常糟糕的特定网站,并从它推广,我们绝对不应该这样做。

  • 麦尔妮
    永久链接到评论#

    真是个热门话题!

    对我来说,nav 是网站上其他页面的列表。因此,我用列表标记它。一个更有趣的讨论是导航是否是有序列表。UX 会说它绝对必须按顺序排列,所以我应该使用 ol;人们很容易为相反的观点辩护。

    如果屏幕阅读器在导航列表(这似乎是常态)方面遇到了问题,那么这是软件方面的问题,而不是我们标记语义的问题。

  • 罗伯
    永久链接到评论#

    这是一个有趣的话题。我认为,如果你禁用了所有样式,页面应该以逻辑的方式呈现。在我看来,这是一个将导航链接保留在列表中的原因。一个有序列表。

  • Alan Dalton
    永久链接到评论#

    三位使用屏幕阅读器的人 - Léonie Watson、Victor Tsaran 和 Marco Zehe - 在这里表示将导航链接标记为列表很有用。

    我们还需要什么呢?

    将导航链接标记为列表。

  • 克里斯蒂安
    评论永久链接#

    如果你仔细想想,链接列表仍然是一个列表,无论你是否意识到它是一个列表。NAV 的出现并没有改变这一点。我们需要共同思考这个问题,直到我们完全理解这个正在出现的真相。我并不是说这意味着如果你不想使用 UL 元素,你就不能使用它。我的意思是,我们不应该认为 NAV 现在出现了,就意味着链接列表不再是列表了。

    此外,NAV 只能替代 <div id=”nav”>,而不是 <div id=”nav”></div> 元素中可能存在的链接列表。但也许浏览器可以使 NAV 充当“导航列表”的开头。或者,他们可以为...“导航列表”创建一个 NL 元素。也许 NL 元素可以放在 NAV 中,有点像 H1 和 H2 放在 HGROUP 中,而 HGROUP 放在 HEADER 中。或者,我们可以在 NAV 中继续使用 UL。只是不要认为链接列表不再是列表了。

  • 克里斯蒂安
    评论永久链接#

    “一个更有趣的讨论是导航是否是有序列表。UX 会说它绝对必须按那个顺序,所以我应该使用 ol;人们很容易为相反的观点辩护。”

    Mern,是的,这里解决方法是在特定情况下,如果顺序确实很重要,就将其设置为有序列表。如果顺序无关紧要,就坚持使用 UL。我两种都用过。

  • 克里斯蒂安
    评论永久链接#

    规范中说:“nav 元素不需要包含列表...”

    然后继续展示导航段落的示例。

    正确。绝对正确。如果你想让你的导航在一个段落中,那么把它放在段落中(它本身会在 NAV 元素中)。但如果它是一个列表,那么把它放在列表中(它本身仍然会在 NAV 元素中)。你不会说,“好吧,既然我们有了 NAV 元素,我就要把我的链接段落从它们之前所在的 P 元素中删除。”

  • Jennifer
    评论永久链接#

    作为一名盲人屏幕阅读器用户,我也支持使用列表,出于其他人已经提到的所有良好理由。顺便说一下,我不会夸大其词,当我教授关于网络可访问性的内容时,我会尽力让我的资格非常清晰,例如十年以上从事网络标准工作和推广网络标准。如果我要发表个人观点,我会尽量明确地表明这一点。我认为有一些方法可以询问人们他们主张的依据,以引发有价值的讨论,而不是像攻击一样。

  • 克里斯蒂安
    评论永久链接#

    听到直接受到影响的人的意见非常令人耳目一新。

  • bTrain
    评论永久链接#

    我一直在进行这场辩论大约一年了。可以说,我从事网络行业的时间并不长,而且没有接受过网络或编码的经典培训,但我也不笨,而且在大学的大部分时间都花在解决难题上。我已经做了一些研究,我发现的关于列表作为导航的唯一论点可以归结为几个类别

    语义网络:问题是,似乎没有人能够解释为什么“ul li a”是语义的,而“div span a”不是。在我看来,在接触 CSS 之前,利用 HTML 对象的自然状态来接近我们想要的结果更明智。
    屏幕阅读器:显然,这些列表对它们来说并不像有些人认为的那样有用。
    这就是它的做法:教条。我讨厌教条,如果我在执行额外的步骤来获得相同的结果,而这些结果可以用更少的步骤获得,我想知道原因。同样,没有好的解释。

    在工作中,我使用列表,因为我与其他人合作,达成共识很重要,但在家里,我永远不会使用列表作为导航,除非我想要一个看起来像项目符号列表的导航,这对我来说似乎很愚蠢。

    我提出的另一个疯狂想法是,人们似乎不太喜欢,那就是永远不要将 HTML 对象用作 jQuery 或 CSS 选择器。在我看来,这似乎是让 CSS 和 HTML 更加模块化的一种显而易见的方法。将 HTML 对象排除在选择器之外,可以让你出于任何原因更改 HTML(例如,从 span 变为 div,因为我想让一些对象堆叠起来,而无需更改所有 jQuery 和 CSS 选择器,这将非常棒)。

    再说一次,正如我之前所说,我还很新。所以,在我有时间和数据来真正测试我的这些想法之前,我会在工作中坚持惯例。

  • Pratik Patel
    永久链接到评论#

    作为一名屏幕阅读器用户,并且经常就该主题进行咨询 - 包括测试,我很高兴看到关于导航的热烈讨论。

    我同意这里其他使用屏幕阅读器的用户关于使用列表进行导航的优势。我还想指出 Stack Overflow 上一个关于导航/菜单的 ARIA 标记的实用资源。

    http://stackoverflow.com/questions/12279113/recommended-wai-aria-implementation-for-navigation-bar-menu

    我还想对建议残疾人社区应该创建自己的浏览器,以便获得最佳实现的提议做出回应。正如其他人已经指出的,这既不可取也不理想。事实上,正好相反。大多数浏览器供应商都投入了大量工作,包括可访问性。屏幕阅读器开发人员已经做了很多工作来支持这些浏览器。人们认为,创建一个“特殊”浏览器会自动解除设计人员和开发人员按照规范和最佳实践进行编码的责任。当然,事实远非如此。

    正如 Victor 指出的,有时很难理解有残疾的用户在浏览网络时所经历的困难。有时,最细微的事情可能会对浏览某个特定网站的质量产生巨大影响。我鼓励每位开发人员从 http://www.nvda-project.net 下载并使用免费的最新屏幕阅读器。当你测试你的网站时,尝试关闭你的屏幕或不要看你的设备。可以通过转到设置/通用/辅助功能/Voiceover 来在 iOS 设备上使用 Voiceover。了解交互实际上是如何发生的。这样想:你是否会测试并查看你的导航或某个特定功能的外观?那么,为什么不测试你的网站对有残疾的用户来说会是什么样子呢?

  • 迈克尔·怀特
    永久链接到评论#

    当我第一次读到这篇文章时,我气得火冒三丈,因为我以为这里又要开始,HTML 被编码员为了节省几行代码而剥夺,从而消除了多年来一直有效的东西。读完评论后,我很高兴看到理智战胜了冲动,我们听到了真正通过听觉使用网站的人们的意见。从我上面读到的内容来看,对于大多数非视障用户来说,列表似乎是访问导航项列表的完美方式。

    你看到我使用了“导航项列表”这个词吗?在九十年代初到中期,这些原始标签正在开发的时候,我还没有涉足 web 行业,但我相信 HTML 是为研究人员开发的,以便他们能够以一种开放标准的文档格式与其他研究人员共享研究报告,这种格式可以在任何操作系统上的任何设备上阅读。我相信在研究报告中,你通常会包含一个“索引”页面或目录,其中包含一个列表,显示文档的主要部分以及它们所在的页码。这正是列表的完美应用。我相信网页导航类似于目录,因此我认为从语义上讲,将导航项放在列表中是完全合理的。仅仅因为“ul”,“li” 占用几字节的额外计算机代码,就不是将其删除的理由。

    我一直喜欢用一种方式编写我的 HTML,这样它在没有应用任何 CSS 的情况下,在页面上看起来合理且逻辑,而将导航放在列表中正是这样做的。它将导航项整齐地放在一个列表中,如果你有子导航项,它们也会被很好地缩进,以显示它们与其他导航项的层次关系。

    如果它没有坏,就不要去修它。当然,这并不应该阻止创新,我们应该始终乐于寻找更好、更有效的方法来做事情,但仅仅为了改变而改变,或者仅仅为了节省几行代码而改变,这不是正确的方式。

    我的两分钱...

  • Pratik Patel
    永久链接到评论#

    @Chuck 问题是,就像所有其他用户一样,残疾人也有自己的偏好。你能期望所有浏览器中所有的浏览器功能都组合成一个单独的“特殊”浏览器吗?IBM 首页阅读器只是你建议的一种实验。由于浏览器技术和标准的快速变化,以及人们的需求差异,它无法维持——即使像 IBM 这样的大公司在背后支持它。这样做的资金从哪里来呢?然后,遵循逻辑链,为什么不为残疾人开发一个单独的操作系统呢?同样的逻辑,为什么不为极客开发一个单独的浏览器呢?因为极客以不同的方式消费内容。他们的需求不同。
    如果我们试图在浏览器中嵌入文本到语音功能,每个浏览器都会有自己的实现,这并不能解决根本问题。我们正在讨论的内容及其结构。作为这些辅助技术的使用者,我们能做的最好的事就是说服你,只要你以某种方式设计和开发你的网站和内容——以一种对所有人都有益的方式,我们就可以用我们的辅助技术来使用它。

  • 皮波
    永久链接到评论#

    嗨,克里斯!

    你看到这篇文章了吗? http://www.netmagazine.com/features/truth-about-structuring-html5-page

    这篇文章也是关于(可能?)错误地使用元素来改善屏幕阅读器的行为。我非常想知道你对这篇文章的看法。

    回到你的文章

    “更新:在询问周围的人后,你应该在 nav 标签上使用 ARIA 角色,即使它是隐含的,因为有些浏览器不会像它们应该的那样应用它。”

    我以前从未听说过。非常有趣——而且非常…令人难过!这显然是浏览器/屏幕阅读器的问题,而不是我们 web 开发人员的问题。:(我们不应该这样做。

  • 皮波
    永久链接到评论#

    @Alan Dalton

    抱歉,我认为你误解了我的意思,或者是我表达得不好,但我认为 WAI-ARIA、现代 HTML5 以及屏幕阅读器的存在绝对棒极了!现代技术很棒!我不想抱怨多打 17 个字符。我想抱怨的是,我认识的所有人(包括我自己)都认为,使用“nav”作为元素会始终默认包含“role=”navigation””作为属性。但这似乎是错误的。我抱怨的是,自从我第一次保存“nav”以来,已经过去了 2-3 年,才有人向我解释,我应该在这个元素中添加一个 WAI-ARIA 角色,因为只使用“nav”还不够。我阅读了很多博客和教程,但我之前从未听说过。

    想要做正确的事情,我也想要其他所有人都做正确的事情,但是如果 HTML5 的所有贡献者/布道者都不能向我这个“普通”web 开发者解释一些 HTML5 元素的正确行为和用法,我该怎么做呢?:(
    这也是我的错吗?当然!但我看到很多非常聪明的人也使用了这种“错误”的用法。这有点令人难过。:(

  • 皮波
    永久链接到评论#

    @Steve: 你的 MDN - ARIA 链接把我带到了另一个链接,结果是 W3C 本身有一个推荐表 (2.10.) 关于如何使用新的 HTML5 元素。现在一切都变得如此明显!

    我甚至去 html5please.com 上查看,之前我访问过那里数百次,你猜怎么着?他们说只有少数浏览器实现了正确的可访问性 API,你可以使用 polyfill 来解决这个问题。为什么我以前没看到呢?^^°

  • 克里斯蒂安
    永久链接到评论#

    来自 http://www.yourdictionary.com/list

    列表是书面或印刷的一系列项目。

    这并没有说明任何关于水平或垂直,以及每个项目是否必须在旁边有一个项目符号(或其他类似的视觉指示器)。我们需要在将样式应用于内容之前正确地表征我们的内容。有时我们甚至需要暂时从我们的脑海中删除用户代理样式表应用于我们内容的样式。换句话说,仅仅看我们的 HTML,我们的 HTML 是否正确?在说这些的时候,我并不是规定人们应该如何表征他们的内容,只是提醒我们,当“它在浏览器中的样子”决定了我们如何标记内容时,我们是在让尾巴摇晃着狗。

  • 马可
    永久链接到评论#

    使用嵌套导航是“正确”的,我做了一些类似的事情

    <nav role="navigation">
        <a><nav>...</nav></a>
    </nav>
    

    问题是:我是否应该将 role="navigation" 应用于第二个 nav,还是让它保持原样?
    我认为需要测试。
    以及其他备选方案,这是我第一个想到的。

  • Bechara
    评论永久链接#

    在 W3C 规范中,当他说我们可以,用非列表的方式标记 nav 元素时,这是很清楚的,但在他在http://www.w3.org/html/wg/drafts/html/master/sections.html#the-nav-element中自己的示例中,他放了一段代码,其中 nav 元素位于段落中,这些段落被使用,但链接并不相邻,这肯定会给屏幕阅读器用户造成问题。在上面的例子中,Chris 创建了相邻的链接,这在可访问性方面,自 WCAG 1.0 以来,在项目 10.5 – 优先级 3 中,是不建议的。

  • Ngo Khong
    评论永久链接#

    有趣的话题。从 nav 元素的定义来看,我认为它应该在没有列表的情况下使用。nav 不仅可以用于主要导航,还可以用于其他类型的导航链接,例如上一页/下一页链接,这些链接很少使用列表。因此,如果我们坚持用列表来表示 nav,我们必须将其他类型的导航链接也改为列表,我认为这很不方便。

    我更喜欢使用无列表的导航。但是,正如 Chris 提出的第一个问题,我们需要一种好的方法来实现一些东西,比如子菜单、下拉菜单等等。

  • Stephanie
    评论永久链接#

    我觉得 nav 描述的是页面上的区域,但并没有真正赋予它“结构”。在 HTML5 之前,我认为通常的做法是在任何地方使用 div,并使用适当的类/ID 来描述元素。我认为在 HTML5 之后也应该应用相同的规则。当然你有一个 nav,但它是什么?它(通常)只是一份网站页面列表。我觉得如果我们只使用 nav,而不使用任何其他结构,那么我们什么时候应该停止使用 div?文章和旁注本身就足够了吗?

    也许我的想法不对,但这只是我的个人看法。

  • Meyer
    评论永久链接#

    列表是最好的选择,屏幕阅读器可以吃大便。

  • Jack Durrant
    评论永久链接#

    当我制作我的博客的 WordPress 主题时,试图摆脱列表导航让我抓狂!我认为我是在这个网站上找到了关于如何摆脱列表元素的教程。

  • San4o
    评论永久链接#

    如果我们谈论的是屏幕阅读器,那么为什么没有人提到标签?

  • Stacey Cordoni
    评论永久链接#

    根据网页内容可访问性指南 1.0 的检查点,优先级 3 检查点 10.5 指出

    在用户代理(包括辅助技术)能清晰地渲染相邻链接之前,请在相邻链接之间包含非链接、可打印字符(用空格包围)。[优先级 3]

    http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-divide-links

    因此,提议的无列表导航(处于其当前状态)不符合要求。

    就我个人而言,我仍然在导航中使用列表,但我对找到一种更合适的方式来标记导航感到很感兴趣。

  • brad
    评论永久链接#

    对于下拉导航,我们如何看待这样的东西:http://codepen.io/bkbillma/pen/mKkEv

  • Léonie Watson
    评论永久链接#

    @Alohci
    “这其中有多少是屏幕阅读器的问题?”

    没有。在规范中,nav 元素没有被定义为集合的父元素。屏幕阅读器可以报告 nav 元素中的链接数量,但这不符合标准 – 而我们正试图让所有 UA 朝这个方向发展。

  • kartofelek007
    评论永久链接#

    HTML5 大纲怎么样?

    <nav>
    <h3 class=”screen-reader-only”>菜单</h3>
    <ul>
    …..
    </ul>
    </nav>

  • steve faulkner
    评论永久链接#

    HTML 5.1中,为 nav 元素添加了关于使用列表标记的说明。

    注意:在 nav 元素的内容表示项目列表的情况下,请使用列表标记来帮助理解和导航。

    欢迎反馈,这里列出了反馈方式

  • Rich Cook
    评论永久链接#

    如果完全愚蠢,请原谅我,但 flexbox 能否为这种菜单方法提供一些排序功能?我对这一切都是新手(不是设计师,只是想设计我的第一个网站),所以也许我在橙子篮子里放了别克,但如果你需要使用列表来导航的排序/重新排序功能,那么 flexbox 允许的 div 和其他元素的排序能否做到同样的事情?

    无论如何,这篇文章和想法很有趣。我将在我的网站上尝试一下,因为我想在我的菜单中做一些与大多数网站不同的东西。

  • AucT
    评论永久链接#

    今天我会做一些无列表导航。我喜欢水平列表,之前我一直在想,为什么不使用一组链接来进行水平导航?所以对于个人小项目来说,这很好,但如果说的是更大的东西,则需要确定它对 SEO、屏幕阅读器等等是否有效。

    顺便说一句,@brad 你的导航非常棒。

  • Andrés Roberto
    评论永久链接#

    规范还说:“在 nav 元素的内容表示项目列表的情况下,请使用列表标记来帮助理解和导航”,这很有道理。

    然而,Reinhard Stebner 的说法也正确。这是一个值得讨论和深入研究的有趣观点。

  • Cory Simmons
    评论永久链接#

    http://codepen.io/corysimmons/pen/hbndI

    我有一个主意。下载一个屏幕阅读器,学习一些控件,自己尝试一下。没有列表比不得不听“列表项 1、列表项 2、...、列表项 10”要流畅得多。

  • Loma Keasley
    评论永久链接#

    这真是一个很酷很有用的信息。我很高兴你能与我们分享这些有用的信息。请像这样继续让我们了解情况。感谢分享。

  • Vlad Malik
    评论永久链接#

    Chris,一组用 span 包裹的链接被 JAWS 识别为一个没有停顿的字符串。这绝对不是一个好主意。这适用于导航、过滤器、分页链接以及任何其他链接组。span 永远不应该用于结构化标记。span 边界没有任何意义。

    当前的 JAWS 识别 NAV 元素,并会宣布导航区域。因此,一定要将导航放在 NAV 内部。在 NAV 内部,我建议将链接放在 DIV 中,这样它们就是块级元素。JAWS 会在块级元素之后停顿。

    WCAG 建议为 A 标签添加 title 属性。我建议您详细说明,例如,“转到主页”或“导航,主页”。请使用逗号,因为逗号被读作短暂的停顿。非常有用。我确实会尝试闭上眼睛,思考它听起来会是什么样子。

    将 A 标签放入 UL 有优势。这与其说是语义问题,不如说是一些语义问题。

    优点:(1) 语义:在 UL 中,JAWS 会暂停并宣布我已进入列表,至少会告诉我接下来的项目是连在一起的;NAV 更好,但链接列表不一定是导航,(2) JAWS 将 li 标签理解为单独的项目,并在读完每个项目后停止,(3) 更多语义:如果一个列表嵌套在另一个列表中(子导航),则层次结构清晰 - JAWS 会宣布嵌套。对于嵌套导航/链接,我会倾向于使用嵌套列表。(4) 不确定人们如何使用它,但 JAWS 确实有一个快捷键,可以检测页面上的任何列表。列表更易于发现。

    对于不同的技术:我在无障碍场景中尝试过表格。它们可能非常有用。在这种情况下,您可以在表格中放置链接,列标题为“导航”,隐藏标题行,并设置表格部分的样式,使其看起来不像表格。JAWS 会宣布“表格,转到页面”。当您继续时,它会读取标题和第一个单元格的值,因此它会说“转到页面,一”。

  • Anshuman Pradhan
    评论永久链接#

    如果我们在“a”标签内放置一个 div 标签,它应该符合无障碍指南吗?

  • Chris Coyier
    评论永久链接#

    来自 Mark Harter 的评论


    我对您所写的内容以及您提到的一个盲人用户不喜欢使用列表项进行导航的演讲感到很感兴趣。

    好吧,作为一个盲人用户,也是一个程序员,我不得不不同意 Reinhold 的说法。我也使用 J.A.W.S.,它是最好的屏幕阅读器,但首先,每个盲人用户使用屏幕阅读器的方式都略有不同,以浏览网站。例如,当我浏览网站时,我会使用 J.A.W.S. 热键,我喜欢通过按键盘上的“H”来查找标题标签,这会将屏幕阅读器的焦点移动到网站的该点。因此,如果网站格式正确,网站名称将是 h1,网站部分将是 h2,等等,等等…但我还喜欢使用“E”键跳来跳去,这将找到用于搜索的表单字段。如果我按下“V”,它会带我到网站上的已访问链接,如果我已经在那里,则为“T”用于表格,“L”用于列表,等等。

    但回到使用列表进行网站导航,我认为这是明智之举,它应该是网站的第一个列表项。我喜欢将它们跨越网站徽标,或在其下方,或者在网站有左侧栏导航的情况下,在 h1 标签之后。

    但是是的,如果网站有太多列表项,它可能会变得令人困惑,但如果这些列表被正确标记,则应该不会有问题。

    自从失明并使用 J.A.W.S. 以来,在过去 10 年中我发现/了解的一件事是,网站越适合屏幕阅读器,它在谷歌、必应等搜索引擎中的索引就越好。

  • 此评论线程已关闭。如果您有重要信息要分享,请联系 我们