ARIA：毒藥或抗圓點？

Aaron Leventhal
Aaron Leventhal
X

什麼是 ARIA？

ARIA 可讓網頁作者建立另一種現實，只有螢幕閱讀器可看到。

有時您可能需要向螢幕閱讀器提供更多資訊，甚至是「謊言」，讓他們瞭解網路內容中的內容。例如：「焦點已經來到了！」或「這實在是滑桿！」。就像在工作台上，在工具和小工具上加上神奇的便利貼。這些神奇的便利貼會讓所有人相信上面寫的內容。

當神奇的便利貼出現時，它會覆寫我們對每個工具的認知或功能。舉例來說，如果您新增 ARIA，指出「這個東西是膠水槍！」雖然它只是一個空的藍色盒子，但神奇的便條紙會告訴我們它是膠水槍。我們也可以加上「而且已滿 30%！」螢幕閱讀器現在會回報膠水槍已充飽 30%。

網路上的等效做法是使用內含圖片的一般 div，並使用 ARIA 說明這是滑桿，值為 100 的 30。ARIA 不會將 div 設為滑桿，只會告訴螢幕閱讀器，讓螢幕閱讀器將其視為滑桿。

ARIA 不會影響網頁的外觀，或滑鼠/鍵盤使用者的行為。 只有輔助技術的使用者會注意到 ARIA 的影響。網頁開發人員可以新增任何任意 ARIA，而不影響未執行輔助技術的使用者。

您應該已經知道了：ARIA 並未對鍵盤焦點或分頁順序執行任何動作。這全都是透過 HTML 完成 有時需要經過一些 JavaScript 調整

ARIA 的運作方式為何？

螢幕閱讀器或其他輔助技術會要求瀏覽器提供每個元素的相關資訊。當元素顯示 ARIA 時，瀏覽器會擷取資訊，並變更螢幕閱讀器針對該元素顯示的資訊。

以下是 ARIA 的常見用途。

  • 新增 HTML 中不存在的特殊元件，例如自動完成建議、樹狀圖或試算表。
  • 新增 HTML 中已存在的元件，但作者決定重新設計，可能是因為他們想變更標準元素的行為或外觀。舉例來說，HTML <input type="range"> 元素基本上是滑桿，但作者想讓它看起來不一樣。
    • 在大多數情況下，你都可以透過 CSS 解決這個問題。不過，對於 range，CSS 會變得相當不自然。作者可以自行製作滑桿，並使用 role="slider" 搭配 aria-valuenow，告訴鍵盤目前的值。
  • 加入即時區塊，讓螢幕閱讀器瞭解網頁區域的相關變更。
  • 建立地標，例如標題。地標可協助螢幕閱讀器使用者更快找到所需內容。地標可包含整個相關區域。例如：「這個容器是網頁的主要區域」和「這個容器是導覽面板」。

為什麼要使用 ARIA？

在已運作的 HTML 中加入一些 ARIA 可能會很有幫助。舉例來說，我們可能會希望表單控制項指向無效輸入內容的錯誤訊息警示。或者，我們可能想指出文字輸入的具體用途。這些調整可讓一般網站更適合透過螢幕閱讀器使用。

假設當地網路商店沒有販售我們需要的所有小工具，但是，我們稱之為 MacGyver。我們可以利用其他小工具來發明自己的小工具！這與需要建立選單列的網頁作者相當類似。

雖然 <nav> 元素存在，但選單列通常會使用 div、圖片、按鈕、點擊處理常式、按鍵處理常式和 ARIA 拼湊在一起。

支援滑鼠使用者

我們一起來製作選單列吧！我們會在名為 div 的一般方塊元素中顯示多個項目。每當使用者點選 div 時，系統就會執行對應的指令。太棒了，這對使用滑鼠點擊的使用者來說很實用！

接下來，我們要讓畫面看起來更美觀。我們使用 CSS 將元素整齊排列，並在元素周圍加上視覺輪廓。我們讓這項功能看起來與其他選單列相似，讓視障人士能直覺地知道這是選單列，以及如何使用。我們的選單列甚至會在滑鼠游標經過的任何項目上使用不同的背景顏色，為使用者提供實用的視覺回饋。

部分選單項目是父項。他們會產生子選單。每當使用者將滑鼠游標懸停在其中一個時，我們就會啟動動畫，將子選單滑出。

這一切都很難存取，這也是網路上許多內容的常態。

讓選單列的鍵盤更易於使用

