ARIA 角色是什麼？開發人員實用指南

ARIA 角色是什麼？ ARIA 角色是 87 個定義值的詞彙表（截至 WAI-ARIA 1.2），它們告訴輔助技術一個元素是什麼以及它應該如何表現，而不管其 HTML 標籤為何。像是 button、navigation 或 dialog 這樣的角色會將通用的 <div> 或 <span> 分配給已知的小部件類型，以便螢幕閱讀器能夠正確地朗讀它並公開正確的鍵盤互動。

為什麼 ARIA 角色存在

要理解什麼是 ARIA 角色，必須看到它們解決了單憑 HTML 無法解決的結構問題。原生 HTML 元素具有隱式語義：<button> 會將自身宣告為按鈕，可獲得焦點，回應 Enter 和空白鍵，並在必要時顯示按下狀態。當開發人員建立自訂小工具（如組合框、選項卡面板、樹狀視圖）時，他們經常使用 <div> 和 <span>，而這些元素不包含任何語義。ARIA 角色透過允許作者明確聲明缺失的含義來填補這一差距。

WAI-ARIA 規範由 W3C 的可存取富網頁應用程式 (Accessible Rich Internet Applications) 工作小組維護。第一版 ARIA 1.0 於 2014 年成為 W3C 建議標準；ARIA 1.1 於 2017 年發布，而 ARIA 1.2 於 2023 年達到建議標準狀態。每次修訂都新增了角色、狀態和屬性，且每個角色都連結到一份描述鍵盤預期行為的作者實作指南 (authoring practices document)。

角色與其他兩個 ARIA 類別之間有一個關鍵區別。角色回答：「這是什麼？」狀態 (States) 和屬性 (Properties) 則回答：「它處於什麼狀態？」以及「它與什麼有關？」role="checkbox" 宣告小部件類型；aria-checked="true" 則表示其當前狀態。混淆兩者是導致自訂小工具失效最常見的原因之一。

六種角色類別

要了解什麼是 ARIA 角色，了解 ARIA 規範將角色分為六個系列會有所幫助。了解該系列可讓您預測角色支援哪些狀態和屬性以及適用哪些鍵盤模式。

類別	目的	代表角色
抽象 (Abstract)	超類別定義，絕不在標記中使用	widget, input, section
小工具 (Widget)	互動控制項	button, checkbox, slider, tab
文件結構 (Document structure)	頁面地標與區域	banner, main, navigation, region
地標 (Landmark)	可導航的頁面區域（結構的子集）	banner, complementary, contentinfo, form
即時區域 (Live region)	宣布動態內容變更	alert, status, log, timer
視窗 (Window)	瀏覽器或應用程式視窗	dialog, alertdialog

抽象角色僅用於組織分類。作者絕不能在標記中寫入 role="widget" 或 role="input"；這會導致未定義的行為且驗證失敗。其餘五個類別才是您實際應用的類別。

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

隱式角色與 ARIA 的第一條規則

每個 HTML 元素都有一個由 HTML Accessibility API Mapping (AAM) 規範定義的隱式 ARIA 功能（這解釋了什麼是 ARIA 角色）。<nav> 元素具有隱式的 role="navigation"。<ul> 具有隱式的 role="list"。<h1> 到 <h6> 具有 role="heading"。<table> 具有 role="table"。

關於使用 ARIA 的第一條 W3C 規則明確指出：如果原生 HTML 元素或屬性已經傳達了所需的語義和行為，請使用它，而不是重複使用帶有 ARIA 的元素。將 role="button" 加到 <button> 是沒有必要的。更糟的是，如果您將 role="button" 添加到 <div>，您會得到朗讀公告但沒有任何行為：沒有焦點、沒有鍵盤激活、沒有表單提交。

冗餘並不總是無害的。覆蓋隱式角色可能會失去輔助技術所依賴的語義。在 <table> 中寫入 role="presentation" 會完全消除表格語義，這在佈局表格中是有意的，但對於資料表格來說則是災難性的。

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

角色如何與狀態和屬性交互

角色充當它們支援的狀態和屬性的容器。規範定義了哪些屬性對哪些角色有效，且瀏覽器僅在可存取性樹 (accessibility tree) 中公開支援的組合。了解什麼是 ARIA 角色有助於知道 role="checkbox" 支援值為 true、false 或 mixed 的 aria-checked。role="slider" 支援 aria-valuenow、aria-valuemin、aria-valuemax 以及可選的 aria-valuetext。role="combobox" 支援 aria-expanded、aria-controls 和 aria-activedescendant。將 aria-checked 應用於 role="button" 是沒有意義的，會被忽略或在某些螢幕閱讀器中產生令人困惑的結果。

