Website Accessibility

前言

我還記得剛踏入職場時，常常在 X 上看到許多國外大神分享他們的產品已經符合無障礙標準，又或是他們的設計系統全面支援 A11y 等等的關鍵字。

當時只覺得：「又有新東西出現！！真的學不動了...」且心想，這該不會又是個短暫的風潮，撐不過一季就退燒吧？

直到剛加入一家美國新創後，初期收到的任務大多還算簡單，但讓我訝異的是這些任務幾乎都是跟無障礙 (Accessibility) 有關的修正或優化，像是讓鍵盤能順利操作、讓螢幕閱讀器能正確朗讀內容等等。

這才發現，原來公司近期正全面推動網站的無障礙支援，也才開始理解，美國法律對網站的可訪問性（Accessibility）有一定的要求，如果網站做得不夠完善，是有被用戶提告的風險。

根據 2021 年的資料，美國約有 4,250 萬名身心障礙者，佔總人口的 13%。這個族群涵蓋了在聽力、視力、認知、行走、自我照顧或獨立生活等方面有困難的人。回頭看台灣，根據衛生福利部統計有近 120 萬人是身心障礙者，佔總人口的 4.2%。

從身心障礙者的角度來看，如果一個產品無法讓他們順利使用，那是否為一種不公平；而從商業的角度來說，缺乏可訪問性的產品，則意味著直接流失這一群潛在用戶。那時我才知道可訪問性如此重要，也才開始認真學習相關的知識。

什麼是可訪問性？

"
「網頁無障礙（Web Accessibility）」是指網站、工具與技術在設計與開發時，即考量到讓身心障礙者也能使用。更具體來說，這代表使用者能夠：感知、理解、導航、與網頁互動，並能參與網頁內容的建立。
— W3C

許多可訪問性的功能不僅僅是身障使用者受益，也對所有使用者帶來了更好的可用性和包容性。以「高對比色彩」為例，不只能幫助視力較差的使用者，也對其他情境中的使用者同樣有益，像是在陽光強烈的戶外使用手機，或是在燈光昏暗的房間裡操作裝置時，都能提升可讀性與能見度，減輕眼睛疲勞，進而提高整體清晰度與使用效率。

重要的原則

可感知性 (Perceivable)
資訊與使用者介面必須能夠被所有人以某種形式感知。也就是說，不論使用者透過哪種感官或輔助工具，都應該能接收到內容。
可操作性 (Operable)
所有使用者都應能操作介面與進行導覽。舉例來說，網站必須支援鍵盤操作，不能只依賴滑鼠，確保每個人都能順利使用功能。
可理解 (Understandable)
資訊內容與介面互動方式應容易理解。舉例來說，系統應能協助朗讀內容、提供摘要，幫助有認知障礙的使用者理解頁面。
強健 (Robust)
內容必須具備良好的相容性，能被多種使用者代理（User Agent）與輔助技術正確解析與呈現，確保系統具備跨平台與未來的可延展性。

可訪問性的四個最佳實踐

以下列出四個在實作階段特別需要留意的重點，這些原則皆參考 WCAG (Web Content Accessibility Guidelines) 的規範。我們也會在後續設計系統的元件開發中，針對這些部分特別強化與實作。

顏色對比度

提供足夠的對比度，能確保使用者清楚看見文字與圖像內容。特別是在文字置於圖片上時，必須確保兩者之間的對比度足夠，才能維持良好的可讀性。

以下圖為例，圖中上方的顏色對比度是 1.61:1，而下方則是符合 WCAG 的 8.39:1，可以明顯看出下方的文字更容易閱讀。

語意化標籤

語意化標籤是指使用 HTML 標籤來描述網頁的內容，讓瀏覽器和螢幕閱讀器能夠更好地理解網頁的內容。對於無障礙設計來說，盡量使用 <header>、<nav>、<main>、<footer> 來包裝內容，主要是因為如果使用 <div> 或 <span> 來包裝內容，螢幕閱讀器會無法判斷這些元素的意義。

無障礙樹 (Accessibility Tree)

在一般的瀏覽器渲染流程中，瀏覽器會先解析網頁標記語言（例如 HTML），建立一棵 DOM 樹（Document Object Model），其中包含頁面上的所有元素、屬性與文字節點。同時，瀏覽器也會解析 CSS，產生 CSSOM。DOM 與 CSSOM 結合後，產生用於排版的 Render Tree，接著經過版面配置（layout）與繪製（paint）步驟，最終顯示到螢幕上。

與此流程「並行」的還有無障礙樹（Accessibility Tree）：瀏覽器會依據 DOM 結構、ARIA 屬性及計算後的樣式，建立這棵樹，並提供給螢幕閱讀器等輔助技術存取。藉由無障礙樹，身心障礙者得以感知、理解並操作我們的網站內容。

無障礙 API（Accessibility API）

當我們想把元件的語意、名稱與狀態暴露給無障礙樹時，就需要利用瀏覽器／作業系統提供的無障礙 API。每個暴露的節點會被包裝成一個 Accessible Object，其中最常見的四大屬性如下：

屬性	作用	常用實作方式
Role（角色）	指出元素在介面中的語意角色，如 `button`、`checkbox`、`link`…	`role="button"`、`role="checkbox"`…
Name（名稱）	讓使用者知道「這是什麼」	`<label>`、`aria-label`、`aria-labelledby`
State／Property（狀態／屬性）	告知目前狀態，如已勾選、已展開、禁用…	`aria-checked`、`aria-expanded`、`disabled`
Description（描述）	額外說明用途或限制	`aria-describedby`

範例程式碼

自訂按鈕元件的角色 (Role)

<!-- div 原本沒有語意，需加 role 與 tabindex -->
<div role="button" tabindex="0">點我</div>

提供名稱 (Name)

<!-- 透過 label 綁定 -->
<label for="search">搜尋：</label>
<input id="search" type="text" />

<!-- 或改用 aria-label 直接指定 -->
<input type="text" aria-label="搜尋關鍵字" />

自訂核取方塊的狀態 (State)

<div role="checkbox"
    aria-checked="false"
    tabindex="0">
  訂閱電子報
</div>

備註： 原生 <input type="checkbox"> 已內建可存取性資訊，一般不需再加 aria-checked。

額外描述 (Description)

<label for="username">用戶名：</label>
<input id="username"
      type="text"
      aria-describedby="usernameHelp" />

<p id="usernameHelp">
  用戶名需包含 6–12 個字元，且不得含特殊符號。
</p>

如果想要了解更多關於無障礙 API 的詳細資訊，可以參考 WICG AOM Explainer。

鍵盤焦點 (Keyboard Focus)

鍵盤焦點是瀏覽器目前接收鍵盤輸入的元素。當使用者以鍵盤瀏覽網站時，焦點就像他們的游標；所有可互動元件都必須能透過鍵盤操作（例如 Enter、Space、Tab 等鍵）存取。此外，焦點的移動順序應按照由上而下、由左至右的 DOM 排序，確保使用體驗流暢。

另一點需特別留意：當使用者點擊按鈕開啟 Modal 視窗時，應立即將鍵盤焦點移入 Modal；在關閉 Modal 後，則需把焦點還給原本的按鈕。後續的文章會實作相關元件，完善這套焦點管理流程。

Accessibility 測試工具

VoiceOver - macOS 內建的螢幕閱讀器
NVDA - 支援 Windows 的螢幕閱讀器
TalkBack - 支援 Android 的螢幕閱讀器

網站的可訪問性 (Accessibility)

前言