我們來新增鍵盤無障礙功能。這項作業只需要修改 HTML，而非 ARIA。請注意，ARIA 不會影響外觀、滑鼠或鍵盤等核心層面，這些層面適用於沒有輔助技術的使用者。

就像網頁可以回應滑鼠一樣，也可以回應鍵盤。我們的 JavaScript 可以監聽所有按鍵動作，並判斷按鍵是否有用。如果不符合，就會像是丟回頁面，就像魚太小而無法食用一樣。我們的規則如下：

  • 如果使用者按下方向鍵，我們就會查看內部選單列藍圖，並決定新的有效選單項目應為何。我們會清除目前的任何醒目顯示，並醒目顯示新的選單項目，讓視障使用者知道目前所在位置。網頁接著應呼叫 event.preventDefault()，以免瀏覽器執行一般動作 (在本例中為捲動網頁)。
  • 如果使用者按下 Enter 鍵，我們可以將其視為點擊，並執行適當的動作 (甚至開啟其他選單)。
  • 如果使用者按下應執行其他操作的按鍵，請將該按鍵傳回頁面。舉例來說，我們的選單列不需要 Tab 鍵，因此請將它移除！這很難正確判斷。舉例來說，選單列需要方向鍵，但不能使用 Alt + 方向鍵或 Command + 方向鍵。這些是瀏覽器分頁網頁瀏覽記錄中，用於前往上一個和下一個網頁的快速鍵。如果作者不小心，選單列就會吃掉這些內容。這類錯誤經常發生，而且我們甚至還沒開始使用 ARIA！

螢幕閱讀器可存取我們的選單列

我們的選單列是使用膠帶和 div 建立的。因此，螢幕閱讀器無法判斷任何內容。活動項目的背景顏色只是一種顏色。選單項目 div 只是沒有特定意義的純物件。因此，使用者在選單列中不會收到任何操作說明，不知道要按哪個按鍵或選取哪個項目。

但這不公平！選單列對視障使用者來說運作正常。

ARIA 可解決這個問題。ARIA 可讓我們假定聚焦在選單列中的螢幕閱讀器。如果作者一切操作正確，自訂選單列在螢幕閱讀器中看起來就會像是電腦應用程式中的選單列。

第一個 ARIA 屬性是 aria-activedescendant。將屬性設為有效選單項目的 ID，並小心在 ID 變更時更新。例如：aria-activedescendant="settings-menuitem"。這會導致螢幕閱讀器將 ARIA 有效項目視為焦點，並朗讀或顯示在點字顯示器上。

說明祖系、父系和子系

子項一詞是指某個項目包含在另一個項目的某處。相反的詞彙是祖系，意指項目包含祖系。至於下一個容器向上/向下，則可能會使用更具體的父項/子項字詞。舉例來說，假設文件中有一個內含連結的段落，連結的父項是段落，但也包含文件做為祖系。相反地，文件可能包含許多段落子項，每個子項都含有連結。這些連結都是祖父文件的子項。

使用 aria-activedescendant 從聚焦的選單列指向特定選單項目，螢幕閱讀器現在就會知道使用者移動的位置，但不會知道物件的其他資訊。這個 div 是什麼東西？這時角色屬性就能派上用場。我們在整個內容中加入 role="menubar"，然後針對項目群組使用 role="menu"，並針對個別選單項目使用 role="menuitem"。

如果選單項目可導向子選單，使用者必須知道這一點。對於視障使用者而言，選單結尾處可能會顯示一個小小的三角形圖片，但螢幕閱讀器至少在目前階段不支援自動讀取圖片。我們可以在每個可展開的選單項目上新增 aria-expanded="false"，表示有可展開的項目，但並未展開。此外，作者應在 img 三角形上放置 role="none"，表示該圖片僅供美容用途。這可避免螢幕閱讀器重複說明圖片。

修正鍵盤錯誤

雖然鍵盤存取權是核心 HTML 的一部分，但很容易被覆寫。例如：

  • 核取方塊使用空格鍵切換，但作者忘記呼叫 preventDefault()。空白鍵現在會切換核取方塊，並將頁面向下移動，這是空白鍵的預設瀏覽器行為。
  • ARIA 模式對話方塊會在其中捕捉分頁導覽。如果作者未明確允許 Control + Tab 鍵在對話方塊中開啟新分頁，將無法正常運作。
  • 作者建立選取清單，並實作向上和向下鍵。不過，作者仍需要新增「Home」、「End」、「PageUp」、「PageDown」或「FirstLetter」導覽功能。

