在網路世界中，我們面對越來越多樣化的任務，如線上協作、訂餐和金融交易。網頁已不僅是資訊傳達的媒介，而是具備動態功能的應用程式，為了滿足這些任務所帶來的新型操作方式需求，開發人員大量利用 CSS / js 對 DOM 元素進行樣式設計，創造出了許多新型的小部件，例如線上協作常見的便利貼或者檔案管理的電子網格等等。這些小部件提供了更加多元的操作方式與使用體驗。然而，對於使用輔助科技的人來說，由於缺乏語意訊息，使用這類的小部件通常是具有挑戰性的。
為瞭解決這類小部件的可訪問性問題，W3C 制定了 ARIA（Accessible Rich Internet Applications）標準，以提供更豐富的語意訊息給輔助科技。然而， WebAIM 報告指出不當使用 ARIA 是導致可訪問性問題的重要來源，開發人員對於它的理解不足更加劇了此問題的發生率。因此，本篇我們將和大家分享 ARIA 是什麼？並從使用 ARIA 的五個基本原則來看看為什麼你應該使用它，以及在哪些情況下你不應該使用它。
ARIA 最早是由隸屬於 W3C 的 WAI (Web Accessibility Initiative) 小組於 2008 年製訂。ARIA 是一組 HTML 屬性，通常以 “aria-” 為開頭。可以添加到 HTML 元素上，用於描述網頁元素行為的語義，它改變 Accessibility tree，向輔助科技提供更豐富的語意訊息，以便讓它們更好地在網頁中進行導航和互動。
但 WebAIM 所發佈的報告指出，在評估網站可訪問性時，檢測人員通常花費更多時間評估和報告 ARIA 的使用情況，勝過其他任何問題。此外，幾乎每份報告都會提到 ARIA 濫用的問題，並概述了需要進行修正的項目，或者更常見的情況是需要移除 ARIA 的使用方式。
此外，根據報告，WebAIM 在 2023 年 3 月對一百萬個最受歡迎的網頁首頁進行分析，他們發現 ARIA 的使用率在過去 1 年間增加了 29%，同時這個使用率更是 2019 年的兩倍。但報告卻指出 ARIA 使用量的增加與網頁上可訪問性問題的增加之間存在明顯的相關性。
雖然 ARIA 已經存在多年，例如下圖中介紹的 aria-label 或 aria-labelledby，相信你一定也有看到過，但大多數人對於它的內涵以及如何正確使用它的理解仍然相當不足。缺乏對 ARIA 用途的深入瞭解，使得開發者誤用 ARIA 的情況仍相當普遍，而這種誤用也導致了更多的可訪問性問題。
作為開發者，我們應該理解並遵守 ARIA 的一些使用原則，才能正確地運用它們來開發無障礙的頁面。現在，讓我們來看看在使用 ARIA 時需要注意哪些原則吧！
原則 1：優先使用原生 HTML ，避免使用 ARIA
在使用 ARIA 之前，可以優先考慮使用原生的 HTML 元素或屬性。只有在 HTML 無法提供所需語義的情況下，才考慮使用 ARIA 。
舉例來說，如果你需要在頁面中使用核取方塊，請使用 HTML 的核取方塊元素（<input type=”checkbox”>），而不是 ARIA 形式的核取方塊（<div role=”checkbox”>…</div>）。
這是因為原生的 HTML 元素會被瀏覽器正確的轉譯到 accessibility tree 上，並透過可訪問 API 將語義傳達給輔助科技的使用者，而不需要額外的處理。此外，原生的 HTML 元素也會內建具備鍵盤導覽功能，像是在單選 (radio) 按鈕可以使用方向鍵來在選項間移動。
那麼究竟何時我們應該使用 ARIA 呢？
在進行現有網站的可訪問性改善時：在進行現有網站的可訪問性改善時，使用 ARIA 是一個不錯的方法。透過添加 ARIA 屬性來改善可訪問性問題，可以最小程度上修改 DOM 結構，避免因調整 DOM 結構而導致既有功能的運作失效。這樣的做法可以節省時間和成本，同時確保網站在提升可訪問性的同時保持功能的穩定運作。
當難以在原生 HTML 元素上進行樣式調整達到期望的視覺效果時：例如在下拉選單的情境中，由於視覺樣式需求，而原生的
<select>、<option>元素在客製化程度上受限，因此開發者常常改用<ul>、*來製作下拉選單，此時就需要使用 ARIA 補充元件的語意。以下的範例使用了原生
<select>元素和自定義的 dropdown 元件做比較，主要差異在於自定義的沒有辦法使用「方向鍵」來選取選單的項目：@! 原生 select 元素與自定義 dropdown 比較
- 當原生 HTML 無法提供所需的語義時：例如在影音播放器中提供的靜音按鈕，一種常見的設計是當點擊後會做成看起來像「按壓」的視覺樣式，但原生 HTML 是沒有此類描述的語意屬性，這時我們就會需要用到 ARIA 來加以處理。
以下範例為關聯核取方塊會讓主核取方塊變成「部分勾選」的情境 (原生的只有勾與不勾兩種狀態)：
- 當某些 HTML 5.x 的使用者代理（瀏覽器）不支援時
除非符合以上這些情境，否則你應該優先考慮使用原生的 HTML 元素和屬性，避免過度使用 ARIA。
原則 2：除非非常必要，否則不要更改原生的語義
如前面提到，大多數 HTML 元素或屬性已經提供了特定的語義。除非真的非常必要，我們不應該更改原生的語義。例如，開發人員想要建立一個標籤式的標題時：
不應該這樣做 ❌：
<h2 role="tab">標題標籤</h2>而是按照最佳實踐 ✅：
<div role="tab"><h2>標題標籤</h2></div>我們應該保持原生的 HTML 元素（例如
<h2>）來表示標題，並使用一個具有角色（role）為 "tab" 的<div>元素來包裹它，以實現所需的語義效果。這樣做的原因是，原生的 HTML 元素已經被廣泛支援和解釋，並且螢幕閱讀器等輔助科技已經為它們提供了相應的處理方式。如果我們更改原生語義，可能會使輔助科技無法正確解讀導致內容的錯誤呈現，進而影響到可訪問性。
原則 3：所有可互動的 ARIA 元件必須支援鍵盤操作
使用 ARIA 屬性可以為自定義元件提供語義，但這並不會使它自動成為鍵盤可操作的元件。我們需要牢記， ARIA 與鍵盤功能無關，它僅提供可訪問 API 的語義，開發人員仍需要額外使用 “tabindex=0” 讓元件獲得焦點，並使用 js 來確保自定義元件能夠透過鍵盤進行互動。
舉個例子，如果我們構建了一個自定義按鈕（
<div role=”button”>），那麼我們需要確保它可以獲得焦點，並且可以使用 enter 鍵和 space 鍵來啟動綁定的功能。也就是說，自定義按鈕應該具備和原生按鈕一樣的鍵盤操作方式。這裡我們製作了一個範例對比了有無加上 tabindex 和監聽鍵盤事件的自定義 button：
可以多注意，許多使用者依賴鍵盤進行導覽和操作，尤其是那些無法使用滑鼠或其他指標裝置的使用者。透過支援鍵盤操作，確保所有人都能夠無障礙地訪問和操作可互動的元件。
原則 4：不要在可聚焦元素上使用 role=”presentation” 或 aria-hidden=”true”
所有可聚焦元素（例如連結、按鈕、文字輸入框、下拉選單、選項按鈕、核取方塊等）不應有 role=”presentation” 或 aria-hidden=”true” 屬性。
role="presentation"：表示該元素僅作為視覺呈現，沒有任何語義訊息，不具備任何角色含義。僅從 accessibility tree 中移除元素的語意訊息，但不會從 accessibility tree 中移除整個元素。aria-hidden="true"：表示該元素對輔助技術隱藏，會從 accessibility tree 中移除整個元素。
在可聚焦元素上使用這些屬性是不適當的，因為 role=”presentation” 會將元素的角色值移除，這會使輔助科技使用者無法得知該元素的用途和如何與其互動。而 aria-hidden=”true” 更會使元素在 accessibility tree 上消失，使輔助科技無法獲取該元素的可訪問名稱和角色。
不應該這樣做 ❌：
<button role="presentation">press me</button>也不應該這樣做 ❌：
<button aria-hidden="true">press me</button>而是按照最佳實踐 ✅：
<button role="presentation" tabindex="-1">Don't Click Me</button> <button style="display: none;">Don't Click Me</button>原則 5：所有互動元素都必須擁有可訪問名稱
所有互動元素（例如連結、按鈕、文字輸入框、下拉選單、選項按鈕、核取方塊等）必須具有可訪問名稱。如果沒有可訪問名稱，輔助科技將無法理解元素的含義。為了提供可訪問名稱，有各種技術可供使用，具體取決於不同的元素。讓我們看一些例子：
- HTML 連結和按鈕：提供的連結文字/按鈕值將成為可訪問名稱。
- 文字輸入框：為了提供可訪問名稱，表單元件需要與其可見標籤關聯，可以是隱式或顯式關聯。
- 自定義小部件：為了為自定義小部件提供可訪問名稱，開發者可以使用 aria-label 或 aria-labelledby 屬性。
例如：
下面的文字輸入框具有可見標籤，但沒有可訪問名稱 ⚠️：
<span style="font-weight: 400;">First name<input type="text" /></span>下面的文字輸入框具有可見標籤和可訪問名稱 ✅：
<span style="font-weight: 400;" ><label for="fname">First name</label> <input type="text" id="fname" /></span>
註：使用 devtools 可以檢視該文字輸入框的可訪問名稱
在這篇文章中，我們介紹了 ARIA 的概念ーー它是一組用於描述網頁元素行為的語義屬性。同時，我們提到了使用 ARIA 的五個重要原則。這些原則指引我們在開發網頁和應用程式時，何時該使用它，以及何時不該使用它。
ARIA 是一組強大的無障礙修飾屬性，但所謂水能載舟，亦能覆舟。不正確或過度使用 ARIA 可能導致更嚴重的無障礙問題。在開始使用 ARIA 前，請務必牢記這篇所提到的 5 項基礎原則，這將有助於你正確運用 ARIA 來開發具有無障礙功能的網頁。
在下一篇中，我們將更進一步地看看 ARIA 可加強哪些無障礙類型與情境，那麼我們就下次見囉！
- Using ARIA: https://www.w3.org/TR/using-aria/
- To ARIA! The Cause of, and Solution to, All Our Accessibility Problems: https://webaim.org/blog/aria-cause-solution/
- The WebAIM Million — The 2023 report on the accessibility of the top 1,000,000 home pages: https://webaim.org/projects/million/
- RULES OF ARIA — Advancedbytez: https://advancedbytez.com/5-rules-of-aria/
- Top 5 Rules of ARIA: https://www.deque.com/blog/top-5-rules-of-aria/
