一份簡短、帶有觀點的無障礙網頁按鈕檢查清單
五項規則，在按鈕無障礙問題進入正式環境前攔下大多數狀況
目錄
按鈕無障礙建議的問題
多數按鈕無障礙指南可分成兩類：不是沒人會讀的 40 頁 WCAG 詮釋，就是籠統地建議你「讓按鈕具備無障礙能力」，卻沒有可執行的步驟。當你週四就要交付功能時，兩者都幫不上忙。
這份檢查清單涵蓋我們在正式環境中最常見的五種按鈕無障礙失敗。它不會讓你成為 WCAG 專家，但能抓到真正會影響使用者的問題。
1. 按鈕就使用 button 元素
如果它的行為像按鈕，就應該是 <button> 元素。不是帶有 onclick 的 <div>，不是帶有 role="button" 的 <span>，也不是帶有 href="#" 再加上 preventDefault 的 <a>。
<button> 元素會免費提供鍵盤導覽、焦點管理，以及螢幕閱讀器宣告。當你使用 <div> 時，你是在從零重建這一切——而且你會做錯。
唯一例外：如果該動作會導覽到新頁面或變更 URL，請使用 <a> 元素。連結與按鈕在語意上不同。螢幕閱讀器使用者會依元素類型導覽，而他們預期按鈕會執行動作、連結會進行導覽。
2. 讓可點擊目標至少有 44×44 像素
WCAG 2.5.5（等級 AAA）要求互動元素的最小目標尺寸為 44×44 CSS 像素。這不是指視覺大小，而是可點擊區域。
你可以有一個視覺上較小、但具備足夠 padding 的按鈕，也可以用 pseudo-element 擴大可點擊目標。重點是使用者不需要精準瞄準。
行動裝置使用者、動作能力受限者，以及任何在移動中使用裝置的人，都會錯過太小的目標。24×24 像素的圖示按鈕也許看起來乾淨俐落，但它是可用性上的失敗。
3. 提供可見、而且不只是瀏覽器預設的焦點狀態
瀏覽器預設的焦點環比沒有好，但它在不同瀏覽器之間不一致，也常常在某些背景上看不見。你需要一個能在你的設計系統中運作的自訂焦點狀態。
好的焦點指示器具備三項特質：
- 高對比：相對於相鄰顏色至少 3:1
- 可見偏移：不會被按鈕本身的邊框或背景遮住
- 一致形狀：使用者應該能在整個介面中辨識它是焦點指示器
不要在沒有更好替代方案的情況下移除 outline: none。也不要把焦點狀態做得過於細微，只有你在完美光線條件下才看得見。
4. 撰寫脫離上下文也有意義的按鈕標籤
螢幕閱讀器使用者經常透過在按鈕之間跳轉來導覽。當他們這麼做時，聽到的是一串沒有周遭上下文的按鈕標籤。
在那樣的清單中，標成「了解更多」的按鈕毫無用處。「點這裡」或「送出」也是。標籤應該描述動作：「下載無障礙檢查清單」、「訂閱更新」、「刪除此則留言」。
如果你的設計需要較短的視覺標籤，請使用 aria-label 提供描述性替代文字。但更好的解法，是撰寫對所有人都有效的標籤。
對於只有圖示的按鈕，aria-label 是必要的。只有放大鏡圖示的按鈕需要 aria-label="Search" 或等效文字。圖示對螢幕閱讀器而言並不可及。
5. 確保足夠的色彩對比
WCAG 2.1 要求一般文字的對比率至少為 4.5:1，大型文字（18pt 或 14pt 粗體）至少為 3:1。按鈕標籤通常是一般文字。
白色按鈕上的淺灰文字不合格。淺藍背景上的淡藍文字也不合格。這些組合也許看起來精緻，但會排除低視力、色盲使用者，以及任何在強烈日光下觀看螢幕的人。
在設計期間就使用對比檢查工具，而不是上線後才做。正式環境中的對比問題修復成本很高，因為它往往需要變更設計系統。
如果你正在使用影像處理工具，client-side processing can help preserve privacy while generating accessible visual assets——特別是在測試色彩組合或產生預覽狀態時。
這份檢查清單未涵蓋的內容
這份清單刻意不完整。它沒有涵蓋停用狀態語意、載入狀態、錯誤處理，或像 split buttons、dropdown triggers 這類複雜按鈕模式。這些模式需要自己的指南。
它也沒有涵蓋何時該使用按鈕、而不是其他互動元素這個更大的問題。對此，你需要理解語意化 HTML 與 accessibility tree——這些主題都值得各自成文。
它涵蓋的是容易先處理的問題：幾乎每次 code review 都會出現、影響最多使用者、且在開發期間最容易修正的錯誤。
如何把它整合進你的工作流程
無障礙檢查清單只有在成為開發流程的一部分時才有效，而不是事後才補上。以下是讓它發生的方法：
在設計中：在你的設計檔中加入焦點狀態與可點擊目標註記。不要把這些留給開發者猜。
在 code review 中：檢查 <button> 元素、圖示按鈕上的 aria-label，以及焦點狀態 CSS。這些都很快能發現。
在測試中：用鍵盤在你的介面中按 Tab 導覽。如果你無法到達某個按鈕，或看不出焦點在哪裡，你的使用者也一樣。
在文件中：把按鈕無障礙需求納入你的元件庫。讓做對的事比做錯的事更容易。
如果你正在除錯正式環境問題，tools for inspecting HTTP headers and redirects 可以協助你理解輔助科技如何解讀你的標記——特別是在排查導覽後的焦點管理問題時。
跳過這項工作的代價
不可及的按鈕不只是沒有通過 WCAG 合規——它們會破壞工作流程。無法點擊送出按鈕的使用者，無法完成表單。看不到焦點狀態的使用者，無法用鍵盤導覽。無法分辨按鈕文字與背景的使用者，無法讀取標籤。
這些不是邊緣案例。全球人口約有 15% 具有某種形式的身心障礙，而暫時性受限（滑鼠壞掉、強烈日光、抱著嬰兒）最終會影響每個人。
好消息是，按鈕無障礙大多是已經被解決的問題。你不需要發明新模式，也不需要等待瀏覽器支援。你只需要正確使用平台，並測試你的工作。
重點整理
- 按鈕使用
<button>元素，導覽使用<a>元素——語意差異對輔助科技很重要 - 確保可點擊目標至少為 44×44 CSS 像素，以支援動作能力受限者與行動裝置使用者
- 提供可見、高對比，且能跨你的設計系統運作的焦點狀態
- 撰寫單獨讀取時也有意義的按鈕標籤，並為只有圖示的按鈕使用
aria-label - 在設計期間檢查色彩對比，而不是上線後才檢查，以避免昂貴的補救修改
FAQ
Q: 如果我加入鍵盤處理器，可以在 <div> 上使用 role="button" 嗎？
A: 可以，但你不應該這麼做。你需要手動處理 Enter、Space、焦點管理與停用狀態——而且你不可避免會漏掉某些事情。<button> 元素預設就會正確完成這些事。請使用它。
Q: 像播放／暫停按鈕這種會切換狀態的按鈕呢？
A: 使用 aria-pressed="true" 或 aria-pressed="false" 表示目前狀態。按鈕標籤也應該反映點擊後會發生的動作（播放中時顯示「暫停」，暫停時顯示「播放」），而不是目前狀態。螢幕閱讀器使用者需要知道按鈕會做什麼，而不是系統目前處於什麼狀態。
Q: 停用的按鈕需要符合對比需求嗎？
A: WCAG 2.1 將停用控制項排除於對比需求之外（1.4.3），但這點具有爭議。對比不足的停用按鈕對每個人來說都難以辨識。如果你要顯示停用按鈕，請讓它可讀。更好的做法是隱藏它，或解釋為什麼它被停用。
Q: 沒有螢幕閱讀器時，我該如何測試按鈕無障礙？
A: 使用你的鍵盤。按 Tab 走過介面，確認你可以到達每個按鈕、看得出焦點在哪裡，並能用 Enter 或 Space 啟用按鈕。這能抓到多數問題。若要做更深入的測試，請使用 Chrome 或 Firefox DevTools 中的 accessibility inspector，檢查計算後的 role 與 label。
Q: aria-label 和 aria-labelledby 有什麼差別？
A: aria-label 直接提供文字字串。aria-labelledby 則參照另一個元素的 ID，該元素的文字內容會成為標籤。當標籤文字已經存在於 DOM 中其他位置時，使用 aria-labelledby。當你需要提供畫面上不可見的標籤時，使用 aria-label。
Sources
- Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
- Inclusive Components: Toggle Buttons — Heydon Pickering
- The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
- WebAIM: Keyboard Accessibility — WebAIM
