Accessibility 開發與實踐系列

客製 Accessibility tree,從認識 ARIA 開始(上)

ARIA 是什麼?介紹運用 ARIA 時的 5 個原則!

A11y新手村🏕
a11yvillage

--

裝飾性封面圖片

運用 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標籤有:aria-label, 用於提供元素的可訪問名稱;aria-labelledby:與aria-label類似,但使用已存在的元素來做為可訪問名稱;aria-hidden:將元素從accessibility tree 中移除”
常見的 aria 標籤包含:aria-label, aria-labelledby, aria-hidden 等等

使用 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 元素已經被廣泛支援和解釋,並且螢幕閱讀器等輔助科技已經為它們提供了相應的處理方式。如果我們更改原生語義,可能會使輔助科技無法正確解讀導致內容的錯誤呈現,進而影響到可訪問性。

“若要建立一個標籤式的標題,應在該標題元素外包裹一個role屬性設定為tab的div元素,而非修改該標題元素的語意,導致輔助科技錯誤解讀”
除非非常必要,否則不要更改原生的語義,易導致輔助科技無法正確解讀元素

原則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:所有互動元素都必須擁有可訪問名稱

所有互動元素(例如連結、按鈕、文字輸入框、下拉選單、選項按鈕、核取方塊等)必須具有可訪問名稱。如果沒有可訪問名稱,輔助科技將無法理解元素的含義。為了提供可訪問名稱,有各種技術可供使用,具體取決於不同的元素。讓我們看一些例子:

  1. HTML 連結和按鈕:提供的連結文字/按鈕值將成為可訪問名稱。
  2. 文字輸入框:為了提供可訪問名稱,表單元件需要與其可見標籤關聯,可以是隱式或顯式關聯。
  3. 自定義小部件:為了為自定義小部件提供可訪問名稱,開發者可以使用 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>
所有互動元素都必須擁有可訪問名稱,例如文字輸入框必須同時具有肉眼可見的標籤以及該輸入框的可訪問名稱,而可訪問名稱通常會以label元素來設定。
所有互動元素都必須擁有可訪問名稱,例如文字輸入框需要同時具有可見標籤及可訪問名稱

註:使用 devtools 可以檢視該文字輸入框的可訪問名稱

在這篇文章中,我們介紹了 ARIA 的概念ーー它是一組用於描述網頁元素行為的語義屬性。同時,我們提到了使用 ARIA 的五個重要原則。這些原則指引我們在開發網頁和應用程式時,何時該使用它,以及何時不該使用它。

ARIA 是一組強大的無障礙修飾屬性,但所謂水能載舟,亦能覆舟。不正確或過度使用 ARIA 可能導致更嚴重的無障礙問題。在開始使用 ARIA 前,請務必牢記這篇所提到的 5 項基礎原則,這將有助於你正確運用 ARIA 來開發具有無障礙功能的網頁。

在下一篇中,我們將更進一步地看看 ARIA 可加強哪些無障礙類型與情境,那麼我們就下次見囉!

參考資料

  1. Using ARIA: https://www.w3.org/TR/using-aria/
  2. To ARIA! The Cause of, and Solution to, All Our Accessibility Problems: https://webaim.org/blog/aria-cause-solution/
  3. The WebAIM Million — The 2023 report on the accessibility of the top 1,000,000 home pages: https://webaim.org/projects/million/
  4. RULES OF ARIA — Advancedbytez: https://advancedbytez.com/5-rules-of-aria/
  5. Top 5 Rules of ARIA: https://www.deque.com/blog/top-5-rules-of-aria/

你的支持是我們的最大動力 💪

如果喜歡我們的文章,可以按下拍手👏來支持我們
也歡迎追蹤我們的medium跟Facebook粉絲專頁,讓我們提供你更多優質的無障礙知識跟新知!

為A11y新手村拍手50下的示意圖

本文作者:Woody

熱愛學習與開發程式的軟體工程師,對知識充滿好奇心,喜歡與人的互相分享。歡迎來一起協作開發各種 accessibility 專案。

--

--

A11y新手村🏕
a11yvillage

每週分享Accessibility相關原創文章,實用性內容包含原理,UX/UI設計到開發實作等,也會訪問障礙者與正在Accessibility實踐路上耕耘的人,邀請你入村跟我們一起創造包容友善的世界🏕