Accessibility 開發與實踐系列
客製 Accessibility tree,從認識 ARIA 開始(上)
ARIA 是什麼?介紹運用 ARIA 時的 5 個原則!
運用 ARIA 時的 5 個原則
在網路世界中,我們面對越來越多樣化的任務,如線上協作、訂餐和金融交易。網頁已不僅是資訊傳達的媒介,而是具備動態功能的應用程式,為了滿足這些任務所帶來的新型操作方式需求,開發人員大量利用 CSS / js 對 DOM 元素進行樣式設計,創造出了許多新型的小部件,例如線上協作常見的便利貼或者檔案管理的電子網格等等。這些小部件提供了更加多元的操作方式與使用體驗。然而,對於使用輔助科技的人來說,由於缺乏語意訊息,使用這類的小部件通常是具有挑戰性的。
為瞭解決這類小部件的可訪問性問題,W3C 制定了ARIA(Accessible Rich Internet Applications)標準,以提供更豐富的語意訊息給輔助科技。然而, WebAIM 報告指出不當使用 ARIA 是導致可訪問性問題的重要來源,開發人員對於它的理解不足更加劇了此問題的發生率。因此,本篇我們將和大家分享 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 時需要注意哪些原則吧!
使用 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>、<li> 來製作下拉選單,此時就需要使用 ARIA 補充元件的語意。
以下的範例使用了原生 <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/
你的支持是我們的最大動力 💪
如果喜歡我們的文章,可以按下拍手👏來支持我們
也歡迎追蹤我們的medium跟Facebook粉絲專頁,讓我們提供你更多優質的無障礙知識跟新知!
本文作者:Woody
熱愛學習與開發程式的軟體工程師,對知識充滿好奇心,喜歡與人的互相分享。歡迎來一起協作開發各種 accessibility 專案。