作者應遵循已知的模式。詳情請參閱「資源」一節。

針對純鍵盤存取問題，您也可以嘗試在沒有螢幕閱讀器的情況下，或在關閉虛擬瀏覽器模式的情況下進行測試。您可以在沒有螢幕閱讀器的情況下發現鍵盤錯誤，因為鍵盤存取功能是使用 HTML 而非 ARIA 實作。畢竟 ARIA 不會影響鍵盤或滑鼠的行為，而是向螢幕閱讀器說明網頁內容、目前焦點等。

鍵盤錯誤通常都是網頁內容的錯誤，特別是在 HTML 和 JavaScript 中，而不是在 ARIA 中。

為什麼會有這麼多？

作者可能會透過多種方式導致 ARIA 錯誤。每個錯誤都會導致整個破裂或細微差異。作者不太可能在發布前發現這些問題，因此隱晦的問題可能更嚴重。

畢竟，除非作者是經驗豐富的螢幕閱讀器使用者，否則 ARIA 一定會出錯。在我們的選單列範例中，作者可能會認為在「menuitem」正確時，應使用「option」角色。他們可能忘記使用 aria-expanded，忘記在適當時機設定並清除 aria-activedescendant，或忘記提供包含其他選單的選單列。那麼選單項目數量呢？通常螢幕閱讀器會以「5 項中的第 3 項」之類的字詞呈現選單項目，方便使用者瞭解所在位置。瀏覽器通常會自動計算這項資訊，但在某些情況下，以及在某些瀏覽器和螢幕閱讀器組合中，可能會計算出錯誤的數字，作者必須使用 aria-posinset 和 aria-setsize 覆寫這些數字。

而這只是選單列。想想有多少種小工具。如有需要，請參閱 ARIA 規格或作者實作方式。每個模式都有十幾種 ARIA 濫用方式。ARIA 會依作者的操作來判斷他們正在執行的動作。如果大多數作者都不是螢幕閱讀器使用者，則可能的問題可能是什麼？

換句話說，在將 ARIA 小工具視為可發布的前，實際的螢幕閱讀器使用者必須試用這些小工具。存在太多細微差異。理想情況下，您應嘗試使用多種不同的瀏覽器-螢幕閱讀器組合，因為除了少數未完成的實作外，實作方式有許多異常。

摘要

ARIA 可用於覆寫或新增至 HTML 顯示的所有內容。您可以對無障礙呈現方式進行小幅變更，或是建立完整體驗。因此，ARIA 既強大又危險，因為開發人員可能不是螢幕閱讀器使用者。

ARIA 是一種標記層，會覆寫其他選項。當螢幕閱讀器詢問發生了什麼事時，如果有 ARIA，使用者就會收到 ARIA 版本的真實資訊。

其他資源

W3C 的 ARIA 撰寫實務文件中，記載了每個範例的重要鍵盤導覽特性，並提供可用的 JavaScript、CSS 和 ARIA。這些範例著重於現行可行的做法，不涵蓋行動裝置。

什麼是 Accessibility API？

無障礙 API 是螢幕閱讀器或其他輔助技術瞭解網頁內容和發生事件的方式。例如 MSAA、IA2 和 UIA。Accessibility API 包含兩個部分：

  • 代表容器階層的物件「樹狀結構」。舉例來說，文件可以包含多個段落。段落可以包含文字、圖片、連結和文字修飾。物件樹狀結構中的每個項目都可能包含屬性，例如角色 (我是什麼？)、名稱或標籤、使用者輸入的值、說明，以及布林狀態，例如可聚焦、已聚焦、必要、已勾選。ARIA 可以覆寫這些屬性。
    • 螢幕閱讀器可透過樹狀結構協助使用者在虛擬緩衝區模式中進行瀏覽，例如「go to the next heading, please」。
  • 一系列事件，用來描述樹狀結構的變更，例如「現在是焦點！」。螢幕閱讀器會使用事件，告訴使用者剛剛發生了什麼事。當重要的 HTML 或 ARIA 標記變更時，系統會觸發事件來告知螢幕閱讀器已變更內容。

HTML 是與這些無障礙 API 的最佳對應。如果 HTML 不夠，您可以新增 ARIA，讓瀏覽器在將物件樹狀結構或事件傳送至螢幕閱讀器前，覆寫 HTML 語意。