網站表單能只用鍵盤完成嗎？逐步走查焦點與送出路徑

不使用滑鼠逐欄測試焦點順序、可操作控制項與送出回饋，找出表單鍵盤操作中斷的位置，並整理成可重現的修正紀錄。

網站表單能否只用鍵盤完成，不能只看欄位能不能輸入；還要確認焦點會依可理解的順序移動、每一步都看得見，選單能操作，送出後也找得到成功或錯誤回饋。以下用一條實際任務走查，從頁面起點記到可重現的阻塞點。

準備無滑鼠測試

開始前先選一個實際會用到的表單，例如聯絡詢問、預約或訂閱，不要一開始就同時測不同頁面。用瀏覽器開啟頁面後，把滑鼠放到一旁，手只使用鍵盤；如果剛才曾以滑鼠點過欄位，重新載入頁面，避免焦點位置已被改變。先確認頁面沒有彈出視窗遮住內容，也沒有瀏覽器自動填入資料，否則你看到的結果可能不是一般訪客會遇到的路徑。測試環境用一筆不會真的送給團隊的資料；若表單可能寄信或建立案件，先改用安全的測試頁、明確標示的測試流程，或停在送出前觀察，不要為了驗證而產生真實聯絡。測前寫下任務，例如「找到姓名、填入信箱、選一個聯絡方式、送出並確認成功」，之後每個步驟都依照這個目標走，不要臨時跳到頁面其他連結。準備一張記錄表，欄位放步驟、按鍵、焦點所在、畫面反應與是否能繼續。整段操作只用 Tab 前進、Shift+Tab 後退、方向鍵移動選項、Enter 或空白鍵啟用，必要時再用 Escape 關閉清單；不同元件的按鍵可能不同，先觀察而不要連按猜答案。每到一個控制項就停一下，讀出它的名稱、目前值和狀態。若需要測試重來，先把游標移回頁面起點並重新載入，確保兩次路徑可比較。開始前也先確認表單旁的隱私說明與資料用途，測試只填虛構但格式合理的內容；不確定提交會連到哪裡，就停止在送出前並記錄理由。把鍵盤切換到英文輸入或中文輸入時都留意焦點是否還在原欄位，避免輸入法面板讓畫面看似沒有反應。完成一輪後不要立刻判定整個網站都可操作，結論只涵蓋這一頁、這一條任務路徑和當時環境。

逐欄移動鍵盤焦點

從頁面初始狀態開始，按一次 Tab，觀察焦點落在哪裡，再按一次並記下下一站。不要連續快速按到表單底部才回想順序；每停一站，就確認焦點對應的文字標籤、欄位用途和必填提示能否一起理解。當焦點移到輸入欄，直接輸入測試內容，再前往下一欄；檢查游標是否仍在欄內、字元有沒有被清掉，以及是否意外跳到別的控制項。表單前面常有導覽連結、搜尋或語言選單，這些若屬於正常頁面路徑就要記錄，但別把圖示或不可操作的文字算成欄位。到最後一欄後繼續按 Tab，確認送出按鈕是否能到達；再按 Shift+Tab 回走一遍，檢查前後方向是否一致、有沒有突然跳出頁面或困在單一區塊。若欄位是分組的，例如電話區碼加號碼，確認焦點順序能讓人明白要先填哪一格，並能自然離開整組。遇到跳過欄位時，先辨認它是刻意隱藏、尚未啟用還是鍵盤真的進不去；不要直接判定為錯誤。另開新一輪時保持同一瀏覽器寬度與相同起始位置，逐站比較預期任務和實際順序。可以在記錄表標出每個停止點的前一站、本站與下一站，這樣回報時能指出具體位置，而不只說「Tab 順序怪怪的」。特別留意一個容易忽略的狀況：焦點可能先經過頁首導覽，再進到表單，使用者若要反覆填寫，是否有清楚的跳至主要內容連結。記錄該連結能否用鍵盤啟動、啟動後畫面是否到達表單附近；沒有這類捷徑不一定表示任務被阻塞，但長頁面每次都要經過許多重複連結，值得列為改善項目。若頁面有多個表單或多組相同按鈕，辨認目前所在區塊，避免把其他區塊的控制項誤認成目標。

核對焦點可見狀態

焦點可見，代表使用者目前能知道鍵盤操作停在哪裡。每按一次 Tab，先找欄位外框、底色、底線或清楚的焦點框是否改變；再確認變化沒有被圖片、彈出選單、固定頁首或頁尾遮住。只靠文字游標閃爍不一定足以辨認焦點，尤其欄位已有內容時；用空白頁面背景和深色區塊各觀察一次，看看提示是否仍容易看見。若按鍵後畫面似乎沒有改變，暫停並試著輸入一個無害字元，確認焦點可能位於文字欄但外觀不明顯；立即刪除測試字元，再繼續。輸入框、按鈕、選項按鈕、核取方塊及自訂下拉選單都要各看一次，因為同一網站可能替不同元件套用不同樣式。用 Shift+Tab 回到剛才的欄位，檢查反向移動時焦點提示是否同樣清楚。若頁面捲動，確認目前焦點沒有被 sticky 區塊擋住，且欄位標籤仍在可視範圍；不要只截下未捲動的首屏當作證據。記錄「哪個控制項、哪種背景、按哪個鍵後看不出變化」比寫「焦點顏色太淡」更容易交給設計或前端重現。修正時先維持品牌配色與元件狀態清楚可辨，再由實際鍵盤路徑逐項複測。若頁面還有成功、錯誤或停用狀態，也分別看焦點框能否與狀態差異同時辨認；這些狀態常改變背景，可能讓原有提示消失。若需要比較差異，可以在焦點停留時截圖，但截圖應只呈現元件狀態，不要帶入測試者的真實資料。遇到顏色變化很細微時，記下焦點周圍的背景和元件狀態，再沿相同路徑確認一次。也要區分「焦點已到但樣式不明顯」和「焦點根本沒到」，前者記下外觀與背景，後者記下移動前後的控制項，方便負責人判斷要調整樣式還是鍵盤路徑。

