推薦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實施導航欄/菜單

回答

相關問題