ARIA 角色與屬性：最佳選擇比較

W3C WAI-ARIA 1.2 規範中的 ARIA 角色和屬性 超過一百個，但其中少數即可解決 XHTML 和 CSS 小部件中的大部分可存取性問題。角色定義元素是什麼，屬性定義其狀態或關係，但 ARIA 不會修改瀏覽器的行為：每個新增的角色都要求使用 JavaScript 實作互動。

可存取的富互聯網應用程式 (ARIA) 是一種 W3C 規範，它將語義添加到本機形式中沒有的 HTML 元素中。角色描述元素是什麼（「按鈕」、「選項卡」、「對話方塊」），而屬性則描述其「狀態」或「關係」（「aria-expanded」、「aria-controls」、「aria-labelledby」）。 W3C 在 使用 ARIA 中發布的 ARIA 的第一條規則很直白：如果有一個原生 HTML 元素已經可以完成這項工作，請使用它並且不要添加 ARIA。

原因是 ARIA 不會修改瀏覽器行為。 <div role="button"> 不會透過 Tab 獲得焦點，不會回應 Enter 鍵或空格，並且不會隨表單一起提交。它只會改變輔助技術所宣告的內容。所有互動都必須使用 JavaScript 實作並仔細管理。在 XHTML/CSS 專案中，HTML 是靜態的，JS 是最少的，這意味著新增的每個 aria 角色和屬性都是您的程式碼必須履行的承諾。

ARIA 的第二條規則要求不要改變本機語意，除非絕對必要。 <h2 role="tab"> 會破壞標題的結構，並使按區域導航的螢幕閱讀器感到困惑。第三條規則要求所有 ARIA 控制都可以透過鍵盤操作。第四個要求不要在獲得焦點的元素上使用 aria-hidden="true"。第五個，也是最容易被遺忘的，提醒我們任何互動元素都需要一個可訪問的名稱：沒有標籤的角色是一個靜音按鈕。

如何選擇：標準在清單之前

選擇角色或屬性不是品味問題。按順序應用這些標準可以避免有關 aria 角色和屬性的大多數錯誤：

1. **是否有原生 HTML 元素？ ** 如果有，請使用它。 <button>、<details>、<dialog>、<input type="checkbox"> 涵蓋的情況比人們想像的要多。
2. **小工具需要動態狀態嗎？ ** 如果它在開啟/關閉、選擇/未選擇或展開/折疊之間變化，則需要狀態屬性（aria-expanded、aria-selected、aria-pressed）。
3. **是否需要元素之間的關係？ ** 關係屬性（aria-controls、aria-labelledby、aria-describedby、aria-owns）連接可訪問性樹無法從 DOM 推斷的部分。
4. **是否需要即時公告？ ** 即時區域（aria-live、role="status"、role="alert"）在不移動焦點的情況下解決更新。
5. **我可以維護它嗎？ ** 沒有鍵盤或螢幕閱讀器測試的複雜 ARIA 模式比什麼都沒有更糟。

維護成本是最容易被忽略的標準。一個精心製作的“role=”tablist“”需要箭頭鍵管理、旋轉“tabindex”、“aria-selected”和“aria-controls”的同步以及正確隱藏非活動面板。如果團隊無法處理這個問題，則一組帶有錨點的連結更容易存取且更便宜。

相關： UserWay — 免費使用計劃的小工具.

最有用 ARIA 角色的比較

下表總結了在實際審計中反覆出現的角色，以及其對應的原生元素（若有）和最常見的陷阱。

角色	用途	原生替代方案	常見陷阱
button	執行動作的控制項	<button>	未加入 Enter/空格鍵處理或 tabindex="0"
link	導航至其他 URL	<a href>	將其用於非導航動作
dialog	模態或非模態視窗	<dialog>	未捕捉焦點或在關閉時未將焦點還原
tablist / tab / tabpanel	分頁介面	無直接替代方案	未將 aria-selected 與可見面板同步
menu / menuitem	應用程式選單	<select> 或連結清單	將其用於網站導航選單
alert	緊急且立即的訊息	role="status" (非緊急)	過度使用導致螢幕閱讀器資訊過載
status	資訊更新	<output>	在更新前未將其插入 DOM
progressbar	任務進度	<progress>	未更新 aria-valuenow
tooltip	彈出式描述	title (有限制)	未與 aria-describedby 關聯
combobox	帶有建議清單的欄位	<datalist> (有限制)	未宣告結果數量

