無障礙網頁設計是非常大的一個題目，雖然一開始可能看起來令人生畏，不過實際運用於網頁設計之中，除了能讓網站觸及更多使用族群之外，因為需要使用結構化語意，網頁的 SEO 也會因而一同被加強，進而使網頁更容易被一般使用者接觸到。
在這系列文章，筆者希望讓大家對於「無障礙網站」其核心目的、相關組織及具體規範等有較宏觀的認識，進而逐步介紹在設計、前端程式中具體有哪些準則應遵守。
無障礙網頁的目的
「無障礙網頁」的目的是讓任何人都能很容易地讀取網頁內容、使用網頁服務。在開發上，設計者不能僅僅以典型用戶的操作模式（使用螢幕、滑鼠、鍵盤、觸控螢幕……等）來規劃交互方式，而必須跳脫自己使用電腦和網頁的角度，考量身心障礙者的操作模式，例如色盲、使用輔助科技（如螢幕閱讀器）來瀏覽網站……等情境。
可能很多人提到「無障礙網頁」，就想像網頁上會出現許多額外的輔助資訊、或是設計簡陋不美觀，其實只要在設計階段靈活運用，滿足無障礙需求的同時也能兼顧視覺效果，而且一般使用者在瀏覽無障礙網頁時也同樣能受惠。
從上面這個比較可以看出，有無實作無障礙設計並不會造成畫面設計上巨大的差異，很多項目反而更清楚了！會覺得這個設計看起來很古早，只是因為他真的是個將近十年前的範例網頁XD [註1]。
其實 UX 原則可說全都與增加網站可用性相關，瞭解 UX 重點、將這些考量融合於開發過程中，就能減少後期單純為了使網頁符合無障礙規範而進行耗費成本的修改。
往更廣的面向來說，其實還有許多在開發時就會預設好的情境典型，都可能令部分使用者──不只是身心障礙者──無法順利讀取網頁內容。以身在台灣的筆者自己來說，大多數專案開發時通常假設使用者都擁有高網速、瀏覽器支援 javascript 、沒有國家級防火牆等等，如果把這些都當成理所當然，就會排除掉部分低網速、使用手持裝置或是較舊版本瀏覽器的使用者，這也是廣義的無障礙網頁所希望避免的情況。
不過，下面我們主要還是針對狹義的無障礙網頁來作說明！
障礙的分群
Google Developers 和 MDN Web Docs 均將使用網頁的障礙分為四類 [註2]，以利區分不同身心障礙者會遇到的使用情境，及他們可能會使用的輔助科技：
- 視覺障礙：
包含全盲、弱視、色盲、視力衰退等，這類使用者可能使用螢幕閱讀器、盲文顯示器、螢幕放大鏡、文字放大功能、高對比度模式、文字語音轉換等方式（甚至組合這些方式）來使用網頁。 - 行動障礙：
包含因為損傷、疼痛而不願使用滑鼠（例如網球肘、扳機指），以及身體癱瘓或身體某些部位活動範圍受限的使用者，這些障礙甚至可能是情境式的──像是滑鼠壞掉、或是在晃動的交通工具上使用裝置等。 - 聽覺障礙：
指毫無聽力或是聽力低弱的群體。與視覺一樣，聽力也會隨著年齡增長衰退。聽覺障礙者通常會使用助聽器等輔具，在網頁使用這方面，則有各種技術幫助將有聲內容轉化為替代文字，例如自動生成影片字幕等等。 - 認知障礙：
比較廣泛，認知疾病的類型有許多種，包含自閉症、思覺失調、 ADHD 等等。這些疾病會影響使用者理解、記憶網站的操作方式。這些群體會使用的輔助工具與其他領域重疊，例如使用縮放功能來簡化閱讀或集中注意力。在開發上，比較難快速解決認知障礙造成的網頁使用問題，不過設計網站時，盡可能簡化並符合邏輯性、一致性會很有幫助。
現行規範很大一部分其實都是針對「視覺」這一塊的障礙在做檢測，主要也是由於網頁本身視覺化的內容通常較吃重，而流程、一致性這方面的要求又較難訂立統一的檢測標準之故。
WCAG與WAI、WAI-ARIA
在研究無障礙網頁設計時一定會提到的幾個名詞縮寫，它們其實分別是組織與規範標準：
WAI（Web Accessibility Initiative）
W3C 為建立無障礙標準與準則而生的組織。WAI 的網站除了提供網頁設計、開發的建議，也提供許多背景知識，讓設計者、開發者能瞭解身心障礙人士如何使用網站，模擬出更完整的使用情境。
WCAG
WCAG 則為無障礙網頁訂出龐大、詳盡、可量化的準則（不過並未包含具體技術）。在 WCAG 2.0 中，定義了不同的評級： A 級 、 AA 級 、 AAA 級 ，許多國家立法制定的無障礙標準都奠基於 WCAG （如美國的 Section 508 of the Rehabilitation Act、台灣的無障礙網頁開發規範…等）。
WAI-ARIA（WAI – Accessible Rich Internet Applications）
WAI-ARIA 則是面向開發者的，這是一套由 W3C 編撰的規則，它定義了一系列額外的 HTML 屬性，能為 HTML 元件提供額外的語意。
自從 HTML5 導入了具有語意的標籤（ tag ），前端工程師在切版時不再只使用簡單的 <div> 標籤搭配 id 來呈現網頁上的各種元件，而會盡量使用有意義的標籤如 <nav> 、 <footer> 等等。然而，單純使用這些標籤仍有其限制，例如在頁面中有多個導覽列 <nav> 時，其各自究竟對應到哪個區塊，對螢幕閱讀器而言就難以分辨。
WAI-ARIA 定義的就是實作上應如何使用這套 HTML 屬性，如 role 、 aria-label 來標示各元件的用途、屬性、狀態，後續系列文章會更詳細地介紹。
無障礙網頁認證
在台灣，《身心障礙者權益保障法》規範政府機關、學校網站都應符合 A 級以上的檢測， 2017 年以後設計新版網頁或改版更需要達到 AA 級；而 2021 年 7 月開始即將實施的新一版（ 2.1 版）的「網站無障礙規範」，新版本的檢測範圍包含更多服務功能。
台灣規範的無障礙網站同樣有三種評級： A 級 、 AA 級 、 AAA 級 ，符合評定項目就能得到相應的等級，由 NCC 負責相關的申請與審查。
下面是 2.0 和 2.1 版的評級表格，可以看到 2.1 版新增了一個新的指引「輸入方式」，並在各細項做了調整 [註3]：
| 4 原則 | 13 指引 | A 等級 | AA 等級 | AAA 等級 |
|---|---|---|---|---|
| 1.可感知 | 1.替代文字 | 1.1 | ||
| 2.時序媒體 | 2.1 2.2 2.3 | 2.4 2.5 | 2.6 2.7 2.8 2.9 | |
| 3.可調適 | 3.1 3.2 3.3 | 3.4 3.5 | 3.6 | |
| 4.可辨識 | 4.1 4.2 | 4.3 4.4 4.5 4.10 4.11 4.12 4.13 | 4.6 4.7 4.8 4.9 | |
| 2.可操作 | 1.鍵盤可操作 | 1.1 1.2 1.4 | 1.3 | |
| 2.充足時間 | 2.1 2.2 | 2.3 2.4 2.5 2.6 | ||
| 3.防痙攣 | 3.1 | 3.2 3.3 | ||
| 4.可導覽 | 4.1 4.2 4.3 4.4 | 4.5 4.6 4.7 | 4.8 4.9 4.10 | |
| 5.輸入方式 | 5.1 5.2 5.3 5.4 | 5.5 5.6 | ||
| 3.可理解 | 1.可讀性 | 1.1 | 1.2 | 1.3 1.4 1.5 1.6 |
| 2.可預期性 | 2.1 2.2 | 2.3 2.4 | 2.5 | |
| 3.輸入協助 | 3.1 3.2 | 3.3 3.4 | 3.5 3.6 | |
| 4.穩健性 | 1.相容性 | 1.1 1.2 | 1.3 |
其中，4 原則和 13 指引大致內容如下：
4 原則 [註4]：
- 可感知：資訊及使用者介面元件應以使用者能察覺之方式呈現（使用者一定要能察覺呈現出來的資訊，也就是資訊不能對使用者所有的感官均無形）
- 可操作：使用者介面元件及導覽功能應具可操作性（使用者一定要能夠操作介面，介面不能要求使用者無法執行的互動方式）
- 可理解：資訊及使用者介面之操作應具可理解性（使用者一定要能夠明白資訊及使用者介面的操作，亦即內容及操作皆不能超出使用者的理解）
- 穩健性：網頁內容應可供身心障礙者以輔助工具讀取，並具有相容性（隨著科技進步，使用者一定要能取用內容，也就是說當科技及使用者代理演進後，內容仍應保有可及性）
13 指引：
1.1 替代文字
有意義的非文字內容需有替代文字來描述、裝飾性內容則要使輔助科技能夠忽略之
1.2 時序媒體
音訊、視訊、互動性影片等需具有替代文字、字幕、描述，甚至手語翻譯
1.3 可調適
程式的結構、順序需要與內容有關聯性，能夠讓使用者知道元件的用途
1.4 可辨識
資訊內容須與背景有足夠的對比，讓使用者易於辨識，主要關乎設計及 RWD
2.1 鍵盤可操作
針對「只有鍵盤」的使用情境提供額外的支援度，避免功能只依據特定的輸入方式才能使用
2.2 充足時間
有障礙的使用者通常會需要花更多時間來進行互動，須確保網頁中有計時、自動播放的內容能夠讓使用者能有足夠反應時間，或是可以控制內容暫停
2.3 預防痙攣和身體不適反應
減少畫面閃爍、使用者能自行終止互動性的動畫
2.4 可導覽
使用螢幕閱讀器等輔助工具，瀏覽網頁時是線性的，這項的功能在於如何讓使用者知道自己身處網頁中的何處、如何到達其他地方，與標題、標籤、鏈結、 HTML 標籤、焦點的設定有關
2.5 輸入方式
和鍵盤可操作類似，這邊主要是針對滑鼠、觸控螢幕、雷射指標等指標輸入設備的支援度
3.1 可讀性
確保使用者能理解網頁內容，針對特殊或艱深辭彙、縮寫、破音字等需有說明
3.2 可預期性
與可導覽類似，使用輔助工具時對頁面內容難以有全觀的瞭解，因此元件需具備一致性以讓使用者更容易瞭解掌握頁面內容
3.3 輸入協助
與 input 相關的提示說明，以及偵測錯誤、提出建議及錯誤預防機制
4.1 相容性
HTML 結構須完整，元件名稱、屬性、值、狀態等均需要實作於結構中
在專案中導入無障礙設計
若專案需求包含通過無障礙網頁認證，最好一開始就和團隊成員說明專案需通過哪個等級的認證，具體必須符合哪些規範，以避免專案最後階段因為無法通過認證而必須大幅改動的情形。例如， SPA（Single Page Application） [註5] 其中一個硬傷就是 SEO 不佳，原因在於頁面一開始只有一個空容器或至少不是完整的網頁內容，必須額外實作 SSR（Server Side Render）來解決這個問題。而同樣的原因也會使無障礙標準難以達成，如果一開始不清楚就把頭洗下去，到最後階段才打掉重練絕對會欲哭無淚。
以分工來說，團隊全員最好都知道大致有哪些規範，才有辦法實作於專案中並進行檢驗。
首先，設計師會需要額外考慮到顏色對比度、字級等具體規定（ UI ），並加強檢驗頁面流程及元件的一致性（ UX ）。設計師們可以著重閱讀以下幾個指引：
- 1.4 可辨識
- 2.3 預防痙攣和身體不適反應（針對動畫、動態設計）
- 3.2 可預期性（與 UX 相關）
再來，對前端工程師而言，由於大部分技術面的規範都屬於頁面結構、 HTML 標籤及屬性的範疇，所以擔子會更吃重一些。不過！前端工程師如果熟悉 Google 提供的 web.dev 工具（或 Lighthouse ），那應該已經對 A 級的大部分規範都不陌生了，其中 Accessibility 這塊就是無障礙相關的檢測。
於是前端工程師應該著重閱讀那些規範呢？可以的話就全部都看一下吧……（炸）因為負責實作的就是前端工程師嘛……。總之這邊還是列一些偏技術性的內容供參考：
- 1.3 可調適
- 2.1 鍵盤可操作
- 2.4 可導覽
- 2.5 輸入方式
- 3.3 輸入協助
- 4.1 相容性
至於為什麼後端工程師也應該要瞭解呢？例如網頁中若有編輯器產生的區塊，如何確保後台使用者輸入的內容也符合規範，這部分的防呆機制和過濾就會落在後端職責了。
最後，無障礙規範其實有非常多與網站內容有關，例如媒體均需有文字替代等。因此，針對額外需要產出的內容與客戶溝通，以及因無障礙開發而產生的時間成本、風險都會是 PM 額外需要考量的。
PM、企劃、文案可以多瞭解與內容產出相關的規範：
- 1.1 替代文字
- 1.2 時序媒體
- 2.2 充足時間（列入這點是因為計時長度可能需要協調）
- 3.1 可讀性
別以為無障礙網頁認證是額外做一個申請動作就能拿到的標章！事實上，根據網站內容複雜度，開發時間可能會增加不只一倍。開發時間的增加反映在兩個地方：
- 無障礙開發本身
- 檢測後進行反覆修改
如果網站內容龐大，且包含影音資料，那麼開發本身的複雜度會倍增，檢測點也會變多。若工程師熟悉無障礙規範，雖然開發本身會較耗時，但檢測可能會比較快通過、需要較少來回修改的時間；反之，更常見的則是先進行一般開發，送審後再根據改善建議進行調整──對 PM 而言，最好一開始就預期會有不少時間卡在審核與修改，尤其在需要 A 以上評級的情形，光是要熬到過審就可能曠日廢時。
[註1] 可以來玩玩看這個 WAI 提供的 DEMO 網站：Before and After Demonstration
[註2] 可參閱 Google Developers 和 MDN Web Docs 針對障礙者的說明頁面。
[註3] 可參閱 網站無障礙規範。
[註4] 整理自 網站無障礙規範。
[註5] SPA 是指透過 JavaScript 來變更畫面內容，讓頁面不需要一直全部重新的技術， Gmail 就是經典的例子。
系列文章目錄：
漫談無障礙網頁設計-1（無障礙網頁介紹）← 現在在這裡！
漫談無障礙網頁設計-2（在設計上實作無障礙網頁的大方向）
漫談無障礙網頁設計-3（在設計上實作無障礙網頁的元件）
漫談無障礙網頁設計-4（在前端實作無障礙網頁不可不知的 HTML）
漫談無障礙網頁設計-5（表格的使用）
