跳至中央內容區塊 :::
:::

鍵盤操作無障礙測試：不用滑鼠也能完成任務嗎？

鍵盤操作是網站無障礙檢測的核心項目。檢查互動元素是否可聚焦、Tab 順序、焦點提示、焦點是否被困住、對話框與表單流程。

最後更新:

重點摘要

  • 先選一個主要任務，確認不用滑鼠也能完成。
  • 鍵盤測試要看能不能到達、看得見焦點、操作後狀態是否清楚、能不能離開。

先用主要任務測，不要只測 Tab 會不會動

鍵盤無障礙測試的核心問題不是「焦點有沒有出現」，而是使用者不用滑鼠能不能完成主要任務。測試時應該從頁面頂端開始，只用鍵盤完成一個真實流程，例如搜尋、篩選、登入、送出表單或完成購買。

如果只在頁面上按幾次 Tab，很容易漏掉真正阻擋任務的問題，例如表單錯誤後焦點沒有回到錯誤位置、dialog 關閉後焦點消失，或展開選單後無法回到下一步。

  • 用 Tab 前進、Shift + Tab 返回。
  • 一般連結用 Enter 開啟；原生按鈕用 Enter 或 Space 啟動；checkbox 用 Space 切換。
  • radio 群組與 tabs 等複合元件通常用方向鍵在內部移動，不是每個項目都要按 Tab；依該元件的互動模式確認選取與啟動方式。
  • 用 Escape 關閉可關閉的 dialog、popover 或 menu。
  • 在表單錯誤、載入完成、路由切換後重新確認焦點位置。

檢查可到達、可看見、可操作、可離開

實務上可以把鍵盤測試拆成四件事：能不能到達、焦點看不看得見、到達後能不能操作、操作後能不能離開或繼續下一步。這比只背檢核點更容易被團隊執行。

  • 可到達：連結、按鈕、欄位、自訂元件與主要操作都能取得焦點。
  • 可看見：焦點樣式有足夠對比與面積，不只靠瀏覽器預設被意外移除。
  • 可操作：元件的鍵盤行為符合使用者預期，不需要滑鼠才能完成。
  • 可離開：元件有可操作的離開方式。Modal dialog 開啟時把焦點留在內部是預期行為；要確認能用鍵盤關閉，且關閉後焦點回到觸發位置或合理的下一步。

試做：走完一次表單錯誤與修正

在測試環境選一份表單，準備可辨識的測試資料。先確認不會寄信、扣款或改到真人資料，再測送出；不要直接拿正式購買或聯絡流程當練習。

  • 從表單前方開始，用 Tab 到各欄位，記下名稱與焦點位置是否清楚。
  • 漏填一個必填欄位後送出。確認能找到哪裡有錯、理解如何修正，而且原本填好的資料仍保留。
  • 只用鍵盤找到錯誤欄位並修正，再次送出。確認完成訊息可被找到，不只是按鈕換色。
  • 記錄頁面、瀏覽器、操作步驟、預期與實際結果，修正後用同樣步驟重測。螢幕閱讀器是否朗讀錯誤或完成訊息，需另行實際測試。

最常見的鍵盤問題

鍵盤問題通常不是單一屬性錯誤，而是語意、樣式、JavaScript 行為和狀態管理一起造成。尤其是自訂元件，不能只做得像按鈕或選單，還要真的有按鈕或選單該有的操作方式。

  • 用 div 或 span 做互動元件，但沒有鍵盤操作。
  • CSS 移除 outline，卻沒有補上清楚焦點樣式。
  • Tab 順序跟畫面順序不同，讓使用者迷路。
  • dialog 開啟時焦點沒有移入，關閉後沒有回到觸發按鈕。
  • 單頁應用程式切換頁面後，焦點仍停在舊位置或不可預期的位置。

DevCheck 可以輔助，但仍要用真實流程判斷

DevCheck 可以協助團隊在目前頁面做初步檢查、觀察焦點路徑與搭配人工檢視輔助討論問題。但工具不能替你判斷每一個流程是否合理，也不能保證輔助科技使用者一定能完成任務。

比較可靠的做法是把 DevCheck 當成 release 前的檢查入口，再由 QA、工程或產品負責人用鍵盤實際走完主要流程。能自動抓的先修，無法自動判斷的就記錄成流程風險。

相關頁面