role="alert" 和 role="status" 之間的選擇是關於 aria 角色和屬性的細微差別決策的一個很好的例子。 alert 中斷目前螢幕閱讀器的閱讀； status 等待使用者完成。對於表單驗證錯誤，「alert」是合適的。對於用戶寫入時“找到 3 個結果”，“status”是正確的，而“alert”會導致侵入。

ARIA 的屬性與組合

這些屬性與四個系列相關，每個系列解決一個不同的問題。

值得一看： AudioEye — Accesibilidad gestionada：自動化與人性化修訂結合.

**標記。 ** aria-label 在沒有可見文字時提供名稱。 aria-labelledby 引用另一個元素的 id，並且當文本已存在於螢幕上時更可取，因為它維護單一事實來源。 aria-describedby 新增了更長的描述，例如欄位的說明文字。差異很重要：名稱是使用者聚焦時聽到的名稱；描述是可以中斷的附加上下文。

狀態。 用於手風琴和下拉菜單的“aria-expanded”（真/假）。 “aria-selected”用於選項卡和選項。 “aria-checked”表示自訂複選框，值“mixed”表示三態狀態。 aria-pressed 用來切換按鈕。當元素仍然可聚焦但不可操作時為“aria-disabled”，與本機屬性“disabled”相反，後者將其從 Tab 鍵順序中刪除。

**關係。 ** aria-controls 指示按鈕控制哪個元素。當 DOM 不反映視覺關係時，「aria-owns」會重新組織可訪問性樹。 aria-activedescendant 讓您在宣布活動元素（組合框中的常見模式）時保持對容器的關注。

**即時區域。 ** aria-live="polite" 或 "assertive" 定義緊急程度。 aria-atomic="true" 會導致整個區塊被公佈，而不僅僅是修改的部分。已宣布更改的“aria-relevant”過濾器。

一個經常被忽略的細節：ARIA 屬性僅適用於具有有效角色的元素。沒有角色的 <div> 上的 aria-expanded 將不會被宣告。 ARIA 布林值是文字字串（「true」、「false」），而不是 JavaScript 布林值；將 aria-expanded="false" 寫入布林屬性會產生不一致的結果。

小部件存取錯誤

此錯誤主要是由於 ARIA 與 HTML 結構錯誤有關。 在已有 <nav> 可用時，仍為 <div> 添加 role="navigation" 會導致區域重複並干擾地標導航。

相關： IAAP CPACC / WAS Certification — 獲得相關經驗的專業認證.

第二個錯誤是焦點。開啟時不移動焦點、開啟時不捕捉焦點、關閉時不將其返回觸發器的模態小部件會讓鍵盤使用者在不可見的內容中導航。本機「

」元素解決了部分問題，但不是全部：返回焦點仍然是開發人員的責任。

第三個錯誤是使用 aria-hidden 隱藏仍可聚焦的元素。一個設定為 aria-hidden="true" 但未設定 display: none 或 visibility: hidden 的關閉選單，其連結仍保留在 Tab 鍵順序中，導致使用者聚焦於不可見的元素。正確做法是同時在視覺上和可存取性樹中將其隱藏。

如果您正在購物： accessiBe — IA 超級位置將在 48 小時內推動 WCAG.

第四個錯誤是缺少可訪問名稱。帶有單一 SVG 圖示的 <button> 需要帶有文字的 aria-label 或 <span class="visually-hidden">。裝飾性 SVG 需要 aria-hidden="true" 和 focusable="false"，因此 Internet Explorer 和一些較舊的瀏覽器不會將其包含在 Tab 鍵順序中。

關於角色的說明和 ARIA 的屬性

沒有工具可以取代實際螢幕閱讀器的測試，但各種工具的組合可以檢測 aria 角色和屬性中的大多數故障。

**靜態驗證。 ** W3C ARIA 驗證器（Nu HTML Checker 的一部分）會偵測不存在的角色、寫得不好的屬性和禁止的組合。 ax DevTools 和 Lighthouse 指出沒有可訪問名稱且缺少強制屬性的角色。

**輔助功能樹檢查。 ** Chrome 和 Firefox DevTools 讓您可以準確地查看輔助技術接收到的輔助使用樹。這是檢查角色是否實際應用以及瀏覽器計算出的可存取名稱的最快方法。

**手動測試。 ** 僅使用鍵盤（Tab、Shift+Tab、箭頭、Enter、Space、Escape）導航整個小工具，然後使用 Windows 上的 NVDA、JAWS（如果可用）或 macOS 和 iOS 上的 VoiceOver。桌面閱讀器和行動閱讀器的結合涵蓋了大部分真實案例。