必要的屬性同樣重要。沒有 aria-checked 的 role="checkbox" 是無效的；該狀態是強制性的而非可選的。沒有 aria-valuenow 的 role="slider" 會使使用者無法確定目前值。ARIA 規範將其標記為「必要的狀態和屬性」，而一致性檢查器（如 axe-core 和 IBM Equal Access Accessibility Checker）會指出其缺失。

角色、可存取性樹與瀏覽器支援

瀏覽器將 ARIA 功能轉換為平台可存取性 API（Windows 上的 UIA、macOS 上的 AXAPI、Linux 上的 ATK/AT-SPI），螢幕閱讀器則使用這些 API。如果沒有瀏覽器正確分配某個角色，該角色對使用者來說實際上是不可見的。

支援程度因功能和瀏覽器而異。「Button」、「Link」、「Header」、「List」和「Navigation」等核心功能獲得普遍支援。較新或更專業的角色（如來自數位出版 WAI-ARIA 模組的 “feed”、“math”、“doc-footnote”）支援較為零散。role="switch" 在現代瀏覽器中受到支援，但在十年前的朗讀並不一致。

針對受眾使用的實際組合進行測試仍然至關重要。在 Firefox 中搭配 NVDA 運作的小工具在 Safari 中搭配 VoiceOver 時可能表現不同，因為這兩個螢幕閱讀器使用不同的平台 API 並應用不同的啟發式方法。

地標角色與頁面結構

地標角色允許螢幕閱讀器使用者直接跳轉到頁面區域。八個地標角色分別是 banner、complementary、contentinfo、form、main、navigation、region 和 search。現代 HTML 對大多數角色都有原生等價物：<header> 變為 banner、<footer> 變為 contentinfo、<main> 變為 main、<nav> 變為 navigation、<aside> 變為 complementary、具有可存取名稱的 <form> 變為 form，以及具有可存取名稱的 <section> 變為 region。

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

使用原生元素是更好的選擇，因為即使 CSS 或 JavaScript 失效它們也能運作，且能降低角色/屬性衝突的風險。search 地標沒有原生 HTML 等效項，因此 role="search" 仍然是搜尋區域的正確選擇。

一個常見的錯誤是將 role="banner" 套用到位於 <main> 或 <article> 內部的 <div>。地標角色僅在未嵌套於某些其他角色中時才會建立地標；位於 main 內部的 banner 根本不會被顯示為地標。在 DOM 中的位置與角色值一樣重要。對於那些想知道什麼是 ARIA 角色的人來說，這些地標是規範的關鍵部分。

即時區域角色

在考慮什麼是 ARIA 角色時，即時區域角色會在不改變焦點的情況下宣布內容變更。四個即時區域功能是 alert、status、log 和 timer，以及更通用的 marquee。每個角色都隱式帶有一個 aria-live 值：alert 和 log 在實作中分別隱含 assertive 和 polite，而 status 則隱含 polite。

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

在 alert 和 status 之間做出選擇是一個具有實際後果的設計決策。alert 會停止螢幕閱讀器正在閱讀的任何內容，這適用於錯誤和緊急通知，但如果過度使用則有害。status 則等待暫停，適用於進度訊息和確認文字。

即時區域必須在內容變更之前就存在於 DOM 中。同時插入 role="alert" 元素及其文字通常會導致沒有公告，因為該區域在變更發生時並不存在。可靠的模式是在頁面載入時渲染一個空的即時區域，隨後再更新其文字內容。

何時不使用 ARIA 角色

使用 ARIA 的第二條規則是，除非確實需要，否則作者不應更改原生語義。第五條規則規定，每個互動元素無論其功能為何，都必須可以透過鍵盤存取並聚焦。

添加角色不會添加行為。在 <div> 上使用 role="button" 會導致它無法聚焦、不回應 Enter 或空白鍵，且無法提交表單。您需要添加 tabindex="0"、針對 Enter 和空白鍵的擊鍵處理程序，以及通常是「符合角色」的狀態管理。到此地步，使用真正的 <button> 需要更少的程式碼且錯誤更少。

某些角色在誤用時會產生實質危害。role="presentation" 和 role="none" 會移除元素的語義，在某些實作中也會移除其必要後代元素的語義。應用 role="application" 會將螢幕閱讀器切換到停止攔截擊鍵的模式，如果自訂鍵盤處理不完整，這可能會將使用者困在其中。

選擇角色的決策框架

遵循一個簡短的序列可以防止大多數 ARIA 角色錯誤。要了解什麼是 ARIA 角色以及如何使用它們，請執行以下步驟：

