在上一篇中，我們介紹了 ARIA 的重要性和使用原則，在本篇中，我們將探討 ARIA 的使用場景，介紹對開發者來說的無障礙必讀指引、討論元件化對無障礙元件開發的好處。閱讀完本篇後，相信你在開發時將更加有意識地實踐無障礙，從一開始就關注它，避免累積無障礙的技術債。
我們在之前 這篇文章談過 accessibility tree，它是瀏覽器為了輔助科技所設計，主要描述頁面的語意，相較於 DOM 是描述了頁面的視覺樣式。其節點主要是由可訪問物件(accessible objects)所組成，可訪問物件在不同作業系統上可能會有些許差異，用於描述 UI 元件目前的資訊或狀態，例如：
- 名稱 (name)：通常是輔助科技辨別物件時使用的屬性，例如螢幕閱讀器會讀顯這些名稱，讓使用者知道他們正在互動的元件是什麼。；語音操作的使用者可以透過名稱在語音命令中定位元素。因此，一個應用或視窗中應避免存在多個物件有相同的名稱。
- 角色 (role)：可以提示輔助科技應如何與該元件互動，例如核取方塊、滑桿、下拉式方塊等等。
- 描述 (description)：提供元件詳細的資訊，例如元件可以如何操作的說明或更完整的敘述
- 值 (value)：通常用於輸入元件，表示目前已輸入的內容
- 狀態 (state)：元件是否被勾選、元件是否能被鍵盤焦點聚焦
- 其他：元件的座標位置
回到網頁的世界，瀏覽器本身具備一套預設的轉換方式，將各種 HTML 元素轉變為相對應的可訪問物件以形成 accessibility tree。我們可以使用 ARIA 屬性，來覆蓋或加強瀏覽器的預設轉換行為，特別是針對語意不明確的標記，如 <div>、<span> 等。 ARIA 的添加最終會反應到 accessibility tree 中的可訪問物件節點，改變輔助科技接收到的資訊，ARIA 被分為以下三類：
- 角色 (role)：對應可訪問物件中的類型。角色定義了元素的功能是什麼。大多數 HTML 元素都有一個預設角色，用於呈現給輔助科技。ARIA 可以定義 HTML 中不可用的角色，也可以覆蓋 HTML 元素的預設角色。
例如：<form>預設的角色是 “form”， 但我們可以透過<form role=”search”>的方式定義表單為搜尋角色。 - 狀態 (state)：元素的當下狀態描述，它通常會根據使用者互動或變數而變化。例如元件是否為展開？元件是否被勾選？元件是啟用還是停用？
例如：<input aria-invalid=”true”>，這個屬性表示非正確的輸入資料，螢幕閱讀器會提示使用者「輸入框 無效」。但這個 aria-invalid 值通常會根據輸入欄位資料變化而有變化，當輸入資料修正為正確後就會更改為 false 。 - 屬性 (property)：元件的特定功能描述。與狀態不同，屬性大多數情況下不會變動。例如，這個元件可以被鍵盤焦點聚焦嗎？它有無詳細的說明？或是這個元件與其他元件有何關聯？
例如：<button aria-haspopup=”true”>。這個屬性增強了標準按鈕的語意，螢幕閱讀器會提示使用者，這個按鈕被按下時會彈出一個視窗。
當設計頁面時，我們可以從可訪問物件的角度來思考，最終使用者接收到的可訪問物件會是什麼樣子，這個 UI 呈現在可訪問物件的狀態、描述或類型是什麼？以此來確認元件的語意是否完整。同時確訒 ARIA 是否正確傳遞語意，利用瀏覽器的 accessibility tree，檢查瀏覽器傳遞到可訪問 API 的資料，以及利用輔助科技檢查從可訪問 API 傳遞到輔助科技的資料都符合我們的預期，以保證使用者獲取的訊息是完整無誤的。
根據使用場景， ARIA 可以大致分為以下：
- 頁面結構的劃分：利用 ARIA，我們能為頁面的區塊定義地標角色，這幫助螢幕閱讀器瞭解頁面結構，有助於使用者在頁面中的定位和導航。更詳細的內容可以看這篇文章。
- 關聯元素及可訪問名稱與描述：HTML 提供了一些可關聯元素的標籤，可以增強元素的可訪問性名稱與描述，這些標籤可以讓網頁更具可訪問性。例如，在表單
<form>中，我們可以使用<label>提供欄位資訊；在表格<table>中，我們可以使用<caption>來提供表格描述，還有<th>標籤用於表格的行列標題。
然而，有一些標籤並沒有相應可使用的關聯標籤作法，比如按鈕<button>或連結<a>。在這種情況下，我們可以使用 ARIA 的aria-labelledby和aria-describedby屬性，來建立元素與元素之間的關聯。 - 動態內容的更新：當內容動態變化時，螢幕閱讀器可能難以感知，我們需要思考焦點管理和通知訊息的策略。例如，當螢幕閱讀器使用者在瀏覽頁面過程中，如果區塊內容更新，此時應該如何處理？如果更新非常重要，是否需要中斷當前的閱讀？是否應立即將焦點移動到更新的區塊？是否需要通知使用者有關此次更新，以便他們可以在其他位置找到它？或者，是否應該直接忽略不通知？。利用 aria-live ，我們能夠指出動態內容變化的區塊，讓螢幕閱讀器能夠正確地通知使用者這些變化。
- 小部件的鍵盤訪問性：小部件通常無法僅僅使用 HTML 來實現，而是需要搭配 JavaScript 來建立和控制的互動元件。例如：滑桿、功能選單、樹狀檢視、拖放控件、自動完成輸入框、對話框和工具提示等等。在製作這些小部件時，會使用
<div>或<span>等無語意的元素來客製化行為，我們需要透過 ARIA 來提升可訪問性。ARIA 提供了一系列的角色、屬性和狀態來實現這一目標。
在「ARIA Authoring Practices Guide」中的「Design Patterns and Examples」章節提供了如何設計這些小部件的詳細建議，遵循這些建議可以幫助我們開發具備良好可訪問性的元件！
ARIA Authoring Practices Guide (APG) 是一份由 Web Accessibility Initiative (WAI) 所撰寫的資源，旨在提供開發無障礙使用者體驗的指引，以確保使用輔助科技和鍵盤介面的人們也能夠輕鬆訪問網站。值得注意的是，APG 不是一個規範性標準，而是一份參考性指南。開發者可以謹慎遵循 APG 的模式，但也可以根據專案需求做出一些調整，前提是確保網頁的設計和行為仍符合可訪問性的要求。
APG 文件分為以下幾個主要部分：
- 模式（Patterns）： 介紹了 30 多種常見使用者介面的設計模式與實踐，從最普通的按鈕、對話框到複雜的樹狀檢視、網格都有。每種模式都清楚地描述了其目的、鍵盤互動模式、ARIA 屬性的用法，也都會搭配一個或多個程式碼範例來補充說明。
- 實踐（Practices）： 這個部分針對實踐網頁無障礙體驗的各種需求提供了深入的解釋，例如：如何提供正確的可訪問名稱、如何開發鍵盤互動、如何向輔助技術傳達頁面結構等等。每一項實踐都提供了詳細的說明與範例。
- 索引（Index）： 提供一份依照 ARIA 角色 (roles)、ARIA 屬性和狀態 (properties and states) 所列出的設計模式索引。例如我們可以透過 aria-modal 這個屬性來找到有使用該標籤的設計模式與實踐範例。
- 關於（About）： 最後一部分則提供有關 APG 的基本資訊、ARIA 基礎、致謝、 APG 文件的內容覆蓋率與品質報告等。
其中，模式（Patterns）這個部分相當值得仔細閱讀，它從元件的角度出發，幫助開發者理解如何使用 ARIA 屬性來實現可訪問性，並列出各種元件的可訪問性設計模式與實踐指南。對於 ARIA 還沒那麼熟悉的人，也能透過簡單易懂的範例來考慮不同的使用情境以及相對應的無障礙行為。
為什麼我們需要從元件的層級來思考可訪問性呢？隨著網頁前端所能完成的任務類型愈趨複雜，工程規模也隨之擴大，元件成為前端開發的基本組成單元。每個元件都有其獨立的功能，它們各司其職，並在整個應用程式中相互協作。採用元件化的方式組織程式碼，不僅更易管理，也提高了其可讀性和維護性。從可訪問性的觀點，元件化可以帶來以下這些好處：
- 可拆解與堆疊：從元件的角度去思考，可以更深入地分析單一元件的任務與相對應的無障礙行為。將可訪問性的考量融入每個元件的開發過程中，是確保運用元件堆疊出無障礙頁面的基礎。
- 可重用： 同一個元件可以在不同的專案中共用，甚至可以跨不同前端框架進行共用。這使得開發者可以更有效地共享和重複使用具有可訪問性的元件。
- 可理解：元件化降低了每個元件的複雜度，讓系統結構更為明確，這有助於開發者快速理解每個元件的職責和可訪問性需求，這使得可訪問性問題定位、團隊溝通和培訓將變的更加容易。
- 可維護： 元件化開發使得遵循可訪問性的最佳實踐變得更加容易。當瀏覽器的支援更新、或是這些最佳實踐發生變化時，只需在源頭處進行更新，即可影響所有使用該元件的專案。
- 可自動化測試：現代有許多測試框架提供單元測試、整合測試等不同角度的測試，通過分別測試元件和彼此間整合互動的可訪問性，可以更好地捕捉潛在的問題。雖然自動化測試無法保證發覺百分之百的可訪問性問題，但利用自動化進行測試，仍可以確保元件在一定程度上的無障礙度。
這篇文章我們介紹了 ARIA 的角色、狀態和屬性分類。其中，角色能夠提示輔助科技如何與元件互動，這對於可訪問性來說是相當重要的面向。此外，在處理小部件的鍵盤訪問時，開發者通常需要借助 JavaScript 來達成可訪問性，此部份會需要留意許多細節，如果程式碼沒有很好的管理很容易導致技術債的累積。因此，透過元件化開發，在元件層級關注可訪問性，並利用堆疊元件和自動化測試等軟體工程技巧，可以降低後期開發和維護成本，同時提高開發流程的順暢性和協作效率。唯有如此，無障礙才能在整個開發過程中實踐。
參考資料
Smashing Podcast Episode 4 With Heydon Pickering: What Are Inclusive Components?
