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

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

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

重點摘要

  • 如果使用者不能不用滑鼠完成主要任務，網站就存在嚴重無障礙風險。
  • 鍵盤測試要看能不能到達、看得見焦點、操作後狀態是否清楚、能不能離開。

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

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

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

  • 用 Tab 前進、Shift + Tab 返回。
  • 用 Enter 或 Space 操作按鈕、選單、checkbox、radio 與展開區塊。
  • 用 Escape 關閉可關閉的 dialog、popover 或 menu。
  • 在表單錯誤、載入完成、路由切換後重新確認焦點位置。

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

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

  • 可到達：連結、按鈕、欄位、自訂元件與主要操作都能取得焦點。
  • 可看見：焦點樣式有足夠對比與面積，不只靠瀏覽器預設被意外移除。
  • 可操作：元件的鍵盤行為符合使用者預期，不需要滑鼠才能完成。
  • 可離開：選單、dialog、carousel、日期選擇器等元件不會把焦點困住。

最常見的鍵盤問題

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

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

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

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

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

相關頁面