網站只用鍵盤能操作嗎？逐頁檢查焦點順序與離開方式
從一條任務路徑開始，用鍵盤逐頁檢查焦點是否可見、順序是否合理、表單與彈窗能否完成及離開，並留下可重現的修正紀錄。
鍵盤測試的目標不是確認 Tab 能不能移動，而是不用滑鼠完成訪客最常走的任務，並隨時看得出目前位置、理解下一步，也能離開暫時開啟的介面。一次測試應留下可重現的路徑與阻塞點，避免只記「不好用」。本文從路徑、焦點、彈窗到修正後重走，整理成逐頁執行的方法。
選定主要操作路徑
先把「主要操作路徑」寫成訪客要完成的任務，而不是列出網站所有頁面。選一個入口，例如首頁進入服務介紹，再到聯絡表單並完成送出前檢查；另選一個常用任務，例如開啟導覽、找一篇文章或展開常見問題。每條路徑標明起點、經過的頁面、每一步預期操作和成功條件。若網站有登入、篩選、購物車或表單，按訪客實際使用順序納入；不相關的管理介面不必混在同一輪。先設定範圍，才不會只在首頁按幾次 Tab 就宣布全站可用。
測試前清空鍵盤附近的滑鼠，重新載入頁面，讓游標停在網址列或瀏覽器起點，再以同一方式進頁；記下是否需要跳過重複導覽。每一步先寫使用者想做什麼，例如「從首頁找到聯絡入口」，不要預設按幾次 Tab，因為插入新連結後次數就變。成功條件要可觀察：焦點落在該入口、Enter 後進到正確頁面、能辨認欄位名稱、送出前能修正資料。用不同路徑測試頁尾、搜尋或登入，不要把一條流程的結果推論成全站結論。若頁面有非連結的互動控制，也將它列入實際任務，不用只看網址能否開啟。選擇時可用三個條件排序：是否影響主要轉換任務、是否含有較多互動、是否最近有改版。優先挑一條跨頁且含表單或彈層的流程，再補首頁和文章頁各一條；這是抽樣策略，不是全站覆蓋證明。若頁面因登入或權限不同而呈現不同內容，把狀態分成兩條路徑記錄，避免拿公開訪客的結果代表登入後畫面。也可先寫下預期會遇到的互動種類，避免走到頁面才臨時決定測什麼。
用鍵盤走完整頁
從路徑起點開始，只用 Tab 前進、Shift+Tab 後退，再用 Enter 或 Space 啟動當前控制項；方向鍵只在選單、單選群組或其他有方向鍵操作模式的控制內試用。每次移動都確認兩件事：視覺上能看見焦點在哪裡，位置也符合閱讀與操作的先後。焦點外框若被圖片、固定頁首或浮層遮住，就記為不可見；若它跳過一個必需按鈕、先到頁尾才回到正文，則比較頁面呈現和焦點次序，不能只憑Tab次數判定錯誤。按鍵時不要快速連按，讓頁面有時間捲動，並看清焦點是否跟著捲動到視窗外。
逐項檢查頁首連結、主要內容、表單、頁尾與頁面中的展開控制。遇到可輸入欄位，確認游標能進入、文字可輸入、提示不會取代欄位名稱；遇到下拉選單或分頁，先觀察焦點，再按適用按鍵，確認選項改變後仍知道目前選到什麼。普通連結應能開啟目的頁，按鈕應執行其動作；若外觀像控制項卻完全不能聚焦，記下它的文字和位置，不要改用滑鼠把流程「補完」。反向用Shift+Tab走一遍，可發現只測正向時漏掉的焦點跳躍或返回困難。每頁至少從頁面進入、完成本頁任務、離開或移往下一頁三處記錄結果。另外留意焦點是否被固定導覽遮住、跳頁後焦點留在已消失的按鈕，或頁面更新後突然回到文件開頭。若長頁面有「跳至主要內容」連結，確認它能由鍵盤觸發並將視線與焦點帶到主內容；若沒有，記錄重複按Tab才能越過導覽的成本，不要自行增加一個未驗證的捷徑。把每次按鍵後的所在元素寫下來，才能比較順序與版面閱讀先後。
標記焦點遺失位置
把焦點的「看不見」和「順序不對」分開記，兩者修法不同。看不見是鍵盤操作已移到控制項，但畫面沒有清楚標示目前位置；順序不對則是焦點可見，卻讓人先到不相關的區塊、漏過任務必需項目，或在閱讀順序中來回跳。另記第三種情況：預期可操作的元素完全收不到焦點。不要只寫「Tab怪怪的」，請記下前一個可見焦點、問題元素的可辨識名稱、再按一次Tab後的位置，以及當時頁面是否有固定導覽或動態內容。
逐頁用同一格式留下證據：頁面名稱或實際網址、操作步驟、預期位置、實際位置、能否看見焦點、是否可啟動、離開方式。截圖可圈出焦點消失前後的畫面，但若問題只有按鍵後狀態改變，補記當下按了什麼、焦點落在哪個元素，不要只交一張靜態圖。遇到焦點被程式移走的狀況，先停止連按，按Shift+Tab一次並觀察是否回到合理位置；再按Tab一次辨認是否重現。這樣能區分短暫動畫、頁面跳動和真正失焦。
例如焦點從「聯絡我們」移到頁首標誌後，下一次Tab直接落在頁尾法律連結，正文中的表單入口卻沒有可見焦點，就記下這三個位置與按鍵順序。這比籠統寫「順序錯」更能讓修正者定位。標記時也分辨「看不到焦點」與「有焦點但名稱無法辨認」：前者需要檢查樣式與遮蔽，後者要記錄控制項是否有可辨識文字或狀態。當內容載入或驗證錯誤後，重新觀察焦點是否移到錯誤摘要或第一個有錯欄位；如果沒有，不要猜應該跳到哪裡，記下目前焦點和使用者接下來找錯誤所需步驟。最後為每個問題保留一個最短重現序列，方便修正後逐步核對。
檢查彈窗進出方式
先找出觸發彈窗、抽屜選單、下拉選單或確認框的按鈕，確認它本身可以聚焦並以鍵盤開啟。開啟後立即觀察焦點落點：若是需要先處理的對話框，焦點應進入對話框內可操作的位置，對話框開著時用Tab前進與Shift+Tab後退，不應跑到背景頁面繼續操作。逐項確認標題、主要內容、輸入欄位、取消和確認控制項都能到達，焦點指示仍清楚可見；若內容很長，留意焦點移動時視窗是否跟到目前控制項。
再分別測試Escape和畫面上的關閉控制，確認能關閉的方式與介面提示一致。關閉後焦點應回到原本的觸發按鈕附近，讓使用者接續原任務；若焦點跑回網址列、跳到文件開頭或完全不見，記錄成返回問題。不是每種展開介面都該把焦點鎖在其中：非模態選單若設計為可繼續瀏覽，應能依其預期方式離開；關鍵在於背景能否被誤操作、目前狀態是否說得清楚，以及使用者是否有可預期的退出路徑。
測試時避免只確認「按Escape會關」，也要確認關閉後沒有留下遮罩、背景仍能正常聚焦、再次打開時落點一致。若彈窗包含錯誤訊息，修正欄位後再關閉並重開一次，確認焦點仍可完成原操作。若按鈕打開的其實是頁面內展開區而非對話框，確認狀態改變可被看見，接下來的Tab能進入新內容，收合後焦點仍在合理位置。若確認動作會送出資料，先用不會造成外部提交的測試內容，避免檢查時真的建立訂單或寄出訊息。遇到第三方嵌入視窗無法退出，記下框架名稱或可見標題和離開前最後一個焦點；這能區分自家介面與外部元件，但不預先認定責任歸屬。
記錄阻塞步驟與裝置
紀錄要讓另一位修正者不用猜你按了什麼。至少寫下重現條件：頁面路徑、裝置類型、作業系統與瀏覽器、使用的鍵盤、視窗大小、登入狀態，以及從哪個入口開始。每一筆問題加上按鍵序列、預期結果、實際結果和阻塞程度：只是外框不清楚、必需內容順序難懂，還是完全無法完成任務。若同一頁有多個問題，分開列項並標出先後，避免把焦點不可見和按鈕無法啟動合成一個模糊工單。必要時附上遮去個資的截圖或短錄影，並保留可公開重現的測試資料。
假設某網站的聯絡表單可以逐欄輸入，但按Tab離開最後一欄後，焦點落到背景導覽，畫面上仍有對話框遮罩，且沒有可聚焦的關閉按鈕。紀錄可寫成：「鍵盤開啟聯絡表單；填完最後一欄；Tab後離開表單並進入背景；無法找到關閉控制；任務停住。」另附裝置、瀏覽器和視窗大小，並記下重開頁面後能否重現。這是明確的重現描述，不代表所有裝置都發生，也沒有替問題猜測程式原因。請由同事按相同步驟重走；若結果不同，補記差異，不要把單次觀察擴大成全站或所有使用者的結論。可以把問題依「能否完成主要任務」排序：任務完全卡住先處理，其次是焦點無法看見或返回位置不明，最後才是少量不影響操作的順序差異。每筆都標註重現次數與結果是否一致；一次沒重現也要保留原紀錄，並註明當次環境，不能因此刪除。若交給開發者或網站維護者，提供最小必要截圖與步驟即可，截圖先遮住姓名、信箱、電話等個資，避免測試資料隨工單外流。
修正後重走同一路徑
修正前先按紀錄判斷問題屬於哪一類：焦點樣式不明顯，先確認控制項有清楚可辨的焦點外觀；順序跳躍，檢查頁面實際結構與互動元件的設計順序；元素不能聚焦，確認它是否真的是連結、按鈕或可操作欄位；彈窗卡住，檢查開啟後的焦點管理與關閉後返回位置。若只有靠調整畫面排列才能讓順序看似合理，不要直接在多個元素加任意Tab索引值，先釐清內容與操作順序是否一致。每次集中修一個根因，記錄改了哪一頁、哪一種控制項，保留原本失敗步驟作為重走清單。
修完後從同一入口重新載入，用相同裝置條件、鍵盤順序和任務走完原路徑，逐點比較焦點是否可見、順序是否合理、控制項能否啟動、彈窗能否進出。再用Shift+Tab逆向檢查一次，並重走一個相鄰任務，確認修正沒有把焦點移到不相關位置或令其他控制項失效。只在這條路徑、這個條件下通過，就記為該範圍的複測結果；其他頁面、不同視窗大小或不同互動仍要逐項測，不能以一次成功宣稱整站都沒有鍵盤阻塞。複測紀錄不要覆寫原始失敗證據，另增一欄寫通過、部分改善或仍阻塞，並附實際按鍵順序。若修正後焦點看得見但仍需繞很久才到主要動作，這是改善但不是任務完成；若焦點能移動卻不能啟動，仍算阻塞。完成一條路徑後再回到問題頁重載，確認開頁初始焦點正常，不因上一輪測試留下特殊狀態。把尚未覆蓋的頁面列出，下一輪從影響訪客較大的路徑開始。
下一步先挑一條常見訪客路徑，建立缺失清單並保留重現步驟；若要進一步整理網站改善方向，可至ZhenheAI 官網查看聯絡入口。