最近工作接觸了無障礙網站的開發，彷彿開啟了異世界的大門
整個團隊沒有人知道無障礙網站是甚麼？網頁開發好之後，被告知需要申請網站無障礙標章。直接拿已經準備要上線的網站用機器自我檢測發現滿江紅，才發現這坑深不見底！
本篇記錄開發到現在踩過的坑、查找到的資料、語法筆記、以及一些好用的輔助工具；內容偏向個人筆記，資訊正確性就…參考參考即可 XD 本文發佈時，無障礙網站標章的申請流程還在進行中，之後如果有新內容，可能更新文章、或是另外寫一篇，就到時候再看看囉~
無障礙網站是給哪些人用的
第一次聽到 ”無障礙網站”，比較容易聯想到的是視障者。
多一點了解後，原來除了視障、聽障人士外，手不穩無法使用滑鼠，必須用鍵盤進行所有操作的人，也是無障礙網站的目標使用對象
廣義的無障礙網頁，除了視障人士，不同設備、不同瀏覽器版本、甚至是爬蟲都可以容易找到想獲得的資訊 ( 往好處想是 SEO 也比較好)
對於網站的的使用，障礙類型大致可分四類
- 視覺障礙：全盲、弱視、色盲等。輔助工具像是螢幕報讀器、瀏覽器的縮放功能
- 聽覺障礙：無聽力、使用助聽器的人。有聲內容就需要有替代文字或手語的規劃
- 行動障礙：無法使用滑鼠、滑鼠壞掉、在移動中需要使用網站
- 認知障礙：自閉、閱讀障礙、思覺失調等。可能會大量使用縮放功能，來簡化閱讀範圍，以集中注意力
綜合以上，網站設計應該盡可能簡單易懂，讓操作流程符合邏輯、畫面保持一致性，例如所有頁面的選單都在同個位置、按鈕固定在右上方等，以降低使用難度
除了本來就廣泛應用的 RWD (跨裝置瀏覽)、跨瀏覽器等注意事項，也需要讓螢幕閱讀器可以唸出使用者必須知道的資訊，像是有意義的照片要加上可被讀出來的說明，連結網址也要讓使用著知道是連去哪等
無障礙網站四原則
- 可感知：使用者就算喪失部份感官，仍可察覺（獲得）網頁資訊
- 可操作：可用鍵盤或語音執行任何網站需要操作的行為
- 可理解：網站架構、網站內容能夠清楚地被解讀，大多做得不錯的無障礙網站都有另外做給螢幕閱讀器念的網站導覽地圖頁面
- 穩健性：要可以用輔助工具來操作，像是螢幕閱讀器
無障礙網站開發
以下就蒐集到的資訊中，分享從網站開發的不同階段、或不同使用情境下，比較常見的問題或注意事項
設計階段注意事項
- 不能只用顏色做傳遞訊息的方式。像是表單沒填對時，只把外框改成紅色是不夠的，最好加上說明文字
- 會被手指點擊的元件 ( 連結、按鈕等 ) 寬高要大於 44 px
- 影音多的話，須規劃字幕、手語翻譯 ( 開發時程也要配合增加 )
開發注意事項
- 使用語意化標籤，對螢幕閱讀器使用者比較友善、同時也強化網站 SEO。舉例來說
<em>是強調、<i>是文字斜體；<strong>是重要，<b>是文字加粗。相較之下<em>與<strong>就是有意義的標籤，<i>與<b>對使用螢幕報讀的人，則沒有實質上的幫助。 <button>如果不在<form>裡，要加上type = 'button'，不然會觸發預設的 submit 作用- HTML 的 landmark tag ，像是<header>, <footer> 只有在 body 的第一層，才會被認定是 landmark
針對鍵盤操作注意事項
<a>跟<button>都可以被鍵盤聚焦到，其他元件如果也想被鍵盤觸發，可以加上tabindex='數字'的屬性，比較常使用的是tabindex='0'及tabindex='-1'tabindex='-1'可以被滑鼠 focus，但無法被鍵盤 focus到；使用情境像是跑馬燈，如果還沒出現在螢幕上的按鈕，加上tabindex='-1'就避免被鍵盤點到tabindex='0'可以加在頁籤上。如果頁面很多tabindex='0'，鍵盤切換時，會依照 DOM 順序切換
針對螢幕報讀器注意事項
- 文章看更多的 button 可以加上
aria-label='看更多某某文章的內容'，清楚說明是看更多哪篇文章 aria-haspopup='true'加在會開啟小視窗的按鈕上，讓使用者更清楚按鈕的後續功能- 有意義的 icon 建議加上替代文字，像是：警告、成功、錯誤等。在 icon 加
aria-label='錯誤、查看密碼、失敗...等'，裝飾性的 icon 則加上aria-hidden='true'，讓螢幕閱讀器直接忽略
表格 table
- 建議加上摘要：大概描述表格的說明文字
- 方法一：
<caption>放在<table>裡的第一個元件，在裡面放上表格摘要 - 方法二：在
table附近加其他元件寫上摘要說明並定義 id，像是<p id='aaa'>,<span id='aaa'>都可以，<table aria-describedby＝'aaa'>螢幕閱讀器就會讀取對應 id 的那個元件的內容，來當作表格的說明
可視不可視
- 讓所有人都看不到：
display:none,visibility:hidden( 但這個有佔位空間 ) - 視覺看到，螢幕報讀器看不到：裝飾內容元件加上
arir-hidden='true'，像是裝飾圖片或 icon，沒必要讓螢幕報讀器唸出來，增加使用的的負擔 - 視覺看不到，螢幕報讀器看到：用 sr-only ( bootstrap 寫來給閱讀機器用的，但很多寫無障礙也會這樣寫)
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0,0,0,0);
border: 0;
}
.sr-only-focusable:focus {
position: absolute;
width: auto;
height: auto;
clip: initial;
margin: inherit;
padding: inherit;
border: initial;
}導盲磚參考寫法
<a accesskey="L" title="左側區域"> ::: </a>
<a accesskey="C" title="中間區域"> ::: </a>
<a accesskey="R" title="右側區域"> ::: </a>WAI-ARIA 是什麼?
W3C 制定的無障礙網頁規範，用來強化 HTML 的語意。
規範中定義了很多可以加在 html 標籤上的屬性，像是 role, aria-label, aria-labelledby ,aria-discribedby 等，在不影響網頁外觀、互動、或預設的功能的情況下，讓報讀器可以將正確的網頁結構及網頁內容精準地念給使用者聽，像是
role='tablist'讓使用者知道這個元件內容是頁簽清單<button aria-label='關閉'> Ｘ </button>讓使用者知道某個顯示為 ”X” 按鈕實際上有關閉的動作aria-label='看更多零基礎轉職文章的內容'讓使用者知道那個原件為 ”看更多” 的按鈕，可以連結去看叫做 ”零基礎轉職” 的文章aria-label='header-nav'如果一個網頁架構上有好幾個 <nav>，螢幕閱讀器會告訴使用者這是上面的主選單aria-label='footer-nav'如果一個網頁架構上有好幾個 <nav>，螢幕閱讀器會告訴使用者這是底部的主選單aria-label='social-media-nav'如果一個網頁架構上有好幾個 <nav>，螢幕報讀器會告訴使用者這選單裡都是放社群連結<img aria-labelledby='close'> <div id="close"> 關閉視窗 </div>這樣圖片的說明就會是'關閉視窗' ，要換成其他元件也行aria-labelledby的值可以放多個 id 用空白隔開aria-labelledby跟aria-label不能同時使用，只會讀到labelledby（權重較高）aria-labelledby放簡要敘述，aria-discribedby放詳細的說明<button aria-pressed='false'> 暫停 </button>按鈕目前沒被按下去，所以還在播放- 常見 role：alert, button, dialog, gridcell, group, tab, tablist, tabpanel
按鈕加上清楚說明，不影響網頁畫面
- 左：使用者只能得知按鈕上顯示的文字為“資料類型”，但不知道實際按下按鈕後會發生什麼事
- 右：使用者可以預先知道按下去會開啟其他視窗，顯示內容為資料類型的清單
程式碼第91 行、在按鈕元件加上說明用的屬性
最初開發時程超趕，在沒有時間好好研究無障礙開發的情況下，是直接拿機器檢測的錯誤訊息一個個貼到網路上找解答，當時一直看到 WAI-ARIA，卻一直搞不清楚到底是什麼，直接搜尋找到的內容也是不清不楚，實在心很累…
開發至今，最深刻的心得是：看 50 篇說明無障礙的文章，不如好好花 2 小時聽完這堂數位發展部的課來的有價值：111年無障礙網站培訓課程_無障礙網頁設計切版
傳送門 | MDN 無障礙網頁開發基礎
瀏覽器小工具：查看 Accessibility Tree
- Accessibility Tree：無障礙檢視工具看到的網頁樹狀結構，可以理解成 “針對無障礙網頁的 DOM tree”。
- 從 Chrome DevTool （ F12 ）查看
步驟一、開啟 Accessibility 檢視模式
- 在 Element 模式，點右邊三個點點
- 選擇 Accessibility
步驟二、切換並重新整理 DevTool
- 勾選 “Enable full-page accessibility”
- 點擊 “Reload DevTool”，以重新整理 DevTool
步驟三、查看 Accessibility Tree
role 會改變在 Accessibility Tree 上的顯示內容。舉例來說：<ul role=”menu”> 回首頁 </ul> ，在 Accessibility Tree 上就不會看到 ul :回首頁，而會直接看到 menu :回首頁 (但不要這樣用，不然裡面的 li 在Accessibility Tree 上，就沒被包在 ul 裡，會報錯)
受害者情境
在網路海找教學的過程中，發現無障礙網站開發受害者大宗的 2 種情境，分別是 “網站已經開發好了，才提出改成無障礙的需求”，以及把 ”已經在線上運作的網站改成無障礙網站”，2 者在本質上很類似。反過來說，一開始就知道要做無障礙網站的話，可以先釐清無障礙網站的規範、找到正確教程跟著開發，通常…可能…或許…就不會成為受害者（？）
有人說看到網站開發接案需求如果是無障礙網站，報價直接乘以 1.5 ～2 倍，大概就能體會他比一般的網站，多了多少工。
而如果需求是要把已經上線的網站，“微調” 後拿去申請無障礙，一律直接拒絕（？）或是需要先看看程式碼長怎樣，再決定要不要接這個案子，因為 “微調” 後的無障礙網站，看起來跟一般網站不會差太多（搞不好看起來更簡單，因為拿掉太複雜的設計元素），業主不會知道你幾乎重寫了整個網頁，相對報價就很容易沒有共識 …。（就像非專業領域的小白目常會說：能不能請你微調個簡單的小小小地方？聽完後發現簡單的是他的大腦不是需求 ）
改寫比重寫困難許多多多！
網站無障礙標章的申請，又大略分為 “機器檢測” 與 “人工檢測” 二個階段。
最初以為機器檢測過了，人工檢測應該相對簡單，殊不知在機器檢測後，送人工審查之前的 “自我評估表“ 當中，又發現一堆檢測重點，是機器檢測沒在管的。
當時還天真地在筆記寫了 “ 其實無障礙要求的友善功能基本上都不難“，難在要花時間還沒錢 (未來是不是可以額外申請功德無量標章什麼的～)
大致整理後，判斷機器檢測應該就是模擬報讀器的使用，如果報讀器遇到一些他讀不出來的東西，就會是第一階段的調整項目，像是連結網址是要去哪、某張圖片是什麼內容等
而自我評量裡面提到的，則很多是針對 ”鍵盤使用者“ 的需求而衍伸的內容。主要訴求是：使用者能否利用 tab 加上 上下左右，就在網站裡暢行無阻
我的踩雷筆記
這次的專案主要是某個計畫的形象網站，使用者主要操作是瀏覽資訊、查看消息與相關新聞（連結到其他新聞平台）等靜態內容，沒有表單要填寫或是表格類的內容部分（這 2 塊也是另一灘深坑，自己慶幸之餘，也提醒大家慎入）
以下是我的踩雷筆記
機器檢測踩到的雷
- 每一頁一定要有個 <h1>，section 的標題要巢狀結構，從 <h1> <h2><h3>…<h6>，不可跳過
- <img> 要有 alt，是圖片描述，可以口語化，清楚易懂為主
- <a> 要有 title
- <a> 包著 <h2> 的話 (像是新聞連結，包含標題及內文)，<a> title 不能跟 <h2> 的內容一樣。( h 幾都一樣，這邊用 h2 為例)
- <a> 包著 <img> 的話， <a> 的 title 不能跟 <img>的 alt 一樣
<a
href='https://www.hpa.gov.tw/Pa...'
title='某某競賽新聞連結'
>
<img
src="specialLinksrc"
alt="某某應用競賽照片"
/>
<h2>【活動】某某創新應用競賽 </h2>
<div> 某某推資料創新應用..... </div>
</a>- <button> 要有文字
- 不能為了切版省力用 <a> 包著 <button> , 會造成螢幕閱讀器的負擔
- CSS 不要用 px，可用 %, em, rem … ( 特定使用者經常會有縮放網頁的需求，寫死的 px 容易破版 )
- 套件的 CSS 檔案，在機器檢測時可以放到排除文件裡
自評檢測踩到的雷
- CSS不要設定 outline: none。雖然操作時會變醜，但是用鍵盤切換時，被點到的地方，才能夠很明顯的看出重點（滑鼠）跳到哪裡了。
- 可考量的優化替待方案：使用鍵盤焦點會出現 outline，但滑鼠點到不會出現 outline
*:focus:not(:focus-visible),
*::before:focus:not(:focus-visible),
*::after:focus:not(:focus-visible) {
outline: none;
}- 所有文字，包含標題、內文，跟背景色的對比要夠鮮明；文字要4.5:1，標題要3:1。顏色對比工具傳送門
- 每個頁面最上面要加上一個隱形的 a 連結，可以連到頁面的主要內容
- HTML
<- 頁首加上跳轉連結 ->
<a
href="#content_main"
title="跳到主要內容"
tabindex="1"
class="sr-only sr-only-focusable"
>跳到主要內容</a>
<- 主要區加上 id ->
<h3 id="content_main" class="title-text">計畫介紹</h3>- CSS
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0,0,0,0);
border: 0;
}
.sr-only-focusable:focus {
position: absolute;
width: auto;
height: auto;
clip: initial;
margin: inherit;
padding: inherit;
border: initial;
}補充資料
- axe DevTools：Chrome 插件 — 檢查整個網頁、或指定某個區塊是否符合無障礙
- HeadingsMap：Chrome 插件 — 檢查 Ｈ系列
- 專門做無障礙網站的框架
- 如何用 vue 做無障礙網頁 (英文)
結語
這篇文章發表的時候，此專案的申請流程還在路上跑階段 (人工檢測中)
由於整個過程拉很長，等流程走完，再看是要回來補其他的部分，或另外再寫一篇，或許會再把無障礙標章的申請流程也整理出來
在沒有預先吸收相關資訊的情況下開發真的是有夠痛苦，如果可以，建議需要開發無障礙網站的人先去了解規範或直接上課，可以節省很多撞牆的時間
最後，如果開發的太痛苦，歡迎加入 【無障礙標章受害者聯盟粉絲專業】，當看到別人踩得坑比你深的時候，痛苦指數會降低一些 ( 什麼心態？！)
～既來之，享受之～
如果喜歡我的文章、或是這篇文章對你有什麼幫助，歡迎拍拍手讓我知道，更歡迎你追蹤並持續關注更多的分享。
我會不定期分享前端新手在開發中的各種學習(撞牆)過程，對這部分有興趣的朋友們敬請期待，
也請路過的前輩們多多指教，
我們下篇文章見！