AO2 FIELD GUIDE · N067 · WordPress 與轉換體驗
鍵盤詢問流程測試從產品入口一路走到欄位、錯誤修正與成功狀態。附操作紀錄與缺陷分級，檢查焦點順序、可見位置及元件行為，不把按得動 Tab 就當成全站無障礙驗證。
網站看起來有按鈕，並不代表不使用滑鼠的人也能完成工作。先挑一條明確任務：找到產品資訊、開啟詢問、填入資料、修正錯誤並確認結果。這條路徑能找出具體阻礙，但不能替代全面的無障礙評估。
鍵盤詢問流程測試，先定一條可重做的任務
選一個起點、角色與結束條件，例如從指南進入相符服務，找到詢問表單，補齊必要資料後辨認送出結果。記錄瀏覽器、裝置、日期與頁面版本，事先準備合適測試資料。測試不是隨意按幾次 Tab，而是要知道哪個工作完成、哪個操作卡住，以及其他人能否重做相同觀察。
W3C 的鍵盤準則說明內容功能應可透過鍵盤介面操作，對依賴移動路徑的功能有相應例外。可被焦點碰到，不等於可被理解並完成操作。本文聚焦詢問路徑，另需檢查的文字替代、對比、朗讀順序與其他需求，不因這條路徑通過就一併宣稱完成。
白話例子：路線畫在地上，門也要真的打得開
想像大樓走道有清楚標線，但到櫃台前的門只能用某種手勢打開；有些人看得見路，仍進不去。網頁上的焦點像目前站的位置，標籤像門牌，Enter 或元件適合的按鍵像開門方式。只畫一圈外框，卻無法展開選單、選項或關閉對話框，仍會讓任務中斷。
這是操作比喻，不表示所有元件都用同一按鍵。原生連結、按鈕、選單與自訂控制有各自互動方式，測試者應核對元件角色與設計模式，不能要求每個項目都用 Tab 逐一走訪。也不要假設熟練測試者能猜出來，一般使用者就一定知道怎麼繼續。
沿著焦點前進，確認順序、名稱與退路
先用 Tab 前進與 Shift＋Tab 返回，觀察焦點順序是否跟任務合理銜接，當前位置是否看得見、會不會被固定頁首遮住。連結或按鈕的名稱應說明動作，不能出現幾個沒有區別的「這裡」。若有展開式內容或對話框，開啟、關閉與返回原操作位置都需能接續。
操作選單、選擇欄位與其他控制時，依其模式測試合適按鍵，例如按鈕的啟動、選項移動及關閉。要特別記錄焦點是否進入不可離開的區域，或突然跳到頁尾。從滑鼠點進元件後才開始按鍵，可能漏掉「根本到不了入口」的問題，因此保留從頁面起點開始的完整紀錄。
| 步驟 | 操作與觀察 | 通過的具體結果 |
|---|---|---|
| 進入頁面 | Tab 與返回，辨認當前位置 | 重要入口可到達且焦點可見 |
| 展開與選擇 | 依元件模式啟動、移動與關閉 | 操作可完成且能離開 |
| 修正錯誤 | 觸發缺漏，找到提示及欄位 | 可理解原因並接續填寫 |
| 確認結果 | 辨認成功或仍待處理狀態 | 不用猜測是否需要再送 |
錯誤與成功狀態，也要納入同一條路徑
先故意漏填一項必要資料，再觀察錯誤摘要、欄位提示與焦點位置是否幫助修正。不能只靠紅色邊框，也不能一送出就清空全部內容。修正後回到適當位置繼續，確認舊錯誤不會誤導。一般填寫邏輯可回連表單指南，復原細節則使用專門的錯誤處理矩陣。
成功畫面需讓使用者辨認目前狀態與接下來可做什麼。自動化工具透過 DOM 直接定位或填值，可以驗證某些介面行為，但不能證明人真的按鍵走得通；螢幕閱讀器相容性也不能由鍵盤測試推論。若沒有實際執行某一項，紀錄為未測，而不是把工具回傳成功一律算通過。
按影響修正並重測，不把例外藏在總分裡
以阻止任務、造成誤操作及增加理解負擔分別描述問題。每筆缺陷保存起點、按鍵順序、實際焦點、預期行為與畫面證據；只寫「無障礙不好」很難交辦。先處理無法到達、無法操作或被困住的節點，再改善名稱與提示，最後重走完整路徑，避免局部修好卻改壞其他步驟。
測試通過的範圍，應跟你實際走過的任務一樣大。交接時列已測環境、未測元件、替代路徑與責任人。手機、不同瀏覽器及輔助工具可再按用途擴充驗證，不把單一桌機結果包裝成全面合規證明；後續模板或表單更新時，用同一任務回查。
| 影響 | 記錄例子 | 重測方式 |
|---|---|---|
| 無法完成 | 到不了提交控制或無法離開 | 從起點重走該路徑 |
| 容易誤操作 | 焦點消失或名稱無法區分 | 核對位置與動作含義 |
| 無法理解狀態 | 錯誤只靠顏色、結果不明 | 重新觸發錯誤及成功 |
| 尚未涵蓋 | 未測瀏覽器或輔助工具 | 列範圍，不當作通過 |
常見問題
用 Tab 可以走完所有按鈕，就算無障礙完成嗎？
不能這樣宣稱。還需確認元件可操作、焦點可見、順序合理、錯誤與狀態能理解，而且這只是一部分需求。先記錄實際任務、環境與未測範圍，再處理具體阻礙。全面評估仍可能包含螢幕閱讀器、文字替代、對比及其他項目，不用一條路徑的成功替代全部驗證。
自動化填表成功，可以取代實際鍵盤測試嗎？
不能完整取代。工具可能直接定位欄位與按鈕，繞過焦點順序、不可見入口或自訂元件操作。把自動化結果限於實際驗證的部分，再由測試者使用鍵盤重走任務。保存按鍵、位置與狀態，未測就明確列未測；也不能由 DOM 可讀推論所有輔助工具都能理解。
測試時可以直接送出正式網站詢問嗎？
先確認環境、接收端與測試安排。可在合適測試站使用明確標記資料走完整成功流程；正式站若只核對入口與欄位，可先停在送出之前。確實需測正式接收時，安排可辨識的紀錄與接手者，避免混入真實業務需求。報告分清觀察到哪一步，不把未送出的流程算成成功提交。
白話總結：不只找得到門，也要開得了門
用一條真實任務串起焦點、操作、修正與結果；把實際測到的範圍講清楚。
- 定路徑：固定起點、情境、環境與完成條件。
- 走按鍵：檢查到達、啟動、返回、錯誤修正與狀態。
- 修再測：按影響交辦缺陷，重走路徑並列未測範圍。
完成條件：使用者可不靠滑鼠完成已定義任務，問題與未涵蓋範圍都有可回查紀錄。
來源與方法範圍
資料查核：2026 年 10 月 24 日。來源支持文中對應的準則與平台說明；工作表、判斷步驟及已標示的假想情境由 AO2 整理，實際使用時依產品資料與現行設定核對。