**參考文件。 ** W3C ARIA 創作實踐指南 (APG) 包括帶有鍵盤和程式碼範例的綜合模式。這是發明新模式之前應該查閱的資料來源。

如何在實際的 XHTML/CSS 專案中決定

在具有輕量級 CSS 和 JavaScript 的 XHTML 網站上，最具成本效益的策略是從本機 HTML 開始，僅在本機無法到達的地方新增 ARIA。具有正確的 <label>、<fieldset> 和 <legend> 的表單需要很少的 ARIA。具有“”的數據表也不會。當出現 HTML 未涵蓋的模式時，ARIA 角色就會出現：選項卡、手風琴、帶有過濾的組合框、模式對話框和動態通知。

建議在程式碼本身中記錄 ARIA 角色和屬性的每次使用，並用註釋解釋其原因。當六個月後有人重構該組件時，他們會知道「aria-controls」是否仍然必要或已成為孤立的。孤立的 ARIA 屬性（指向不再存在的 id）是驗證器無法可靠​​地偵測到的無聲故障來源。

最後，將可訪問性視為元件「完成」定義的一部分，而不是後續審核。從第一次提交開始就使用鍵盤和螢幕閱讀器進行測試的具有 ARIA 角色的小部件的成本遠低於審核後修復的小部件。

要點

• ARIA 角色和屬性不會添加行為：沒有鍵盤和焦點管理的角色比沒有更糟。
• ARIA 的第一條規則是只要存在原生 HTML 就使用它； <button>、<dialog> 和 <details> 涵蓋的情況比人們想像的要多。
• 屬性分為標籤、狀態、關係和活動區域；每個家庭解決不同的問題。
• role="alert" 中斷且 role="status" 等待：錯誤的選擇會使螢幕閱讀器使用者飽和。
• ARIA 布林值是字串（“true”/“false”），屬性僅適用於具有有效角色的元素。
• 必須使用鍵盤和真實螢幕閱讀器進行測試；驗證器只能偵測到一部分失敗。

資料來源與進一步閱讀

• WAI-ARIA — 維基百科：Web 可訪問性倡議 – 可訪問的富互聯網應用程式 (WAI-ARIA) 是萬維網聯盟 (W3C) 發布的一項技術規範，…

常見問題

ARIA 角色和屬性之間有什麼區別？

角色定義了輔助技術的元素，例如role =“tab”或role =“dialog”。屬性描述其狀態或其關係，例如“aria-expanded”或“aria-labelledby”。角色應用於代表組件的元素；屬性通常應用於相同元素或與其相關的元素。

我應該在什麼時候使用 ARIA 而不是原生 HTML？

僅當沒有 HTML 元素覆寫該模式時。 W3C ARIA 的第一條規則很明確：如果有原生元素，就使用它。選項卡、手風琴、具有過濾功能的組合框和模式對話框以及 HTML 無法自行實現的其他模式都需要 ARIA 角色。

元素具有「可存取名稱」是什麼意思？

可存取的名稱是螢幕閱讀器在聚焦元素時宣布的文字。它是根據內容、「aria-label」、「aria-labelledby」或關聯的「」按照規範定義的優先順序計算的。沒有可存取名稱的互動角色是使用者無法辨識的控制項。

為什麼我的 role="button" 對鍵盤沒有反應？

因為 ARIA 不會增加行為。<div role="button"> 需要 tabindex="0" 才能接收焦點，以及針對 Enter 和 Space 的 keydown 處理程序。最簡單且最穩健的解決方案是使用原生的 <button> 元素，它已經包含了焦點、鍵盤啟動和表單提交功能。

使用 aria-hidden="true" 是壞事嗎？

從輔助功能樹（accessibility tree）中隱藏裝飾性或重複的內容是正確的，但絕不應將其應用於會接收焦點的元素。如果可聚焦元素被設定為 aria-hidden="true"，鍵盤使用者可能會聚焦在螢幕閱讀器不會朗讀的內容上。請務必將其與實際的視覺隱藏結合使用。

有哪些工具可以驗證 ARIA 角色和屬性？

W3C Nu HTML Checker 包含對 ARIA 角色和屬性的驗證，並能偵測不存在的角色或禁止的組合。axe DevTools 和 Lighthouse 會指出缺乏可訪問名稱（accessible name）或缺失強制屬性的角色。為了驗證最終結果，瀏覽器 DevTools 中的輔助功能樹檢查器（accessibility tree inspector）能準確顯示輔助技術接收到的內容。