1. 識別小工具或區域。 用簡單的語言描述該元素實際上是什麼。
2. 檢查原生 HTML 等效項。 查閱 HTML-AAM 映射。如果 <button>、<select>、<details> 或 <dialog> 適合，請使用它。
3. 如果沒有適合的原生元素，選擇最接近的 ARIA 角色。 驗證它存在於目前規範中且不是抽象角色。
4. 添加必要的狀態和屬性。 檢查角色的定義以確認強制性屬性。
5. 實作鍵盤互動模式。 針對該小工具類型遵循 WAI-ARIA 作者實作指南 (Authoring Practices Guide)。
6. 使用至少兩種螢幕閱讀器和瀏覽器組合進行測試。 驗證公告、狀態和鍵盤流程。

第三步到第六步是大多數自訂小工具錯誤發生的地方。在第五步跳過鍵盤模式會創建一個宣告正確但無法操作的小工具，這可以說比根本沒有 ARIA 更糟糕。

測試與驗證工具

自動化工具可偵測結構錯誤：無效的角色值、缺失的必要屬性，以及應用於不支援該角色的元素。axe-core 是許多瀏覽器擴充功能背後的引擎，它檢查 ARIA 規則的定義子集。IBM Equal Access Accessibility Checker 和 W3C 自己的 Nu HTML Checker 也會顯示角色濫用。

自動化工具無法驗證角色是否產生正確的公告或鍵盤互動是否有效。因此仍需要使用 NVDA 搭配 Firefox、JAWS 搭配 Chrome 或 VoiceOver 搭配 Safari 進行手動測試。Accessibility Insights for Web 擴充功能將自動檢查與引導式手動評估（包括鍵盤和螢幕閱讀器驗證）結合在一起。

ARIA 規範本身、WAI-ARIA 作者實作指南和 HTML-AAM 映射文件是關於什麼是 ARIA 角色的權威參考。MDN Web Docs 的 ARIA 參考是一個方便且精選的次要來源，它為每個角色引用了相應的規範。

要點

• ARIA 角色宣告元素是什麼；WAI-ARIA 1.2 在六個類別中定義了 87 個角色，抽象角色絕不能出現在標記中。
• 原生 HTML 元素具有隱式角色和內建行為，因此使用 ARIA 時的第一條規則是優先使用原生元素，而非 div 加上 role。
• 角色需要其支援的狀態和屬性：沒有 aria-checked 的 role="checkbox" 是無效的且無法使用。
• 添加角色絕不會增加鍵盤行為或可聚焦性；這些必須單獨實作並測試。
• 地標和即時區域角色具有決定其是否有效的位置和時間規則。
• 自動檢查器僅偵測結構錯誤；仍需針對不同瀏覽器組合的螢幕閱讀器進行測試。

要理解什麼是 ARIA 角色，請記住它們為輔助技術定義了元素的用途。

資料來源與進一步閱讀

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

常見問題

簡單來說，ARIA 角色是什麼？

ARIA 角色是您附加到 HTML 元素的標籤，用來告訴輔助技術該元素代表什麼。<div role="button"> 會被朗讀為按鈕而非通用文字。角色提供了底層標籤未提供的含義，但它們本身不會添加任何行為、焦點處理或鍵盤支援。

ARIA 角色和 ARIA 屬性有什麼不同？

角色描述元素的類型，而屬性則描述其狀態、值或關係。 role="slider" 標識滑桿； aria-valuenow="50" 報告其目前位置，而 aria-labelledby 指向其標籤。角色和屬性一起使用，每個角色定義它支援哪些屬性。

ARIA 角色有幾個？

WAI-ARIA 1.2 定義了 87 個角色，分為六類：抽象、元件、文件結構、地標角色、即時區域和視窗。像「widget」和「input」這樣的抽象角色只存在於規範的內部分類中，永遠不應該用 HTML 編寫。這個數字隨著每個規範的修訂而增加。

我應該使用 ARIA 角色而不是語意 HTML 嗎？

不。 ARIA 使用的第一條規則是，只要存在具有所需語意和行為的原生 HTML 元素，就首選該元素。使用 <button> 而不是 <div role="button">，以及 <nav> 而不是 <div role="navigation">。 ARIA 角色是沒有適當的原生元素的情況下的後備方案。

ARIA 角色適用於所有瀏覽器和螢幕閱讀器嗎？

現代瀏覽器和螢幕閱讀器可靠地支援button、link、heading 和 navigation等核心角色。更新或更專業的角色（包括數位出版模組中的角色）提供了更多程度不一的支援。只有透過使用受眾使用的特定瀏覽器和螢幕閱讀器組合進行測試才能確定。

添加 ARIA 角色會破壞無障礙體驗嗎？

是的。覆蓋隱式角色可能會遺失有用的語義，例如當role="presentation"應用於資料表時。如果自訂鍵盤處理不完整，則應用 role="application" 可能會封鎖使用者。原生元素中的冗餘角色會產生不必要的噪音，有時還會導致相互衝突的播報。