譯文 對無障礙網頁應用（ARIA）的選擇

標籤：狀態   over   代理   disable   hidden   down   功能   audit   分析   

//本文編輯格式為Markdown，譯文同時發布在眾成翻譯

對無障礙網頁應用（ARIA）的選擇

讓網站對每個人都能訪問是一件相當艱難的工作，尤其是在我們使用自訂標籤解決方案（custom markup solutions）的那些日子。我很高興#a11y(可訪問性的簡稱)的話題最近獲得了越來越多的關注，因為#a11y沒有什麼好的,但是正如James Williamson今天發布的twitter:

我們對提高可訪問性最大的誤解是認為那是在幫別人，但是你錯了，這是你的職責。(The biggest misconception about accessibility is that by adding it you‘re doing somebody a favor. You‘re not, you‘re doing your job.)

為了使你的網站更便於訪問，你可以使用 WAI-ARIA（無障礙網頁應用）來提供更多語義化的資訊，去支援一些訪問輔助技術。

WAI-ARIA背後的想法很偉大，但不幸的是它可能有超乎想象的使用難度。最近，我遇到了一個分頁組件（pagination component）的例子，並且我在其中發現了一個常見的錯誤，我想在這篇文章中討論一些相關的細節。

如何不（！）去使用  aria-selected

所以讓我們一起來看如下的例子：

<nav role="navigation" aria-label="Pagination Navigation">  <ul>    <li>      <a href="/page-1" aria-label="Go to Page 1">1</a>    </li>    <li>      <a href="/page-2" aria-label="Current Page, Page 2"         aria-selected="true">2</a>    </li>    <li>      <a href="/page-3" aria-label="Go to Page 3">3</a>    </li>  </ul></nav>

這個例子中的許多元素都用aria-label屬性進行了適當的標記。這是一件好事，因為一個連結如果它只包含一段數位話，它無法給盲人提供足夠多的資訊。對於盲人們來說，他們很難理解全是數位連結背後的意義。

我想深入分析的是這第二個連結。它有一個aria-selected被設定成true.這是ARIA的一個缺陷—————它很容易被弄錯。當你想要將正確的頁面標記為selected時，用它似乎有意義，但事實上這樣做並不對，對於像VoiceOver之類的螢幕朗讀輔助器並不起作用。

為了理解為什麼這樣做是不行的，我們需要理解ARIA中角色（role）的概念。

ARIA中“link”及其含義

WAI-ARIA 角色模型 是一種向輔助技術提供有關如何處理給定元素資訊的方法。

在我們的例子中，我們在處理一個錨點元素（anchor），瀏覽器會自動將它與“link”相關聯。標準的HTML元素通常有正確的角色關聯。瀏覽器知道這些元素什麼意思，並且能以最好最方便的方式對待它們。

標準的HTML元素能呈現包括適當的焦點處理、對鍵盤和點擊互動的反應。

標準標記預設情況下是可以訪問的.

所以，讓我們看一下“link”的定義 :

對內部或者外部資源的互動式引用，在被點擊的情況下，會導致使用者代理程式導航到該資源。（An interactive reference to an internal or external resource that, when activated, causes the user agent to navigate to that resource.）

可能對你而言，這個定義中並沒有什麼新的東西，但是在它的右邊，你會發現關於支援狀態以及效能的資訊，這通常是通過HTML 屬性來設定的。

使用這些你可以向輔助技術提供額外的資訊。“link”的定義列出了一系列的ARIA屬性，你可以使用像aria-label,aria-hidden或者aria-disabled等。

aria-selected 並不在其中。

那麼，什麼才是正確的用法呢？我們一起來看它的規範。

aria-selected的含義

aria-selected的定義包括:

此屬性用於單選以及多選組件。（This attribute is used with single-selection and multiple-selection widgets.）

所以關於使用aria-selected必須有一些選擇。

在處理選擇時，我首先想到了選擇元素以及選項按鈕。另一方面，連結並不提供任何選擇互動。

事實上一些“Pagination Navigation”（分頁導航）內的連結在這個例子中並不起效。當你點擊其中的一個連結通常是載入下一頁，這種情況，這裡的分頁並沒有真正的選擇互動。

aria-selected的實際用例

aria-selected 支援許多的role，包括 "tab"，這對你來說可能是新的，但你我打賭你知道你從中期待什麼。如果你看這個例子 你將會看到“tab”的用法和aria-selected背後確切的推理。

<ul class="tablist" role="tablist">   <li id="tab1" class="tab" aria-controls="panel1"      aria-selected="true" role="tab" tabindex="0">Prices</li>   <li id="tab2" class="tab" aria-controls="panel2"      role="tab" aria-selected="false" tabindex="0">Features</li> </ul>

這個例子展示了一個"tab component"（標籤組件），它是由許多控制著可見的內容的清單項目組成。這列表本身有“tablist”的role，並且每個清單項目都有“tab”來確保輔助技術知道去處理什麼。

清單項目在被聚焦的狀態下能對點擊和鍵盤導航做出反應。這是通過tabindex以及一點Javascript。這個組件總體上是易訪問的，並且為了向使用者提供關於當前哪一個tab正被選擇的附加資訊，每一個tab的aria-selected屬性都是被設定了的。螢幕助讀程式現在已經能夠識別出“selected”，因為它們能理解元素的“tab”屬性。

還有更多的內容，這裡我就不細展開了（你能在這個例子中找到解釋），但是要建立標籤的可訪問性並不像一眼看上去的那樣瑣碎。

要記住最重要的事情，aria-selected 能給選擇互動提供額外的資訊 像這個例子中當前的標籤。

開發人員工具來救援

正如你所見，處理WAI_ARIA是棘手的，但是幸好這裡有許多解決的辦法。例如，Google提供了一個非常漂亮的Chrome 拓展 ，這可以協助你發現這樣的錯誤。要檢查你的網站，你可以在開發人員工具中輕鬆運行協助工具功能審核。

除了可訪問性審核以外，這個拓展還通過可訪問性面板擴大了元素檢查。在那裡你可以看一下應用的屬性、角色，還可以看一下輔助技術是如何大聲朗讀出這個元素的。這確實很有協助，實際上我經常使用它。

總結

可訪問性處理起來可能比較麻煩，但是WAI_ARIA的規則值我們得去讀，在使用了合適的工具後，我想我們可以使網站變得更易訪問。

我希望你能喜歡這篇文章，如果你有什麼問題歡迎你能告訴我。

編輯

結果，分頁中當前頁面例子的正確屬性是WAIARIA 1.1中定義的 aria-current屬性. 不幸的是，它在寫的時沒能很好的支援。

 

譯文 對無障礙網頁應用（ARIA）的選擇