操作選單與勾選項

用 Tab 移到選單、核取方塊和選項按鈕後，先讀出畫面上的名稱，再嘗試符合元件的按鍵。核取方塊通常可用空白鍵切換，選項按鈕可能用方向鍵在同組選項間移動；但自訂元件的行為不一定相同，所以先操作一個項目，觀察是否選取、展開或改變文字。原生下拉選單可用方向鍵選項並按 Enter 確認；自訂清單則要確認開啟後焦點仍在清單內，能移動到每個選項、看見目前項目，並可用 Escape 關閉且回到原控制項。若清單開啟後按 Tab 直接離開，檢查它是不是有意讓清單常駐，還是選項根本無法被鍵盤選到。勾選同意或偏好設定時，確認空白鍵只切換目前項目，不會讓整頁意外捲動；切換後狀態需在畫面上看得出來。對互斥選項逐一測試，看看左右或上下移動是否更新選取狀態，且按 Shift+Tab 可返回問題說明。若有日期、地址建議或自動完成清單，輸入部分內容後觀察提示出現的位置，逐項走訪並確認可選擇；也檢查按 Escape 後已輸入文字是否保留。遇到按鍵無反應時，先記下瀏覽器、元件當下狀態與操作，再重新載入重試一次，避免把網路延遲誤認為鍵盤問題。如果 Tab 鍵在選項間移動而不是離開整組，記下這個行為及每次按鍵後的選取狀態。完成一組後再按 Tab，確認焦點離開整組並前往下一個合理項目；反方向回走時也要能到達前一個欄位。若選項旁有補充說明，確認焦點停在項目時仍看得到對應文字，避免只知道「第幾個選項」卻不知道內容。這些觀察可用來分辨文字說明不足、控制項未連結標籤或鍵盤操作中斷等不同問題。

完成送出與返回

資料填完後，不要立即送出；先從最後一個欄位繼續按 Tab，確認送出控制項能取得焦點，名稱清楚且不是只顯示圖示。按 Enter 或空白鍵前，檢查是否會建立真實聯絡紀錄；若用途不明或副作用無法排除，就停在此處並把「送出前路徑可達」與「送出結果未驗證」分開記錄。若有安全測試環境，送出後觀察焦點停留位置、頁面是否跳到提示、成功訊息是否能被看見，以及原有內容有沒有消失。接著以 Shift+Tab 回到送出按鈕，再往前走，確認返回時不會漏掉最後一個欄位。若必填欄位留白時可安全測試，送出後記下錯誤是否指出欄位、說明需要修改什麼，焦點是否帶到第一個錯誤或錯誤摘要；若焦點沒有移動，仍要確認使用者能從鍵盤找到提示和欄位。修正錯誤後再次送出，查看原先填寫的資料是否保留，避免要求從頭重填。把結果記成狀態，不要只寫「成功」：例如「可送出，成功訊息在表單上方，但焦點停在原按鈕」；若停在錯誤提示前，也具體記下使用者需要走幾站才能返回欄位。可把送出前後分成三個觀察點：最後一欄到送出按鈕的移動、按下按鈕後的畫面變化、以及錯誤修正後重新送出的結果。比如在明確的測試頁中，若漏填主旨欄，記下頁面是否指出主旨、焦點是否仍留在按鈕，以及回到該欄需要經過哪些控制項；這只是示範記錄方式，不代表所有表單都應使用相同欄名或呈現方式。若成功後頁面切換，注意返回瀏覽器上一頁時表單值是否還在、焦點是否有可理解的位置；若成功後表單清空，也記下回到表單入口是否能繼續完成後續任務。

記錄阻塞步驟

每次發現阻塞，都用一行描述當時任務、起始位置、按下的按鍵、焦點停留處和實際畫面反應。把「無法操作」拆成可重現的句子，例如「從電話欄按 Tab 兩次，焦點看不出落點，輸入內容沒有出現在任何欄位」；若只是成功狀態未被宣告，記清楚送出後頁面如何改變，不要籠統寫成送出失敗。可用下表把觀察轉成下一步：

回報時附上頁面名稱而非含個資的完整網址，遮掉姓名、信箱、電話及表單內容；若需要螢幕畫面，先確認截圖沒有敏感資訊。把問題交給網站負責人時，指出最短重現步驟與預期結果，例如按 Tab 應能看見哪個按鈕、按 Enter 後應能辨認什麼回饋。修正後從同一起點重走整條路，並再做一次反向檢查；只驗證出錯的單一欄位，可能漏掉新的順序或焦點變化。若鍵盤路徑已完整，再以輔助科技做另一輪核對，那是延伸檢查，不能取代本次無滑鼠走查。記下完成日期、測試瀏覽器與未測項目，方便團隊重現且不把一次結果當成永久保證。若一輪中途遇到不確定結果，標成待確認而不是猜測原因；換成另一種瀏覽器或裝置時，另外開一列記錄，不把兩種環境的觀察混在一起。若需把表單放回整體網站收客流程檢視，可到ZhenheAI 首頁了解企業網站與表單收客能力。