推荐WAI-ARIA实施导航栏/菜单

我们正在实施（即添加）WAI-ARIA支持到门户网站的主导航菜单。菜单是这里所示：推荐WAI-ARIA实施导航栏/菜单

Navigation menu screenshot

菜单是由经典<ul>/<li>/<a> DOM树来实现，用CSS看起来像水平制表风格。

对于这样一个小部件，推荐的WAI-ARIA实现是什么？

我打算在这里发布一个可能的实现作为答案，以便让事情顺利进行。

如果您知道/不关心WAI-ARIA上下文中的CSS导航菜单，请跳过其余段落。

序言（这么说）

我读过从w3org最近WAI-ARIA规范的许多地方的一般理解，分类，等等。然后，我已阅读了有关UI小部件实现的几个示例。在这样一个CSS导航菜单中，我找不到任何特别针对目标的例子。我一直发现的最接近的小部件是Menu，MenuBar和TabPanel。当然，我也看过Free ARIA Community group（这个问题最初是在这里发布的）。

我会说，没有这些小部件完全匹配（CSS）导航菜单。例如，TabPanel可以控制页面中的一些内容（ - > aria-controls），也可能是MenuBar;但我不确定导航菜单是否控制页面中的内容（它控制着要显示的下一页）。没有更进一步，还有一些其他的差异。参考文献在帖子末尾。如果有人认为导航菜单更好（或更适合），我们很乐意了解它们。

参考

来源

2012-09-05 superjos

一个可能的实现是：

HTML结构：

<div> <!-- Outer wrapper --> 
    <ul> <!-- Main navigation bar container --> 
    <li> <!-- First-level item without submenu --> 
     <a> <!-- Destination URL --> 
     </a> 
    </li> 
    <li> <!-- First-level item with submenu --> 
     <a> <!-- Destination URL --> 
     </a> 
     <ul> <!-- Second-level menu container --> 
     <li> <!-- Second-level item --> 
      <a> 
      </a> <!-- Destination URL --> 
     </li> 
     </ul> 
    </li> 
    </ul> 
</div>

角色：

角色=”导航”为外包裹<div>
角色= “菜单栏” 为<ul>导航栏容器
角色=对第二级 “菜单” <ul>容器
角色= “呈现”对于第一级和第二级<li>菜单项（它们在暴露的可访问菜单栏结构中不需要）
role =“menuitem”用于第一级和第二级<a>菜单项

属性：

咏叹调-haspopup = “真” 用于具有子菜单
咏叹调-labelledby =用于二线 “先前<a>菜单项的ID” 第一级<a>菜单项水平<ul>容器

国：

aria-selected =“true”对当前访问的第一级或第二级<a>项目;咏叹调选择=“假”在其他<a>项目。即强制的概念“选择< ==>当前页”
咏叹调发泡=“真/假”为第二级<ul>容器
咏叹调隐藏=“真/假”为第二级<ul>集装箱
aria-activedescendant =“”主<ul>导航栏容器。这是替代使用tabindex
tabindex = 0当前访问<a>项目;其他<a>项目的tabindex = -1。这是为了首先将焦点放在当前页面上，然后切换到导航栏。这是与唱段，activedescendant

键盘的另一种方法：

标签：移动焦点/ Web应用程序中出菜单从其他点。
Shift + Tab：按照相反顺序将焦点从Web应用程序中的其他点移入/移出菜单。
向右箭头：一个导航栏项目
向左箭头：一个导航栏项目
输入：激活当前焦点项（即定位到相应的URL）
空间：激活当前焦点项（即定位到相应的URL）

月/ 2014：咏叹调选Vs的菜单项

在回答@Joshua Muheim评论：现在的我可以看到from here以及his reference，即aria-selected属性不允许为menuitem的角色。
当我从最近的SO answer中读到的时候，有些解决方案给出了事物的当前状态，并且还有一个新的建议属性。

来源

2012-09-05 10:15:33 superjos

我几乎已经准备好放弃咏叹调规格，直到我读到你的答案。对我来说，这是我在菜单中缺少的“演示文稿”角色，导致出现奇怪的行为，例如每个菜单项被读作“1之1”而不是“1 [长度]”。我在网上看到的大多数例子都会导致这种不受欢迎的行为，除了你的回答之外，我还没有发现任何说'ul [role = menu]> li [role = presentation]> [role = menuitem]。做得好。 –

实际上，当我尝试使用'ul [role = menu]> li> a [role = menuitem]'时，“1的1”问题。可以肯定的是，大多数人都在推荐'ul [role = menu]> li [role = menuitem]> a'，这根本不起作用！它会读取菜单项，但由于没有链接集中，你不能去任何地方。 –

很高兴帮助！据我所知，每当你为* aestetichal *目的插入一些（嵌套的）节点，即定位，显示/隐藏，背景着色等时，就需要xxx [role = presentation]。但是这些节点对于* content *的观点来说没有任何意义，因此您将它们标记为任何可访问性工具。 – superjos

+ Escape键应关闭打开的菜单并将焦点返回到打开它的元素。

来源

2013-08-30 19:20:25 user810937

自从我最后一次想到这些功能以来，已经有一段时间了。乍看之下，使用Escape键关闭打开的菜单看起来非常合适（我不记得我是否已经在我的搜索过程中看到过这些内容）。我不确定使用Esc关闭菜单后会发生什么情况：您的建议（将焦点返回到打开它的元素）对我来说似乎并不合适。 – superjos

Escape是关闭的标准。 http://access.aol.com/dhtml-style-guide-working-group/#menu – user810937

作为供参考，您可以通过将aria-posinset和aria-setsize属性添加到具有role = menuitem的元素来获得一个菜单，以通告'Y的X'信息。此致敬礼布赖恩格拉文达

来源

2013-12-07 06:40:40

感谢分享。我认为如果菜单DOM改变的话可能对他人有帮助。我可以从[这里]（http://www.w3.org/TR/wai-aria/states_and_properties#aria-posinset）读取“如果集合中的所有元素都存在于DOM中，则不需要” – superjos

逃避关闭是一个标准的回归方式，它是许多用户的预期行为。

来源

2014-08-20 20:03:34

的ARIA设计模式提供预期的大量自定义的UI行为控制http://www.w3.org/TR/wai-aria-practices/#aria_ex使用ESC键的关闭并返回到在接近触发因素是跨桌面和Web标准的UI。在任何Google文档应用中尝试（例如）。

来源

2014-08-20 20:45:52

只是一点点迟到：谢谢你的补充，福克纳先生 – superjos

推荐WAI-ARIA实施导航栏/菜单

回答

相关问题