如果您在 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
属性。
所以
您怎么看?无谓的追求?有价值的讨论?
我个人已经无列表很长一段时间了。在我看到一些可靠的研究表明这是愚蠢的做法之前,我会坚持下去。和以往一样,最好的办法是向雷纳德这样的真正的屏幕阅读器用户了解更多信息。
如果我们继续使用列表,为什么它总是无序列表?我记得瑞安·辛格有一次对此大发雷霆。我们是否应该认为我们非常刻意地选择了该列表的顺序?
请务必查看 总结文章,了解这篇文章发布后我们对所有这些内容的了解。
嵌套导航呢?
我也很好奇 - 列表为子链接提供了很好的层次结构。有没有推荐的方法可以在没有列表的情况下做到这一点?
您也可以嵌套
<div>
s……但我主要好奇的是屏幕阅读器用户对此有何看法。当然,子菜单需要在 :focus 上触发。您可以在链接元素中嵌套元素,应该没有任何区别。除非您要谈论更复杂的事情?
更多地考虑自然层次结构的优势。即使没有 CSS,导航及其在列表中的子菜单也会以可用的方式显示,并且层次结构清晰可见。
有趣的话题。我确实切换到无列表的导航,但我没有真正用它做过嵌套导航。
如果我使用 <div>,这意味着它应该放在父 <a> 标签内,对吗?
我在 jsfiddle 上尝试过,嵌套的 <div> 并没有被识别为子元素,而是被识别为相邻元素。当你离开父链接时,你无法访问子导航,因为它会消失。我的代码有什么问题吗?
NAV 元素是一个分区元素。你可以简单地将 NAV 嵌套在另一个 NAV 内部,从而创建子部分(严格来说,每个 NAV 应该有一个标题,如果没有,它将得到一个隐含的“空标题”。)
@Marc Racho:在你 jsfiddle 中,你将链接 (A) 嵌套在另一个链接内,这是不允许的。
我希望我能纠正自己的回复。虽然可以将 NAV 嵌套在 NAV 内部,但显然最好使用 SECTION 来创建子菜单。
你不能将链接元素嵌套在链接元素内部。除了无效之外,这将是模棱两可的。
@Evert - 这正是我在想的东西,你不能将链接嵌套在另一个链接内部。但是是的,我误解了 Chris 关于嵌套 <div> 的说法,哈哈,它应该是像 这样。
我认为嵌套 DIV/SPAN 可能会让我们仍然处于使用 UL 和 LI 来完成此操作的相同思维模式。也许使用 NAV 的“嵌套”菜单应该更像:http://jsfiddle.net/g4kMG/1/(不过,我没有研究过这方面的任何影响)。
我使用 UL 和 LI 来创建导航菜单,因为我相信屏幕阅读器会在读出每个列表项之间停顿。如果他们在 NAV 内的链接之间停顿,那么我想这就可以了。
我很高兴你写了这个,Chris - 我也想知道为什么每个人都使用列表来进行导航,同时又花时间编写样式来删除大多数甚至所有默认的列表属性,以使它们看起来不像列表。谢谢!
顺便说一句,我同意,看起来“他们”应该将有序/无序列表重命名为编号/项目符号列表,因为正如你指出的,两者都天生以你编码它们的顺序进行排序。
称它们为“编号”或“项目符号”将它们与表示相关联 - 而不是如何处理它们的定义。
“无序”从来不意味着项目会随机显示:只是它们的显示顺序是任意的,并且重新排序它们不会对它们的含义产生任何负面影响。
是的,但不能认为“编号”列表可能意味着比表示更多,就像“有序”一样 - 意味着它们是有编号的,原因是为了表示“顺序”。使用 Adobe 产品(如 InDesign)的设计人员肯定会这样认为,因为我们正在讨论的两种类型的列表(HTML 标记中的有序和无序)被标记为编号和项目符号,大多数文本编辑器也是如此。只有在 HTML 中,我们似乎才称它们为不同的东西。当我重新排列 HTML 中的有序列表时,与我在文字文档中重新排列编号列表时一样。我甚至不明白为什么我们需要比“列表”更多的东西。让我设置一个样式,以确定我们是否使用项目符号或数字,或者使用什么,并让列表按这种方式表现,第一个 li 代表 #1 或字母 ‘A’ 或什么,……如果我关闭该样式属性,它可以回退到“项目符号”来代替数字。无论哪种情况,我都在幕后对列表进行排序。
为了记录,我同意,在用户的眼中,看到一个编号列表比仅仅看到一个项目符号列表更能表达不同的含义 - 那就是顺序确实很重要(即金、银、铜)。但是,我正在谈论的是幕后 - 在代码中,一切都是由我,开发人员,对每个列表项的排序来决定的,无论我是否使用 <ol> 或 <ul>。一个读取为铜、金、银的有序列表对于用户来说并不比一个读取为金、银、铜的无序列表更有意义。重点是,它仍然回到我,开发人员,正确地对有序和无序列表的代码进行排序。
项目符号和数字是用 CSS 应用的。当然,ol’s 自动有数字,ul’s 自动有项目符号,但 ul’s 可以有任意数量的指示符,更重要的是,ol’s 可以是 a. b. 和 c. 而不是 1. 2. 和 3.
有序和无序可能有点别扭,但它们总是正确的,无论样式如何。
这可能是一个新手评论,但为什么不能像 sass 那样在预处理中在 nav 标签内添加列表标记呢?
Sass(以及 scss 和 less 和 stylus)只处理你的 CSS。它不会触及标记。如果你想走这条路,jQuery 可能是最好的选择。
这似乎是 JAWS 浏览器可以更好地处理的事情。我猜这将是一个很常见的问题,就像今天一样。
我同意这一点......你会认为,如果使用列表是事实上的方法......那么他们应该能够处理它。你可以向 ul 添加角色,阅读器可以使用它。
JAWS 不能很好地处理导航,真是疯了?这似乎是一个重大的疏忽?
这正是我阅读本文时一直在思考的事情。我们有语义标签,正是出于这个原因。他们不应该评估他们的用户体验,并找到改进/修复这些细微差别的方法吗?这在普通网络浏览器的世界中(大多数情况下)是会发生的
我假设类似 HTML5 Shiv 的东西在 IE 的回退方面做得相当不错?
我使用列表作为菜单。因为我的网站主要用于 3D,我认为盲人不会介意是否有列表,因为他们无论如何也看不到图片。但是我可能会继续使用列表。
供参考,屏幕阅读器也用于部分视力用户,而不仅仅是盲人。并非所有部分视力用户,这取决于许多因素,但这些用户将通过他们的屏幕阅读器看到你的网站和/或收听它。
UL 比 OL 更合适,因为它不是需要按特定顺序发生的事件序列。 http://www.w3.org/TR/html401/struct/lists.html
我一直认为规范应该更改为将 Nav 元素视为一种特殊的列表。将 Nav 中的所有链接视为 NavItems 是否有意义?
我个人总是使用列表来进行导航,因为它让我感觉每个导航项都是其中的一部分。
但我真正不喜欢的是
nav > ul > li
,元素太多。为什么不直接nav > li
呢?好吧,它不是语义的,但是ul.nav > li
在 HTML5 规范方面语义性更低,因为nav
是为导航而设计的。那么计划是什么?.nav
只是一个 HTML 类名称,它没有语义,除了我们看到源代码的网页设计师和网页开发人员之外,没有意义(这里不谈论微数据,与无障碍无关)。nav
是一个 HTML5 元素,你可以向它添加任何你想要的类,它们不会改变它的语义。你的代码中添加的元素是否太多?总的来说,你可以在你的页面中添加 1 个导航,可能 2 或 3 个。更多导航非常不寻常,所以在我看来这不是什么大问题,因为它带来了很多好处。
如果你不想使用
nav > ul > li
,你可以使用nav li
,它将选择 nav 内的所有列表项。nav > li
不起作用,因为你没有 li 作为 nav 的直接子元素我喜欢这种方法。我讨厌为了适应我的导航而清除列表样式,而且我一直想知道,为什么我们社区的大多数人坚持使用这种列表导航。所以,如果我和使用屏幕阅读器阅读网页的人都可以从非列表导航中受益,为什么我不应该改变这种模式呢?我非常喜欢它,感谢 Chris 和所有帮助解决这个问题的人。
我个人喜欢 NAV 内部的 UL。但就像任何事情一样,创建导航有多种方法。
但我确实喜欢没有 UL 和 LI 元素的 NAV。各取所需。
使用 UL 作为导航过程已成为一种惯例。
我同意你的观点 Chris。自从引入 nav 元素后,语义目的就消失了,所以我放弃了使用 ul 作为导航块。NAV 内部的 ul 显得多余。
您如何编写子项代码?
这会让下拉菜单变得非常困难……哈哈。
使用嵌套 NAV 怎么样?这样就不会那么难。nav class=”top-level”,和 nav class=”sub-level”。
我只是想澄清一下关于“无序”和“有序”命名的内容。这些名称源于项目是序数还是非序数的概念。当然,任何列表都是按顺序排列的,但在某些情况下,顺序并不重要,换句话说,每个项目在列表中的位置是任意的。在某些列表中,顺序很重要,因此使用数字或字母来指定该顺序是有意义的。导航的顺序由设计师或开发人员决定,但我们通常不将导航视为序数。而前十名列表是序数的,列表中项目出现的顺序与其编号位置相关联。
我更喜欢使用列表,因为它可以免费提供很多额外的元素(它们是用于样式的句柄 - 考虑一下悬停和添加的图标),即使在非 CSS 环境中(如显示指向文档锚点的目录的 RSS 阅读器)也能很好地呈现,并且它在链接之间添加了空间,这使得在触摸设备上更容易操作,而无需进行任何样式设置。
屏幕阅读器更新起来非常慢,并且不同版本之间差异很大。我想 ARIA 可以让所有这些变得更容易,但我很久以前就放弃了当它在 Jaws 中工作时就称之为可访问或不可访问。
可访问性具有多方面,盲人用户只是其中一个需要关注的群体。例如,患有阅读障碍或学习障碍的人可能会从适当的列表结构中受益,尤其是在嵌套菜单中。当然,你可以在任何元素上使用 CSS 来实现这一点,但为什么不使用那些有效且专为列出分组内容而设计的元素呢?
再说一次,问题是:改变普遍做法有什么好处?屏幕阅读器的体验非常主观,因为我知道其他盲人用户喜欢使用键盘快捷键在列表中导航。“白板”论证也是一种品味问题。
这里的一些答案让我感到害怕。ul > li > a 并不是太多元素,它是一个正确的 HTML 结构,nav > li 并不是,因为 nav 不是列表元素。你可以在节省按键次数方面做得过火。SASS 答案也是如此 - 似乎存在一种奇怪的信念,认为 SASS 可以做任何事情。那么,它是否成为新的 PHP?:) 有些东西需要改变,而另一些东西只有在它们被破坏时才需要改变,而不是为了使用新兴技术或节省代码而破坏它们。
这也是我的第一个想法。<ul> 和 <li> 元素不仅可以组织导航的链接,还可以提供更多关于如何呈现这些链接的选择。
屏幕阅读器在访问网页时的体验始终与使用鼠标的视力正常的用户不同。可访问性的挑战不是让所有用户获得相同的体验,而是确保所有用户都能获得他们需要的 信息。如果网页对屏幕阅读器来说很混乱,因为它包含多个导航列表,这似乎更多是网页设计和组织的问题,而不是导航链接出现在列表中的问题。
基于列表的标记提供“额外”元素的想法并不是一个独特的优势。在无列表设置中使用 div 和 span 会给你同样的自由(甚至更多空间)。此外,我认为仅仅为了呈现优势而使用基于列表的设置与标准不符。
与主题相关的是,由于学习了使用 ul > li > a 设置来进行导航,我的大脑有时会将所有事物简化为“哦!这也是一个列表,因为它是一系列类似的项目!”我必须停止(惩罚)自己不去(因为)使用 ol > li > article 产生的各种零碎内容。
嗨 Chris,你写道
作为回应
同意。这让人感觉像是在为了新潮而新潮。
我认为在某种程度上应该存在某种类型的列表,让人们能够在其中放置 li 标签,并且可能包含 href 属性。默认情况下,导航意味着它实际上是一个列表。
导航是列表的原因之一是,网页不应该包含指向自身的链接,这是比较合理的做法。
在这个例子中,我们位于网站的首页,所以“首页”菜单项不是链接(
A
),但它仍然是一个菜单项(LI
)。PS:这里的评论中的 Markdown 似乎不起作用(至少对于预览来说是如此)。
哦,这里只是预览有问题。正确的代码示例
我不记得上次看到导航时,当前页面不是链接。我在面包屑中见过这种模式,但对于导航呢?
但是,要解决 Chris 标记中提出的问题,只需将当前页面用其他元素包裹起来,例如 span。或者,如果你想保持字符计数短,可以使用 i 或 b。
Marat,你不需要列表项来放置简单的非锚文本…
我可以很容易地写
首页
产品
联系我们
只使用 span…
我的意思是,认为“后续链接已经是显而易见的列表”的假设是错误的,因为有些项目不一定是链接。为了样式(表示性)目的,我们当然可以使用
SPAN
代替A
来表示非活动项目,但从语义角度来看,SPAN
中没有任何语义,因此非链接文本就完全不再是一个项目,它只是语义不明的未知目的文本。相反,列表项始终是列表项,无论其内容是链接还是非链接。Sean
例如,大多数由Art. Lebedev Studio(俄罗斯领先的网络工作室)创建的网站都使用这种模式。跟踪与当前页面完全对应的特定链接在技术上有时会有问题(这在 DOM 中非常容易,但例如,PHP 中的 DOM [实际上是最流行的服务器端语言] 存在很多错误,在实践中几乎无法使用),并且在网站的“流水线生产”中可能是不合理的,但模式本身非常合理且有用(顺便说一下,网站首页上的徽标不应该链接到其首页,原因相同)。
这是一个有趣的讨论,所以我决定稍微研究一下。我认为你在帖子中提到的担忧主要是由于页面上有多个链接列表,这会导致 SR 用户感到困惑。
最重要的是,SR 用户本身应该是最佳实践的最终权威,因此我理解为什么 Reinhard 的声明被如此认真地对待(正如它应该的那样)。
尽管如此,这里有一些值得注意的引用和链接
来自 Roger Johansson,2009 年
来自 南佛罗里达大学页面(其中还包含 VoiceOver 阅读链接列表的视频演示)
来自 Userite,一家专门从事 Web 可访问性的公司(此引用可能来自旧页面,没有日期)
此 W3C 文档建议通过列表对链接进行分组。
此宾夕法尼亚州立大学可访问性页面提供了一些关于链接组的建议,但没有说明列表。
在 WebAIM 最近的屏幕阅读器调查中,在 有问题的项目中,没有提到链接列表,尽管其他与导航相关的项目被视为有问题的。
此 WebAIM 上的旧讨论讨论了链接列表,但这是一篇旧帖子,所以我不知道它今天有多相关。
从 WebAIM 进一步了解,他们解释说,在“屏幕阅读器会通知用户一段文本(或图形)是链接”的标题下
这里是从同一页面中得出的一个有趣的小知识
同样,从实际的屏幕阅读器用户那里获得更多反馈将很棒。我认为 WebAIM 调查没有将链接列表列为有问题的项目这一点很重要,因此基于此,我不会轻易拒绝使用无序列表来链接。毕竟,不是大多数 SR 用户想要的最重要的事情吗,而不仅仅是一个人?
无论如何,我相信其他拥有更最新知识的人会在这里发表评论,我认为 Christian Heilmann 上面的评论很好,因为他建议,实际上没有完美的、一刀切的解决方案。
Lee,他说得对。跳过导航的正确目标是页面
<h1>
,这样它就会被读取。Chrome 在没有 JavaScript 的情况下不会将焦点移动到它。至少在我理解你关于发布代码的痛苦。我放了一个
<code>
,然后转义所有<
,剩下的都是正常的。Chuck,我仍在努力,我刚刚测试了一些纯 HTML 跳过导航链接,没有发现任何问题。你是说 #links 在 Chrome 中被破坏了吗?你是如何测试焦点已移动的?
啊,键盘焦点!想明白了,它仍然是一个“错误”。
为什么这(可访问性部分)仍然是一个问题?已经有一个解决方案了
https://mdn.org.cn/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_link_role
根据工作示例,
<nav>
<ul role="navigation">
<li><a href="about.html" role="link">关于</a></li>
. . .
</ul>
</nav>
也适用于 div(假设链接由 JavaScript 处理)
<div class="nav" role="navigation">
<span role="link">关于</span>
. . .
</div>
那么为什么不使用它呢?可访问性不应该是选择一种标记解决方案而不是另一种解决方案的理由。它应该只是一层额外的内容。
这是我的清单
为什么我仍然需要添加 JavaScript 才能使跳过导航工作?
为什么我不能使用为视觉浏览器设计的 CSS(
display: none
)而不用担心非视觉工具如何处理它?毕竟,还有hidden
ARIA 状态。关于这一点,为什么 CSS 甚至要提供给盲人用户?
Christian 的评论回答了这些问题:“屏幕阅读器更新起来非常慢,而且不同版本之间差异很大”。
创建非视觉“浏览器”真的很难吗?与其试图搭载视觉浏览器,不如直接创建一个。它将拥有完全的控制权,例如忽略“target=_blank”和弹出窗口。一定有人在 Webkit 或 Gecko 上工作,他们可以把一些东西组合在一起。
我认为你从来不需要使用 JavaScript 才能使跳过导航工作。
role=link 在<a>元素上不是必需的,因为它的作用已经在浏览器中映射了。只有当你 a) 试图改变本机语义,或者 b) 试图用 polyfill 来弥补缺乏浏览器支持时,ARIA 作用才在大多数元素上是必需的(参见:在 HTML 中使用 ARIA。请参阅我下面关于 Christian 关于屏幕阅读器的评论)。
@Lee:有一些非常古老的错误(现在无法查找,但我认为是在 Webkit 中),导致跳过导航对键盘用户不起作用(焦点问题)。没有 JS,你无法让跳过导航为这些用户工作。
Steve,我的观点是将 ARIA 属性视为我们处理类的方式。我们可以在 CSS 中定位标签,但如果我们定位类,标签可能会改变(例如,当更新到 HTML 5 时)。这里也是一样的。如果屏幕阅读器寻找 role=link,那么标签是什么并不重要。换句话说,使 ARIA 属性独立于 HTML/XML/WhateverML,这样所有作用都将在所有标签上都有效。它还有助于避免
<a href="javascript:void(0)">
和<a href="#">
,它们实际上并不是链接。关于你关于浏览器支持的评论,我同意。这是另一个理由说明专门用于可访问性的独立浏览器。让处理可访问性的社区拥有专门为他们需求量身定制的浏览器。这也会为开发人员提供明确的验证,以确认网站是否符合要求。
@glev:我对此表示怀疑,我的跳过导航链接一直都是纯 HTML 的
“关于这一点,为什么 CSS 甚至要提供给盲人用户?”
我可能是 80% 的盲人,阅读文本和浏览网页有困难。但视觉元素可以帮助我使用键盘/鼠标进行导航。因此,渲染 CSS 非常重要。
但我不知道这对那个受众是否重要。只是想举一个为什么 CSS 仍然被读取的例子。
我也停止使用列表来进行导航,纯粹是为了减少代码膨胀。每当我看到代码中只包含另一个元素的元素时,我都会删除它,除非有非常强烈的理由不这样做。98% 的情况下,我只需使用一个元素即可实现我需要实现的目标。我对于将<a>设置为 display: block 也感到厌倦了,仅仅是为了让可点击区域扩展到. 的边缘。对于菜单系统,我仍然会嵌套一个<ul>,但我已经解放了!这真的很令人振奋。
你不觉得网页设计师如此专注于视力障碍者有点奇怪吗?
别误会我的意思,他们能够访问网站很重要,但用于可访问性的努力与实际使用屏幕阅读器的互联网用户比例不成比例。
我完全同意。我有一位有残疾的叔叔,我确实认为他能够访问互联网非常重要。
但是,我无法理解使用或不使用列表导航的完全合理的论据。在我看来,这似乎只是意见而已。
在我看来,HTML 和我们编写它的方式~并没有问题。问题本身是屏幕阅读器。为什么我们要花这么多时间在已知有效且效果很好的事情上,而不是解决实际问题?构建更好的东西,让视力障碍者能够正确地访问现代 HTML。
我确实赞赏关于为每个人构建最佳产品的进步态度,换句话说,代码中的平等。我只是不相信 HTML 是这里真正的問題。
Jeremy Keith 最近描述了“玩数字游戏的问题”(在不同的背景下):“从百分比来看,这个群体非常小。但这不仅仅是一个数字。它是一个人。那个人很重要。”
此外,它不需要“大量的努力”。如果你写作清晰,使用 HTML 元素来实现其预期目的,清晰地呈现你的信息,并记住人们有不同的能力水平,那么你的作品将会被更多的人访问。你会感觉很好。
都是数字吗?
有多少用户仍在使用 IE8? 你从什么时候开始不再关心他们? 屏幕阅读器并不仅仅供完全失明的人使用。 他们也被有运动障碍的人使用。
此外,可访问性不都是关于元数据的吗? 你对内容的描述越详细,你的内容就越容易被消费,并在更广泛的网络中传播。
我赞同导航项的想法。 或许:ni
http://www.youtube.com/watch?feature=player_detailpage&v=QTQfGd3G6dg#t=38s
哈哈,太搞笑了!
我们是说“ni”的骑士
你需要是英国人才明白这个梗 ;)
多么有趣的电影!
克里斯,这篇文章很有趣,我将来一定会更加关注这一点!
减少导航列表听起来不错。 但是你如何处理“下拉菜单”? 尤其是带有两级或更多级的 WordPress 下拉菜单。
我甚至没有想过这个问题,并且从我使用 CSS 开始就一直使用列表作为导航。 正如克里斯蒂安·黑尔曼所说,其优点是,即使 CSS 关闭,它们也能很好地显示,并且你获得了额外的容器(UL 和 LI)用于样式目的。 如果你将所有这些与 role=”navigation” 结合起来,就应该没有任何问题。 提到的“代码膨胀”在这个语境下有点可笑(确实还有更糟糕的问题),这只是一些 UL 和 LI 而已——如果你想用链接单独对导航进行样式设置,你迟早会需要某种容器。
我同意 @Charles @ CodeConquest.com 的观点。
花太多时间只为了屏幕阅读器? 网页应该保持稳定,停止追随无用设备的每一次变化。 设备应该追随网页的演变。
(我的英语不好,请见谅)
这是一个有趣的想法,克里斯。 我要试一试,看看效果如何。
无关且离题
@Chris——我喜欢你选择停止支持 IE7 和 IE8 的事实,这是一个明智且勇敢的决定。 我认为所有面向开发人员/设计师的网站都应该遵循这种趋势,因为这样做很有道理。
虽然我喜欢这种思路,但我对子菜单导航有点担心。 列表似乎是嵌套子导航的完美方式。 当然,你可以嵌套另一个 div,但这感觉有点不对。
===
有序列表的概念不是指项目顺序与彼此相关吗? 比如一组路线,你不能随便改变顺序,否则你就无法到达目的地。
除了“主页”菜单项(我猜大多数人都会期望它排在第一位)之外,大多数导航项的顺序并不重要。
以你网站上的导航栏为例:导航方式没有规定“片段”必须排在“视频”之前。 它们完全可以颠倒顺序,并且在导航菜单的语境中仍然“有意义”。
无序列表仍然有“顺序”——在你逐条阅读时,存在第一个项目、最后一个项目,以及中间的一堆项目。 只是这些项目的顺序在理解其含义方面并不重要。
例如,你的导航菜单可以很容易地变成这样,并且仍然“有意义”
克里斯,这是一篇很有趣的文章。
role="navigation"
的建议非常有用。是的,有序列表描述了一个需要发生的序列。 导航不是这种情况。 你可能会说面包屑可能会,不过。
我参加了这次刷新活动,莱因哈德确实说他觉得将面包屑放在有序列表中是有逻辑的。
他提到的另一点是不使用列表来显示非列表内容。 他指的是那些使用无序列表来布局所有内容的糟糕 CMS。
感谢你逆流而行!
在 WordPress 中搜索了如何使用
wp_nav_menu
完成此操作的方法,但你自然是在几个月前就涵盖了这个问题:从 wp_nav_menu 的输出中删除 LI 元素如果我没记错的话,Bobby(旧的辅助功能验证工具)会将连续的超链接标记为错误,如果它们之间只有空格。 如果链接在没有应用 CSS 的情况下呈现(出于某种原因),那么你无法从视觉上辨别一个链接的结束位置和下一个链接的开始位置。 是两个词还是两个独立的链接?
那么,我们是否关心页面在没有应用 CSS 时是什么样子? 如果你关心,那么你需要在这些链接之间添加一些东西。 列表提供良好的空白,因此效果很好。
如果不使用列表,那么也许你应该在每个项目之间放置逗号,然后用 CSS 隐藏逗号?!?
我一直很喜欢使用列表作为导航菜单,你总是可以在另一个列表中放入另一个列表,以创建子菜单,这正是列表的本意。
至于屏幕阅读器? role=”navigation” 似乎是最好的解决方案……
“我的英语语法不好,请见谅”
克里斯,我同意你的观点,我很久以前就一直在这样做了。
致敬。
我继续使用无序列表作为导航链接的原因是:这是一种通过语义组织结构告诉世界(人或机器)这些链接是单个导航系统的一部分的方法。 链接的显示顺序并不重要。 但是,它们在无序列表中一起组织这一事实明确表明**这些链接在组织上是相关的**。
使用其他标记(div、span,甚至直接使用锚标签)并不能提供如此清晰的含义。 就可访问性而言,无序列表可能更麻烦,但显然,从评论来看,这个问题还没有定论,也许未来的辅助功能工具会使争论变得毫无意义。 我想从技术上讲,nav 标签也可以提供合理的组织分组,但它不像列表那样明确(因为 nav 标签也可以包含除了导航链接以外的其他内容)。
在 nav 标签内的链接集难道不能传达相同的含义,即它们是相关的,因为它们是 nav 标签的子元素,而不需要不恰当地使用列表来表示非列表内容,以此来推断关系?
@MaccG——我明白你的意思——nav 标签会自动创建列表通常会创建的组/关联。 但是,如何在 nav 标签内关联特定的链接组? 由于 nav 标签可以包含链接以外的内容(与导航相关的文本)——如何在 nav 标签内创建不同内容的语义分离?
这就是我想要表达的意思——无序列表提供了这种区别。
关于何时使用适当的 ARIA 角色(例如 role=”navigation”),我倾向于强烈依赖史蒂夫·福克纳的在 HTML 中使用 ARIA。 它是一个很好的资源(尤其是“推荐表”)。
根据这篇文章,在
<ul>
上使用role="presentation"
会怎样?这会从列表中删除语义吗?
我同意许多评论,将责任归咎于屏幕阅读器,认为它们应该以一种对受众有意义的方式解释语境上正确的和普遍的编码实践。我确信,由于这还没有做到,所以说起来容易做起来难。我以前尝试过使用屏幕阅读器浏览网页,那真是痛苦。但是,就像浏览器负责以对有能力的人有意义的方式解释标记一样,屏幕阅读器也负责以对残疾人有意义的方式解释标记。
如果 nav>ul>li>a 是普遍的、事实上的标准……那么屏幕阅读器就必须处理它!
“事实上的标准”的概念有点令人作呕。那不是标准,而是模式或趋势,告诉一小部分开发者“处理它”对他们来说是一个相当沉重的负担:“预测网络上其他人的看法,认为这是一个好的、未经文档记录的实践,这个实践可能在一年或两年内改变,或者根据开发人员的喜好而因网站而异!”我的意思是,是的,这不是一项无法克服的任务,但仍然是一个糟糕的期望。
也许我错过了,但是否有结论表明屏幕阅读器没有真正提供有意义的标记解释?我读到的是它对最终用户来说只是一个繁琐的过程。
@Vince,收到你的观点。我绝对支持标准,这次讨论很棒。我只是说,一旦开发者符合标准,他从理论上讲就完成了他的工作。剩下的就由浏览器负责以一种对他们的受众有意义和可用的方式解释该标准。
嗯……让我们再试一次
这可以正常工作
<ul role=”naviagtion”>
<li><a href=”http://www.google.com>Google</a></li>
</ul>
如果你想把它做得更花哨,可以用<nav>元素把它包起来。
但是关于文章中的整个部分,Reinhard 建议它“不能正常工作”怎么办?
@Chris - 但这是 Reinhard 代表每个使用屏幕阅读器的用户说话,还是他只是从自己的经验出发说话?一个数据点不能代表所有情况。最终我认为,这取决于辅助功能软件开发人员来创建更好的软件,而我们网页设计师和开发者则应该按照标准和最佳实践进行编码。
也许最佳实践会改变,只需将链接放在 nav 元素中,并通过将链接放在一个 section 元素中来创建“链接关联”。但就目前而言,无序列表对我来说很有效,并且提供了语义分组和组织。
有趣的谈话。
当然,这只是一个数据点。但让我们收集更多!这实际上是我见过的唯一来自实际屏幕阅读器用户的意见,这在我看来比整个由非屏幕阅读器用户组成的线程更有分量。
WebAim 已经做了一些调查 - 这是最新的调查(遗憾的是,是在 2009 年)
屏幕阅读器调查#2
尽管所呈现的数据已经超过 3 年,而且受访者人数很少(与注册的残疾互联网用户数量相比),但它仍然是一篇有趣的阅读材料。尤其是关于“存在问题的事项”的部分,该部分甚至没有提到导航项目是一个问题(是否有关于惯例的论据?)。
除了之前提到的主观性问题之外,我们还可以预期,一个人的解决方案是另一个人的问题正如 Chris Heilmann 在他场景中提到的那样,盲人和阅读障碍者的体验。
ARIA 角色会覆盖浏览器中的原生角色映射。ul 上的 role=navigation 在HTML5 中不符合标准。允许的角色值是 directory、listbox、menu、menubar、tablist、toolbar、tree 和 presentation。
我仍然认为
UL > LI > A
是导航的逻辑结构。毕竟,它仍然是一个页面列表。站点地图通常以这种方式构建,并且在视觉上也经常保持一致(在嵌套和缩进等方面),因此这似乎非常适合。如果屏幕阅读器能够区分导航列表和包含其他类型数据的列表,那就太好了,可以使用
<nav>
元素或 ARIA 角色属性来实现。换句话说,也许只读出它是导航块,然后提醒他们任何子菜单(下拉菜单)。当使用列表时,这些内容在标记中都非常清晰地呈现。我想对关于“屏幕阅读器延迟”的错误信息发表评论。通常情况下,延迟是由于浏览器未能实现适当的辅助功能支持造成的,与屏幕阅读器无关。例如,最近在 HTML 中添加了一个新元素。在过去的一周左右,它出现在 Firefox、WebKit 和 Chrome 的夜间构建版本中。JAWS、VoiceOver 和 NVDA 也在浏览器实现它的同一天支持它。为什么?与添加到 HTML 的大多数新元素不同,它的实现包括辅助功能(在浏览器辅助功能 API 中映射的角色),以及解析和样式等主流实现,因此屏幕阅读器可以立即理解它并将其含义传达给用户。请注意,由于 Chrome 中的浏览器错误,该元素当前没有以它应该具有的特定角色传达,而是以更通用的“group”角色传达。
也许我们可以呼吁 WebAIM 在他们的下一项调查中包含一个关于此问题的测试或问题?http://webaim.org/projects/screenreadersurvey4/
天哪。我完全忘记了进行实际的研究。这应该是第一次我抱怨 XHTML2 并回到 HTML 的时候吧!
从文章中“列表,10 个项目。列表,6 个项目……”
这是一个简单的 JAWS 控制。不想听到所有这些信息……就关闭它。JAWS 和大多数屏幕阅读器都有很多冗余设置。用户可以选择他们想听到的内容。而且,一个人的意见不能成为标准,那个人也不能代表整个群体。
很棒的信息!你经常使用 JAWS 吗?你能分享一篇关于如何调整这些设置的博客文章吗?你对导航方面更好的/更糟糕的标记模式,或者其他任何事情,有什么看法吗?我不想仅仅根据一个人的意见做出重大决定,但这实际上是我唯一听过来自实际使用屏幕阅读器的人的意见。
我在一所盲人学校工作。我不是盲人。我是一名视障教师,做了 10 年。我教过 JAWS。我用 JAWS 进行测试。它是一款深度软件,可高度配置……如果用户选择这么做的话。
以下是一些有用的链接,将解释一些可以配置的内容。
http://webaccessibility.gmu.edu/docs/Accessible%20Documents%20Creation/6%20HTML/Tab%205%20–%20A.%20JAWS%20and%20HTML.doc
这更具体地针对 HTML - 虽然有点过时了,但仍然是开始的良好信息。缺失的部分更多地与地标和更新的功能有关。JAWS 的版本周期大约为 12-18 个版本,并提供季度(或更频繁)的子版本和构建。
此外,许多有视力障碍(盲人和低视力)的人帮助开发了 WCAG、ATAG、UAAG、508、欧洲、澳大利亚,以及其他国家/地区的标准。这些标准并不是在真空中开发的。
还有
http://www.indiana.edu/~iuadapts/technology/software/jaws/jaws_guide.html(这更像是一个介绍)
Jim,
你能提供更多关于一些测试用例的信息吗?例如,最小优化下的 JAWS(它的反应)与中等/最大优化下的 JAWS 输出?你的帖子是我迄今为止读过最有价值的帖子。我也很好奇这件事。
谢谢
我喜欢阅读这种内容。感谢你将它整理出来,Chris。
你没有抓住重点!“有 12 组链接的页面”的问题在于它是一个设计糟糕的网页。
网页上的“链接或导航项目过多”是屏幕阅读器用户遇到的最大问题之一:http://webaim.org/projects/screenreadersurvey4/#problems 。我更希望看到一篇关于这个问题的文章。
我不同意你的说法。告诉像亚马逊、Overstock或任何拥有数百万到数十万库存的大型电子商务公司。你的理论还适用吗?导航元素是许多仍然需要它们的网站不可或缺的一部分。虽然我同意如果做得正确,少即是多,但这并不总是适用。
在过去,亚马逊(包括 .co.uk 和 .com)网站确实被 RNIB 作为不良实践的例子,但更多的是因为页面上的每个链接都被写成“点击这里”,对使用屏幕阅读器导航网站的用户毫无帮助,他们只能在链接之间跳转(链接:点击这里,链接:点击这里,链接:点击这里,无限循环)。
我查看了 Way Back Machine,想找一个例子,但很遗憾,2007年之前的快照都不工作。
这种链接设置方式在许多现代网站上仍然存在问题,但我使用隐藏的 span 来解决这个问题,当艺术作品需要使用它时,例如“链接:更多信息(关于某事),链接:更多信息(关于其他事情)”。
@David Aimi
这是一个有趣的问题。我认为我的理论确实适用。网页不需要有 12 组链接,仅仅因为公司拥有大量的库存。Luke Wroblewski 的“移动优先”演示表明,许多大型公司正在向内容更少、但更专注的网页发展。
我不是说导航元素不好。我指的是有证据表明,对于使用屏幕阅读器的人来说,链接或导航元素过多的网页是一个问题。
@Alan Dalton
我 100% 同意你所说的一切。无论设备或位置如何,如果你的网站不够简洁、实用,并且没有设计成帮助用户完成任务,那么就该重新考虑整个网站了。
列表对屏幕阅读器用户有帮助,原因有以下几点……
1. 它们充当在页面内容中导航的钩子。所有屏幕阅读器都识别列表,但只有一种(据我所知)能够识别 div,而且没有一种能够通过 span 导航。
2. 当屏幕阅读器遇到列表时,它会通知用户它包含多少项。这有助于创建即将到来的内容的心理地图,类似于快速浏览整个导航块。
3. 列表以绝对清晰的方式传达导航层次结构。嵌套列表之间的关系很容易被屏幕阅读器理解。
一些屏幕阅读器的最新版本支持 nav 元素和/或导航地标。可以通过 nav 或导航地标进行导航,复制上面提到的第一个好处(仅限于某些屏幕阅读器用户)。
HTML5/5.1 规范中唯一复制上面提到的第二个好处的元素是排序列表或无序列表。它们是唯一(在这种情况下相关)旨在表示项目组的元素。
嵌套的 nav 元素目前不受任何屏幕阅读器的支持。单个 nav 元素会被识别,但仅作为独立的实体。使用 nav 元素,无法复制上面提到的第三个好处。
@Chuck Barlow
如果你提供的第一个例子,将导航角色应用到 nav 元素,效果会更好。这将更好地反映两者之间的映射,并且还会避免 ARIA 和 HTML5 感知的屏幕阅读器重复“导航区域”样式的公告。
@Chris G
nav – ul – li 几乎可以肯定将成为未来的标准(它还需要一段时间才能普及),但所有屏幕阅读器现在都能完美地处理它。支持 nav 的屏幕阅读器会将其宣布为 nav,不支持的屏幕阅读器会将其忽略,就像它是一个 div 一样,并且在所有情况下,列表都被视为列表。
事实上,我建议将这种设计模式作为最稳健、语义上有用且支持良好的选项。
今天下午对大约 30 名屏幕阅读器用户的快速民意调查表明,许多人发现列表在这种情况下很有用。有些人说,如果导航块前面有一个标题,列表可能就不是必需的,有些人说他们更喜欢使用屏幕阅读器的功能来访问链接,但承认如果他们正在寻找特定组的链接,这将无济于事。
只是为了突出显示这段有用的文字
这正是问题所在。为什么 HTML 必须是一个因素?语言不应该有任何区别。它是一种视觉媒体,可以改变。让可访问性成为任何语言的附加层。如果使用 ARIA 属性来指示列表项,则这些项是
<li>
、<span>
或<newTagThatDoesNotExistYet>
,这并不重要。我不是建议每个标签都拥有一个 ARIA 属性。你可以有一个属性来指示哪些标签用于列表项。因此,无论你使用
<ul>
和<li>
还是<nav>
和<div>
,容器元素将拥有role=navigation nav-items=[标签名]
。可选地,如果省略,nav-items
值可以假定为第一个子元素是什么。而且,在哪里规定屏幕阅读器必须理解网页?为什么可访问性社区不能采用开源代码并创建自己的浏览器?这样就不会那么依赖于其他人来实现功能。
@Chuck Barlow
因为网页就是用它编写的。
不,它不是。
这就像在入口处有台阶的建筑物上加装斜坡:耗时、昂贵,而且有时不会完成。从一开始就设计一个可访问的东西更快、更便宜,而且更具包容性。
如果它们不理解,它们将毫无用处。
主流比隔离更好。
每个使用网络的人都会依赖于网页设计师来制作他们可以使用网页。优秀的设计师可以创造每个人都可以使用的东西。不要再用“他们”和“我们”来思考。
那么呢?如果引入了某种新的语言,也是基于标签的,我们是否必须从可访问性开始重新开始?如果它只是一个附加层,那么什么都不需要改变。将 HTML 4 -> 5 作为现实例子,但这也会应用于全新的语言。
是的,它是。XML 可能不是,但 HTML 绝对是。它最初是
<font>
、<b>
、<center>
、bgcolor
等等。现在我们有 CSS 来处理大多数视觉属性,但我们仍然有<div>
和<span>
,它们除了默认情况下如何显示以外,其他方面完全相同。屏幕阅读器甚至不会识别<span>
。同样,<em>
和<strong>
只是<i>
和<b>
的语义替换。没有理由不能在需要强调的所有情况下使用相同的标签,并使用 CSS 来区分视觉效果。除了我们有一大批开发者在争论如何最好地实现可访问性,这将需要一些时间,但会(请原谅我玩弄文字)很快提升起来。一旦建立起来,实现起来就会很简单。
它们仍然非常有用。屏幕阅读器在网络出现之前就已经存在。它们与计算机上的所有其他应用程序一起使用。
因为“主流”是所有创新的来源。拥有一个凝聚力强、灵活且由使用它们的专家制作的东西,比目前缓慢实施、不一致的屏幕阅读器和浏览器群更好。
我说的是其他浏览器开发者,而不是网页设计师/开发者。
HTML 的开始不是作为一种视觉语言。它最初是一种结构化语言。它有 i、b 和 u 元素(以及 strong 和 em),以及一个用于图像的 align 属性,允许文本围绕图像“浮动”,但仅此而已 - 请参阅 http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
其他内容后来被添加进来 - 然后在 CSS 成为主流后被移除。
我的错。我不应该把它说成好像它们都是 1.0 中的,而是应该说“我们所知道的 HTML”。然而,这些元素和
<pre>
的包含,以及该提案中存在默认渲染的事实,很好地表明视觉表示是首要考虑因素。但我显然无法确定,所以我承认这一点。@Chuck Barlow
HTML 中内置了可访问性功能,到目前为止效果还不错。使用 HTML 结构化内容是使内容可访问的第一步。此外,这一点至关重要,对于新设计师和开发人员来说,学习如何正确使用 HTML 元素比学习如何将 ARIA 应用于元素要容易。这意味着在现实情况下,他们更有可能实际使用 HTML 元素来使内容可访问,而不是在实际项目中应用 ARIA 角色。
…以及所有你能想到的任何其他主题。这并不是放弃良好实践的理由。
那只是猜测。这并没有什么用。使用语义上正确的 HTML 使信息更容易被各种残疾人访问。许多设计师和开发人员已经在这样做。我看不出有什么理由试图改变这一点。
这有多少是屏幕阅读器的失败?
对于好处 2,屏幕阅读器不能告诉用户导航(或 role=”navigation”)块中有多少个“a”元素吗?
如果屏幕阅读器理解嵌套导航,好处 3 就可以解决。
为什么我们试图修复来自数百万网站作者的标记,而这些作者实际上不会阅读这个讨论或类似内容,而是修复当今使用的少数屏幕阅读器的行为?
这不仅仅是屏幕阅读器!!!这就是原因。当链接的布局含糊不清时,普通用户也会感到困惑。如果你不小心,一个包裹的链接看起来可能像两个链接,或者连续的链接可能看起来像一个。
例如,在维基百科中,指向其他文章的链接没有下划线,看起来像指向“欧洲联盟”的链接可能令人失望地仅仅是两个链接,指向“欧洲”和“联盟”。
通常在可访问性方面,你希望添加尽可能多的语义,这样屏幕阅读器用户就可以使用快速导航键有效地在你的网站上跳转。如果你使用列表,他们可以按 L 键查看列表。我会说使用列表进行网站导航以赋予它语义,并让用户知道导航中有多少个项目。如果你不使用列表进行网站导航,我不会称之为失败,但如果你不使用列表进行像页脚中那样可见的带点的链接列表,我就会称之为失败。
不要担心屏幕阅读器的冗长,用户可以根据他们使用的屏幕阅读器来控制它。所有屏幕阅读器的工作原理都不同,如果他们在链接之前听到“列表,6 个项目”,这根本不算什么。你通过实施语义 HTML 代码完成了你的工作。屏幕阅读器软件和用户应该完成他们的工作,即控制这些内容的朗读方式。
此外,残疾人差异很大,他们可能对为他们编码的方式非常挑剔。但他们并不代表所有残疾人。很多时候你会看到人们根据“他们从这个盲人那里听到的”或“他们从这个可访问性专家那里听到的”来做出编码决定。低视力用户可能比盲人用户更加挑剔。最好的选择是遵循基于标准的编码,使用语义,并让用户及其辅助技术软件控制这些语义的呈现方式。
简而言之,冗长不是你的问题,而是 AT 和 AT 用户的问题。
我只是一个可访问性专家,我的意见基于测试和研究,但同样并非所有可访问性专家都同意我的观点。
看看当你反抗结构化标记时会发生什么?当我们决定不使用列表时,我们开始怀疑我们应该使用 div、span、paras、sections 还是其他东西。不要修好没坏的东西。:)
对我来说,作为一个屏幕阅读器用户,导航列表提供了
导航块中除了导航链接之外没有其他项目的安全性。
导航块的大小,即它有多大(不同意其他屏幕阅读器用户的观点)。
了解导航块的大小可以让我决定是继续通过选项卡浏览还是完全跳过列表(屏幕阅读器尤其允许我跳过页面上的结构化标记块)。
我希望这听起来不太直白,但…你们很多人之所以不明白,是因为你们在测试时看着屏幕。尝试闭着眼睛浏览网站,你可能会开始体会到结构化信息的重要性。
+1 为标签。
有人有蒂姆·伯纳斯·李的邮政编码吗?我要写一封深思熟虑的信。
nav 元素是一个新元素,其目的正是为了指示屏幕阅读器的导航,并允许对样式进行不同的处理。与为 XHTML2 提出的 不同,它不能有 - 作为直接后代,因为 HTML5 需要与旧内容和旧浏览器兼容。
应该是 +1 为 标签。
我个人喜欢带有 的
但是,正如你们许多人指出的那样,嵌套链接怎么办?然后是 WordPress,它使用列表,因此在主题中你仍然需要考虑列表。
不过我认为,如果该元素可以像描述列表那样工作,那将会很好,例如,我们可以有这样的内容
<nav>
<nl><a href=”link.htm”>链接 1 </a></nl>
<sl><a href=”linkA.htm”>链接 1 A</a></sl>
<sl><a href=”linkA.htm”>链接 1 B</a></sl>
<nl><a href=”link.htm”>链接 2 </a></nl>
</nav>
在这个例子中,我们可以有一个“导航链接” <nl> 和一个“子链接” <sl>。当然,这只有在理想的世界中才会出现。:)
或者像其他人建议的那样使用
我认为使用列表与否更多地取决于导航内部的类型,而不是什么是一成不变的正确答案。
如果你把它们看作标签内部的正常内容,你会把它们放在 ul 中吗?或者它只是一个元素序列。
对于简单的导航,尤其是对于简单的导航,我认为没有理由将其全部包裹在一个额外的元素中。
此外,导航有很多不同类型,所以我怀疑所有情况都有一种“正确的方式”。
tl;dr 如果是列表,那么它应该在 nav 中的列表中,但如果它只是一组链接,我看不出将其包裹在 ul 中有什么理由
具体来说,阅读完评论后,我无法理解你所提到的“倾向于使用列表”是如何实现的。
这里有一些来自 VoiceOver、NVDA 和 Windows Eyes 的测试结果
使用 ol 或 ul 的有力理由通常是
这是它在网络上大多数地方被测试和实施的方式。
这为子导航项目提供了一些有意义的层次结构。
<ul role=”navigation”> 提供与 div 和 span 解决方案几乎相同的标记。
避免使用它们的理由通常是
这消除了页面上不必要的含义。
这简化了标记并消除了不必要的元素,尤其是在面包屑和扁平导航中。
这证明了我想要/被迫使用的所有类名(并且真正缩小了 HAML 标记)。
看起来即使在使用屏幕阅读器的人群中,也存在一种偏好。只要你考虑屏幕阅读器,我认为“只有一个正确答案”的说法是错误的。
如果没有真正使用过屏幕阅读器,仅仅通过观察就很难判断,而且认为所有使用屏幕阅读器的人(或任何群体)都以特定的方式浏览或偏爱浏览互联网是一种危险的态度。
我发现很多人的评论很奇怪:“下拉菜单怎么办?”…em 怎么办!?
所以我非常喜欢这个想法,但我们如何让 WordPress 做到这一点呢?WordPress 想要将所有内容和闪烁标签都放在导航上。有什么想法吗?
作为这里的一个路标,我试图在这里保留主要的赞成/反对观点:http://codepen.io/chriscoyier/details/ztxvw
我知道 HTML5 规范中规定了这种限制,但它没有说明这种限制的来源。ARIA 规范和 W3C ARIA 创作文档都没有声称这种限制。事实上,role=navigation 被认为是一个全局属性,因此可以放置在任何地方。
这仅适用于“扁平”导航。正如我之前指出的,当你需要子菜单时,整个过程就会变得更加复杂。一个简单的例子
这甚至不是最复杂的结构。为了维护正确的 HTML5 分区结构,最好将每个菜单项和子项包装在自己的分区元素中。此外,每个分区必须有一个标题。
我想要表达的是,使用 UL 时,无论导航结构变得多么复杂,结构都保持灵活,但如果不用 UL,结构就会变得越来越复杂。
role 是一个全局属性,HTML 中唯一用于 role 的全局令牌是“presentation”。HTML5 中的符合性限制基于“强大的本机语义”和“ARIA 规范中定义的隐式 ARIA 语义”的概念。在ARIA 规范中,它指出
只是想插一句…
回到 2005 年左右,我与 RNIB 紧密合作,特别是在重建苏格兰资格认证局网站的无障碍功能时,与盲人测试用户合作。这些测试用户使用 JAWS 和 Supernova 访问网页。
网站上所有主要的导航都是使用无序列表构建的,并且在任何情况下都没有给用户造成任何导航上的困扰。
实际上,标签有助于确保链接不会相互重叠(这可能是在 JAWS 中明确宣布链接之前),并且它也为没有打开样式表的用户进行了很好的降级,因为标准的链接列表仍然很好地分隔成唯一的项目,尽管 div 作为块也会做到这一点,但 span 等就不是这样。
我认为,网站的无障碍功能应该可以通过所有网站的良好编码实践来实现。但是,总有一些奇怪的情况,即使是 RNIB 的家伙也一头雾水…
我们从未找到一种方法来描述元素周期表的图形,使用 alt 或 longtext 替代方案…
如何创建一个新的导航列表元素,该元素可以被屏幕阅读器分别解释,并且在样式方面有不同的处理方式。
这是一个选项,但它仍然是 NAV 中的一个列表,只是不同类型的 UL 列表。
我经常思考为什么我们会使用列表作为菜单结构,例如。
这篇文章很有意思。
我想知道这是否会对 SEO 有任何影响?
SEO 怎么说?
在我上一份工作中,自称是英国最好的 SEO 部门之一始终表示,无论导航列表是主要导航还是页脚导航,都需要使用 li 结构,这样搜索引擎机器人才能轻松识别主要的网站地图结构?
让我感到惊讶的是,很久以前,人们曾经使用 | 字符或其他任何字符来分隔链接,这是根据无障碍建议: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;人们很容易为相反的观点辩护。
如果屏幕阅读器在导航列表(这似乎是常态)方面遇到了问题,那么这是软件方面的问题,而不是我们标记语义的问题。
我认为这不是用户界面设计是否规定了顺序的问题,如果你从屏幕设计中进行工作,它们将以某种顺序排列,无论是有意还是无意。
我设想的一种需要用 OL 而不是 UL 进行导航的情况是,当导航被认为是一组顺序步骤时,这些步骤按顺序执行,例如购物车结账流程。他们喜欢显示所有步骤,当前步骤突出显示,之前的步骤可以导航,而接下来的步骤仅显示供信息参考。
但是,如果你只是有一些典型的页脚链接,并且屏幕设计/客户说他们绝对必须以特定顺序显示(这并不罕见),但这仍然不是使用 OL 的理由。关键是顺序对用户是否重要,而不是对作者是否重要。
@李:我同意在主导航中不使用 OL 的观点。如果顺序改变了,列表项的含义不会改变(只要嵌套始终保持嵌套)。
这是一个有趣的话题。我认为,如果你禁用了所有样式,页面应该以逻辑的方式呈现。在我看来,这是一个将导航链接保留在列表中的原因。一个有序列表。
我同意,罗伯。该网站使用 Andy Clarke 的通用样式表来处理 IE6 和 IE7,而标记为列表的链接组在这些浏览器中更容易使用 - 从视觉上看。
三位使用屏幕阅读器的人 - Léonie Watson、Victor Tsaran 和 Marco Zehe - 在这里表示将导航链接标记为列表很有用。
我们还需要什么呢?
将导航链接标记为列表。
算上下面的亚伦,一共四位,再加上提到的 30 人的投票,他们更喜欢使用列表。但也有一位不喜欢列表,并公开反对使用列表。我确实觉得所有因素都倾向于使用列表。我很快就会总结一下。
作为一个使用 Jaws 的盲人用户,我个人更喜欢将导航项目包裹在列表中。正如之前在这个讨论中提到的,它允许作者展示分层信息,并且让我快速了解有多少项目,还提供了快速在项目之间跳转的方法,并使整体感觉更有条理。但是,话虽如此,当我访问一个网站时,他们的导航是否在列表中,不太可能对我的体验产生重大影响,也不太可能对该网站是否可访问产生太大区别。
当然,使用 ARIA 后,这个问题就不那么严重了,正如已经注意到的那样,但将导航链接放在列表中确实会提供更多语义信息,这始终是件好事。
如果你仔细想想,链接列表仍然是一个列表,无论你是否意识到它是一个列表。NAV 的出现并没有改变这一点。我们需要共同思考这个问题,直到我们完全理解这个正在出现的真相。我并不是说这意味着如果你不想使用 UL 元素,你就不能使用它。我的意思是,我们不应该认为 NAV 现在出现了,就意味着链接列表不再是列表了。
此外,NAV 只能替代 <div id=”nav”>,而不是 <div id=”nav”></div> 元素中可能存在的链接列表。但也许浏览器可以使 NAV 充当“导航列表”的开头。或者,他们可以为...“导航列表”创建一个 NL 元素。也许 NL 元素可以放在 NAV 中,有点像 H1 和 H2 放在 HGROUP 中,而 HGROUP 放在 HEADER 中。或者,我们可以在 NAV 中继续使用 UL。只是不要认为链接列表不再是列表了。
我认为将导航标记为列表是正确的,但我见过其他被标记为列表的东西,我认为绝对不应该这样。最令人惊讶的是,我看到一个表单被标记为表单字段列表。列表项需要比仅仅属于同一表单更紧密地相关。也许如果有一个要捕获的列表,但事实并非如此。
是的,人们有时会弄错。更应该在我们可以的时候把它弄对。
@Christian,我对“nl”元素也有同样的想法。导航列表元素可以像 ol 和 ul 一样没有任何样式,但保持缩进,但我们真的需要另一个列表元素吗?嵌套未经样式化的 ul 会给你一个视觉上的嵌套提示(● > ○ > ■),这与处理分层导航时是一致的。我敢打赌,当有人想到 nav 元素时,他们的意图不是将导航简化为使用 nav > a + a,那样在某种程度上会失去语义,但我想这可能是主观的。
我知道他们在规范中谈到了 nav 的非列表使用,但在他们的例子中,他们也展示了使用 ul,当我更多地思考这个问题时,nav 或多或少就像 section、article 或 aside,描述了内部的内容,而不是一个简短的导航解决方案。如果你的导航没有层次结构,那么 ul 工作得很好,但在需要重要性或顺序的情况下,ol 可以成为一个很好的论据。对我来说,坚持创建导航的传统方法是有意义的。就样式而言,我创建了一个名为 _tools.scss 的小工具文件,我可以在其中轻松使用 mixin,如果我绝对必须这样做的话,该 mixin 可以删除在使用 normalize 时的一些浏览器样式。
@Lee:“最令人惊讶的是,我看到一个表单被标记为表单字段列表。”
你选择什么?
从语义上讲,一组表单字段更像一个列表(UL 和在某些情况下为 OL),而不是一个段落...甚至是一个 div...或一个 span。人们也可以为定义列表辩护。我认为用列表标记表单是语义上正确的选择。
嗨,Mern。我的惊讶纯粹是一种本能反应,我不知道是否能解释清楚,但我还是试一试。
从语义上讲,表单通常不包含字段列表。对你来说,也许可以,但对你的用户来说不是。这就像说一段文字是一个句子列表,或一个句子是一个单词列表。它们是隐式的,但不是显式的,将它们称为列表不会增加任何价值。
没有必要仅仅因为你有一个序列就在 HTML 中做任何事情,它已经可以很好地处理序列了。
虽然从实现的角度来看,使用列表来构建或处理你的文档可能很方便,但将它们作为列表呈现对你的用户没有任何好处。这就是语义元素存在的意义(你的用户)。
我会试着进一步扩展表单 != 字段列表。
一个列表(对用户有意义的列表)不仅仅是一组相关的项目,通常是相同类型的项目。表单通常不只包含一个简单的字段序列,它们有标题、标签、字段、解释性文本段落、帮助图标、表单错误消息、字段错误消息、跨字段错误消息、按钮、可能还有一个步骤列表、一个进度条、水平线(谁知道呢?)、字段集,甚至可能还有更多。
如果你认为这些东西中的一些应该在表单元素之外,想象一下,如果表单元素有一个背景,一个可爱的边框,或者,即使表单是一个纸质表单,从语义上讲,它们属于表单,对吧?
那么,如果在表单中的两个表单字段之间有一个段落,这个段落也属于列表的一部分,还是意味着你需要结束一个列表并开始另一个列表?我认为使用列表本身就毫无意义。
那么,如果不是列表,我的选择是什么?现在通常什么都没有,没有 div、span、段落、定义或任何东西,因为标签应该放在字段上方,我发现大多数布局无需任何额外的标记即可实现。HTML4.1 Strict 不允许将 input 元素作为 form 元素的直接子元素,这很烦人,但 HTML5 允许这样做。
“一个更有趣的讨论是导航是否是有序列表。UX 会说它绝对必须按那个顺序,所以我应该使用 ol;人们很容易为相反的观点辩护。”
Mern,是的,这里解决方法是在特定情况下,如果顺序确实很重要,就将其设置为有序列表。如果顺序无关紧要,就坚持使用 UL。我两种都用过。
正确。绝对正确。如果你想让你的导航在一个段落中,那么把它放在段落中(它本身会在 NAV 元素中)。但如果它是一个列表,那么把它放在列表中(它本身仍然会在 NAV 元素中)。你不会说,“好吧,既然我们有了 NAV 元素,我就要把我的链接段落从它们之前所在的 P 元素中删除。”
作为一名盲人屏幕阅读器用户,我也支持使用列表,出于其他人已经提到的所有良好理由。顺便说一下,我不会夸大其词,当我教授关于网络可访问性的内容时,我会尽力让我的资格非常清晰,例如十年以上从事网络标准工作和推广网络标准。如果我要发表个人观点,我会尽量明确地表明这一点。我认为有一些方法可以询问人们他们主张的依据,以引发有价值的讨论,而不是像攻击一样。
听到直接受到影响的人的意见非常令人耳目一新。
我一直在进行这场辩论大约一年了。可以说,我从事网络行业的时间并不长,而且没有接受过网络或编码的经典培训,但我也不笨,而且在大学的大部分时间都花在解决难题上。我已经做了一些研究,我发现的关于列表作为导航的唯一论点可以归结为几个类别
语义网络:问题是,似乎没有人能够解释为什么“ul li a”是语义的,而“div span a”不是。在我看来,在接触 CSS 之前,利用 HTML 对象的自然状态来接近我们想要的结果更明智。
屏幕阅读器:显然,这些列表对它们来说并不像有些人认为的那样有用。
这就是它的做法:教条。我讨厌教条,如果我在执行额外的步骤来获得相同的结果,而这些结果可以用更少的步骤获得,我想知道原因。同样,没有好的解释。
在工作中,我使用列表,因为我与其他人合作,达成共识很重要,但在家里,我永远不会使用列表作为导航,除非我想要一个看起来像项目符号列表的导航,这对我来说似乎很愚蠢。
我提出的另一个疯狂想法是,人们似乎不太喜欢,那就是永远不要将 HTML 对象用作 jQuery 或 CSS 选择器。在我看来,这似乎是让 CSS 和 HTML 更加模块化的一种显而易见的方法。将 HTML 对象排除在选择器之外,可以让你出于任何原因更改 HTML(例如,从 span 变为 div,因为我想让一些对象堆叠起来,而无需更改所有 jQuery 和 CSS 选择器,这将非常棒)。
再说一次,正如我之前所说,我还很新。所以,在我有时间和数据来真正测试我的这些想法之前,我会在工作中坚持惯例。
回答:这是因为 DIV 和 SPAN 本身不具有任何语义含义,并且没有应用额外的标识信息,无论是类名、ID、角色还是其他任何标识信息。前者表示“通用块级元素”,而后者表示“通用内联元素”。但 UL 和 LI 则具有很多语义含义。前者表示“无序列表”,而后者表示“列表项”。
如果你有一个链接列表,那么你就有了一个列表,然后用 HTML 将它们描述为一个列表就是正确的做法(尽管可能不是强制性的)。
“DIV SPAN A” 比 “UL LI A” 需要更多步骤。
对于那些担心有时在制作导航列表时需要撤销默认样式的人来说,使用 DIV 和 SPAN 则需要 *添加* 样式。如果你知道自己在做什么,可以使用一些快速的方法来对列表进行样式化,而不会导致代码膨胀。更重要的是,要正确地描述你的 HTML 元素, *然后* 对它们进行样式化。
6 位使用屏幕阅读器的用户在这里表示,将导航链接标记为列表很有用。
我也是。
阅读这里来自使用屏幕阅读器用户的评论。这些都是很好的解释。
克里斯蒂安
好的,我明白了,所以你假设将导航视为列表在某种程度上是有帮助的。我仍然认为,除非我希望我的导航是一个带项目符号的列表,否则将导航视为列表很愚蠢。Web 上的人们已经采用这种约定,但对我来说,这似乎是一个任意的采用。如果它在 90 年代不是任意的,那么今天肯定就是了。
对不起,你能解释一下这句话吗?我数了三个元素,这意味着构建每个元素都需要相同数量的步骤。
抱歉,你必须一直这样做,而不是偶尔。一直都这样做。每次使用列表项作为导航时,都需要使用 CSS 移除这些列表样式,并且在很多情况下需要强制它们以内联方式显示。
我不理解这句话。我们现在讨论的不是样式,而是结构。列表具有需要每次移除的样式(你可以在重置文件中添加它)。问题是,我今天看到的大多数导航栏都是水平的。如果你使用重置来移除列表样式,那么如果重置没有加载,会发生什么?你的水平列表现在会从你的样式化容器中弹出,并且会有那些难看的黑色圆点。DIV SPAN A 绕过了整个需要重置以取消样式化自然样式化列表的问题。
换句话说,如果我想要一个像这样显示的导航
首页 新闻 联系
我可以利用 HTML 对象的自然结构行为,立即实现这一点,而无需任何 CSS …… 示例(抱歉,关于有创意的 HTML 表示哈哈)
我就完成了!如果我想走列表路线,我会经历以上步骤,并且还需要处理 display: inline 和 list-style-type-none。所以,简而言之,初始化一个非列表导航需要 1 步,并且如果出现问题,不太可能破坏你的页面格式,而创建列表导航需要 2 步。据我所知,2 < 1
如果导航是一个列表,但如果不是,则不是。
问题在于,认为只有带项目符号的东西才是列表。
尽管有以上说法,但我还是读了一些屏幕阅读器用户的评论,这些评论很有道理。我认为,这对我来说最有意义
这难道不能用插件来完成吗?这似乎是一个有趣的问题,值得尝试解决。我写了一个书签,它基本上允许在浏览器中远程点击,也可以用作插件。构建一个在任何网页上都能以相同方式工作的插件是一个具有挑战性的练习,尽管 HTML 结构不同。当我在这方面变得更加熟练后,也许尝试构建一个能够智能地解析网页的屏幕阅读器,无论标记如何,都会很有趣。但这将是一些下一级的技术,我目前还做不到。(尚未)
但无论如何,屏幕阅读器的论点似乎是迄今为止我看到的唯一可行的论点。抱歉,其他论点都没有说服力,原因是我上面提到的。
样式没有加载总是有风险的。这不是列表独有的问题。
好的,感谢 Christian 向我展示了我关于列表是无缘无故地需要更多工作是正确的。从现在起,我将在我的个人项目中坚持不使用列表,甚至可能说服我的同事们列表有多愚蠢。
你似乎误解了重置没有加载的意思,因为在这种情况下,带有列表标记的水平导航可能完全无法使用,而另一个选项仍然可以使用,而没有或只有很少的样式。
我对你的行为没有个人偏见。
如果你愿意,你可以自由地将列表描述为不是列表。 *我* 不会阻止你。“列表是书写或打印的一系列项目。” 它不必是“垂直的”和“带项目符号的”才能成为列表。也可以参见 这里。
我知道你想说什么。如果人们愿意,他们可以像“重置”样式可能只失败一样地编码所有内容。最近,我一直在使用将重置/标准化样式放在我自己的样式表顶部的做法,然后如果需要,调整重置/标准化区域的值。而且很多时候它确实有效。然后,如果我的整个样式表没有加载,而只有用户代理样式表正在应用,那么如果我的 HTML 标记正确,那么该网站仍然会以逻辑方式显示。
这样说,我并不是在规定人们应该如何描述 *他们* 的内容,只是提醒我们,当“在浏览器中的外观”决定我们如何标记内容时,我们会出现尾巴摇着狗的情况。
作为一名屏幕阅读器用户,并且经常就该主题进行咨询 - 包括测试,我很高兴看到关于导航的热烈讨论。
我同意这里其他使用屏幕阅读器的用户关于使用列表进行导航的优势。我还想指出 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。了解交互实际上是如何发生的。这样想:你是否会测试并查看你的导航或某个特定功能的外观?那么,为什么不测试你的网站对有残疾的用户来说会是什么样子呢?
我假设你指的是我的评论,因为我找不到其他关于此的提及。
首先,我从来没有说过这会“解除设计人员和开发人员按照规范和最佳实践进行编码的责任”。这应该始终做到。
我想到的优势会使每个人受益。将会有一个单一的、平台无关的可访问性测试点(谁有时间和资源测试所有屏幕阅读器?)。可以创建已知可访问的本机小部件(例如日历),并且可以正确处理跳过导航(Webkit 是这里的问题制造者),以及其他一些事情。
这一建议部分基于这些结果,这些结果相当糟糕(只有 2 个获得了“绿色”分数):http://www.html5accessibility.com
如果浏览器基于 Webkit,那么其中一些贡献也可以用于其他 Webkit 浏览器。
顺便说一下,您提供的链接似乎是错误的。它应该是 http://www.nvda-project.org,而不是 .net。
我遗漏了一个重要的部分,尽管在我最初的评论中提到了,那就是浏览器也会处理文本到语音的部分。我认为这一点并不清楚。这就是单点测试可访问性的意义所在。
当我第一次读到这篇文章时,我气得火冒三丈,因为我以为这里又要开始,HTML 被编码员为了节省几行代码而剥夺,从而消除了多年来一直有效的东西。读完评论后,我很高兴看到理智战胜了冲动,我们听到了真正通过听觉使用网站的人们的意见。从我上面读到的内容来看,对于大多数非视障用户来说,列表似乎是访问导航项列表的完美方式。
你看到我使用了“导航项列表”这个词吗?在九十年代初到中期,这些原始标签正在开发的时候,我还没有涉足 web 行业,但我相信 HTML 是为研究人员开发的,以便他们能够以一种开放标准的文档格式与其他研究人员共享研究报告,这种格式可以在任何操作系统上的任何设备上阅读。我相信在研究报告中,你通常会包含一个“索引”页面或目录,其中包含一个列表,显示文档的主要部分以及它们所在的页码。这正是列表的完美应用。我相信网页导航类似于目录,因此我认为从语义上讲,将导航项放在列表中是完全合理的。仅仅因为“ul”,“li” 占用几字节的额外计算机代码,就不是将其删除的理由。
我一直喜欢用一种方式编写我的 HTML,这样它在没有应用任何 CSS 的情况下,在页面上看起来合理且逻辑,而将导航放在列表中正是这样做的。它将导航项整齐地放在一个列表中,如果你有子导航项,它们也会被很好地缩进,以显示它们与其他导航项的层次关系。
如果它没有坏,就不要去修它。当然,这并不应该阻止创新,我们应该始终乐于寻找更好、更有效的方法来做事情,但仅仅为了改变而改变,或者仅仅为了节省几行代码而改变,这不是正确的方式。
我的两分钱...
“点击了那个大大的、无形的赞按钮”
我完全同意。这里最基本的问题是“导航链接是否是一个列表?”答案绝对是肯定的。
目录是列表吗?站点地图是列表吗?无论你称之为“导航”、“菜单”还是其他什么,它都是指向你网站上页面的链接列表。为什么它会有什么不同呢?
甚至菜单的定义也是“选项列表…” (http://www.thefreedictionary.com/menu)
@Chuck 问题是,就像所有其他用户一样,残疾人也有自己的偏好。你能期望所有浏览器中所有的浏览器功能都组合成一个单独的“特殊”浏览器吗?IBM 首页阅读器只是你建议的一种实验。由于浏览器技术和标准的快速变化,以及人们的需求差异,它无法维持——即使像 IBM 这样的大公司在背后支持它。这样做的资金从哪里来呢?然后,遵循逻辑链,为什么不为残疾人开发一个单独的操作系统呢?同样的逻辑,为什么不为极客开发一个单独的浏览器呢?因为极客以不同的方式消费内容。他们的需求不同。
如果我们试图在浏览器中嵌入文本到语音功能,每个浏览器都会有自己的实现,这并不能解决根本问题。我们正在讨论的内容及其结构。作为这些辅助技术的使用者,我们能做的最好的事就是说服你,只要你以某种方式设计和开发你的网站和内容——以一种对所有人都有益的方式,我们就可以用我们的辅助技术来使用它。
嗨,克里斯!
你看到这篇文章了吗? http://www.netmagazine.com/features/truth-about-structuring-html5-page
这篇文章也是关于(可能?)错误地使用元素来改善屏幕阅读器的行为。我非常想知道你对这篇文章的看法。
回到你的文章
“更新:在询问周围的人后,你应该在 nav 标签上使用 ARIA 角色,即使它是隐含的,因为有些浏览器不会像它们应该的那样应用它。”
我以前从未听说过。非常有趣——而且非常…令人难过!这显然是浏览器/屏幕阅读器的问题,而不是我们 web 开发人员的问题。:(我们不应该这样做。
@Pipo
我们生活在一个不可思议的时代。网络使残疾人能够像其他人一样进行交流、工作、购物和社交。我们拥有一个免费的平台,可以让盲人阅读来自世界各地的新闻,而且是实时发生的——这在 1950 年代是不可想象的!即使你明天失明了,你也能够像今天一样做同样的工作,使用相同的社交网络;你不需要感到被排斥。说真的,这些东西让我震惊。以前从未有过一项技术能让这么多人参与到社会中,而不是被排斥。
你却在抱怨在网页中多打 17 个字符
重要的是,你可以做到。
关于那篇文章,只是想提醒一下(虽然我同意其中的大部分内容)。那里有一些非常基础的想法,你要带着批判的眼光去看。例如,“HTML5 风格的标题样式有点疯狂”这一部分假设标题必须是无类的,并且需要单独进行样式设置(这会加剧标题部分中关于文档大纲所概述的问题 [双关语])。
@Alan Dalton
抱歉,我认为你误解了我的意思,或者是我表达得不好,但我认为 WAI-ARIA、现代 HTML5 以及屏幕阅读器的存在绝对棒极了!现代技术很棒!我不想抱怨多打 17 个字符。我想抱怨的是,我认识的所有人(包括我自己)都认为,使用“nav”作为元素会始终默认包含“role=”navigation””作为属性。但这似乎是错误的。我抱怨的是,自从我第一次保存“nav”以来,已经过去了 2-3 年,才有人向我解释,我应该在这个元素中添加一个 WAI-ARIA 角色,因为只使用“nav”还不够。我阅读了很多博客和教程,但我之前从未听说过。
我想要做正确的事情,我也想要其他所有人都做正确的事情,但是如果 HTML5 的所有贡献者/布道者都不能向我这个“普通”web 开发者解释一些 HTML5 元素的正确行为和用法,我该怎么做呢?:(
这也是我的错吗?当然!但我看到很多非常聪明的人也使用了这种“错误”的用法。这有点令人难过。:(
@Pipo
我误解你了。抱歉!
我明白你的意思。我通常使用基于地标角色的属性选择器——[role=”banner”]{},[role=”navigation”]{},[role=”main”]{},[role=”contentinfo”]{}——来布局网页。我从未担心过需要添加角色。
这是一个好问题。我从杰里米·基思的地标角色文章中学习了。
@Pipo - 那里有资源。一个好的起点是 MDN - ARIA。这份文档:在 HTML 中使用 ARIA 为每个 HTML 元素提供指南,以及元素是否需要添加 ARIA 来弥补浏览器实现的不足。 HTML5Accessibility.com 提供了流行浏览器当前可访问性实现支持的概述。这是一个浏览器、操作系统和屏幕阅读器支持粗略指南。
@Steve: 你的 MDN - ARIA 链接把我带到了另一个链接,结果是 W3C 本身有一个推荐表 (2.10.) 关于如何使用新的 HTML5 元素。现在一切都变得如此明显!
我甚至去 html5please.com 上查看,之前我访问过那里数百次,你猜怎么着?他们说只有少数浏览器实现了正确的可访问性 API,你可以使用 polyfill 来解决这个问题。为什么我以前没看到呢?^^°
@Pipo,很高兴你找到了你想要的东西。注意:我正是包含推荐表的规范的编辑 :-)
来自 http://www.yourdictionary.com/list
这并没有说明任何关于水平或垂直,以及每个项目是否必须在旁边有一个项目符号(或其他类似的视觉指示器)。我们需要在将样式应用于内容之前正确地表征我们的内容。有时我们甚至需要暂时从我们的脑海中删除用户代理样式表应用于我们内容的样式。换句话说,仅仅看我们的 HTML,我们的 HTML 是否正确?在说这些的时候,我并不是规定人们应该如何表征他们的内容,只是提醒我们,当“它在浏览器中的样子”决定了我们如何标记内容时,我们是在让尾巴摇晃着狗。
使用嵌套导航是“正确”的,我做了一些类似的事情
问题是:我是否应该将
role="navigation"
应用于第二个 nav,还是让它保持原样?我认为需要测试。
以及其他备选方案,这是我第一个想到的。
马可,你怎么能这样嵌套导航?你不能在链接里面放链接,假设这不是无效的 HTML,你会同时点击两个链接。
阅读规范,嵌套一个 nav 元素似乎没有任何意义。它是一个分节元素,你只需要把它包裹在你的网站或页面导航周围,无论它是什么。
nav 元素是一个地标,因此作者可以对用户说“这就是导航所在”。我认为它不适合用来嵌套。
在 W3C 规范中,当他说我们可以,用非列表的方式标记 nav 元素时,这是很清楚的,但在他在http://www.w3.org/html/wg/drafts/html/master/sections.html#the-nav-element中自己的示例中,他放了一段代码,其中 nav 元素位于段落中,这些段落被使用,但链接并不相邻,这肯定会给屏幕阅读器用户造成问题。在上面的例子中,Chris 创建了相邻的链接,这在可访问性方面,自 WCAG 1.0 以来,在项目 10.5 – 优先级 3 中,是不建议的。
有趣的话题。从
nav
元素的定义来看,我认为它应该在没有列表的情况下使用。nav
不仅可以用于主要导航,还可以用于其他类型的导航链接,例如上一页/下一页链接,这些链接很少使用列表。因此,如果我们坚持用列表来表示nav
,我们必须将其他类型的导航链接也改为列表,我认为这很不方便。我更喜欢使用无列表的导航。但是,正如 Chris 提出的第一个问题,我们需要一种好的方法来实现一些东西,比如子菜单、下拉菜单等等。
我觉得 nav 描述的是页面上的区域,但并没有真正赋予它“结构”。在 HTML5 之前,我认为通常的做法是在任何地方使用 div,并使用适当的类/ID 来描述元素。我认为在 HTML5 之后也应该应用相同的规则。当然你有一个 nav,但它是什么?它(通常)只是一份网站页面列表。我觉得如果我们只使用 nav,而不使用任何其他结构,那么我们什么时候应该停止使用 div?文章和旁注本身就足够了吗?
也许我的想法不对,但这只是我的个人看法。
列表是最好的选择,屏幕阅读器可以吃大便。
当我制作我的博客的 WordPress 主题时,试图摆脱列表导航让我抓狂!我认为我是在这个网站上找到了关于如何摆脱列表元素的教程。
如果我们谈论的是屏幕阅读器,那么为什么没有人提到标签?
“dfn”标签
根据网页内容可访问性指南 1.0 的检查点,优先级 3 检查点 10.5 指出
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-divide-links
因此,提议的无列表导航(处于其当前状态)不符合要求。
就我个人而言,我仍然在导航中使用列表,但我对找到一种更合适的方式来标记导航感到很感兴趣。
Stacey。’在用户代理能清晰地渲染相邻链接之前’ 是关键。当链接在列表中时,即使是屏幕阅读器也能清晰地渲染它们。
WCAG 2.0 现在是推荐标准。它在分组链接的示例技术中使用了 UL:http://www.w3.org/TR/2012/NOTE-WCAG20-TECHS-20120103/H48.html#H48-ex5
这正是我想说的,Lee。:)
啊,原来如此!
对于下拉导航,我们如何看待这样的东西:http://codepen.io/bkbillma/pen/mKkEv
@Alohci
“这其中有多少是屏幕阅读器的问题?”
没有。在规范中,nav 元素没有被定义为集合的父元素。屏幕阅读器可以报告 nav 元素中的链接数量,但这不符合标准 – 而我们正试图让所有 UA 朝这个方向发展。
谢谢 Léonie。
如果阻止 AT 用户获得更好体验的是规范,那么规范就需要改变。nav 元素的语义似乎与被视为主要链接组一致,只是不仅仅是链接组。改变标准以使辅助工具链能够支持这一点会带来什么困难?
HTML5 大纲怎么样?
<nav>
<h3 class=”screen-reader-only”>菜单</h3>
<ul>
…..
</ul>
</nav>
在HTML 5.1中,为 nav 元素添加了关于使用列表标记的说明。
欢迎反馈,这里列出了反馈方式。
如果完全愚蠢,请原谅我,但 flexbox 能否为这种菜单方法提供一些排序功能?我对这一切都是新手(不是设计师,只是想设计我的第一个网站),所以也许我在橙子篮子里放了别克,但如果你需要使用列表来导航的排序/重新排序功能,那么 flexbox 允许的 div 和其他元素的排序能否做到同样的事情?
无论如何,这篇文章和想法很有趣。我将在我的网站上尝试一下,因为我想在我的菜单中做一些与大多数网站不同的东西。
今天我会做一些无列表导航。我喜欢水平列表,之前我一直在想,为什么不使用一组链接来进行水平导航?所以对于个人小项目来说,这很好,但如果说的是更大的东西,则需要确定它对 SEO、屏幕阅读器等等是否有效。
顺便说一句,@brad 你的导航非常棒。
这篇文章有 6 位使用屏幕阅读器的人的评论,他们都说将导航链接标记为列表很有用。我想你已经得到了答案!
参见:https://css-tricks.org.cn/wrapup-of-navigation-in-lists/
规范还说:“在 nav 元素的内容表示项目列表的情况下,请使用列表标记来帮助理解和导航”,这很有道理。
然而,Reinhard Stebner 的说法也正确。这是一个值得讨论和深入研究的有趣观点。
http://codepen.io/corysimmons/pen/hbndI
我有一个主意。下载一个屏幕阅读器,学习一些控件,自己尝试一下。没有列表比不得不听“列表项 1、列表项 2、...、列表项 10”要流畅得多。
这里有一个更好的主意:阅读这里来自实际使用屏幕阅读器的人的评论,而不是自己尝试。他们都说将导航链接标记为列表很有用。
这真是一个很酷很有用的信息。我很高兴你能与我们分享这些有用的信息。请像这样继续让我们了解情况。感谢分享。
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 会宣布“表格,转到页面”。当您继续时,它会读取标题和第一个单元格的值,因此它会说“转到页面,一”。
如果我们在“a”标签内放置一个 div 标签,它应该符合无障碍指南吗?
来自 Mark Harter 的评论
我对您所写的内容以及您提到的一个盲人用户不喜欢使用列表项进行导航的演讲感到很感兴趣。
好吧,作为一个盲人用户,也是一个程序员,我不得不不同意 Reinhold 的说法。我也使用 J.A.W.S.,它是最好的屏幕阅读器,但首先,每个盲人用户使用屏幕阅读器的方式都略有不同,以浏览网站。例如,当我浏览网站时,我会使用 J.A.W.S. 热键,我喜欢通过按键盘上的“H”来查找标题标签,这会将屏幕阅读器的焦点移动到网站的该点。因此,如果网站格式正确,网站名称将是 h1,网站部分将是 h2,等等,等等…但我还喜欢使用“E”键跳来跳去,这将找到用于搜索的表单字段。如果我按下“V”,它会带我到网站上的已访问链接,如果我已经在那里,则为“T”用于表格,“L”用于列表,等等。
但回到使用列表进行网站导航,我认为这是明智之举,它应该是网站的第一个列表项。我喜欢将它们跨越网站徽标,或在其下方,或者在网站有左侧栏导航的情况下,在 h1 标签之后。
但是是的,如果网站有太多列表项,它可能会变得令人困惑,但如果这些列表被正确标记,则应该不会有问题。
自从失明并使用 J.A.W.S. 以来,在过去 10 年中我发现/了解的一件事是,网站越适合屏幕阅读器,它在谷歌、必应等搜索引擎中的索引就越好。