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

如何檢查鍵盤焦點路徑？用視覺化方式看懂 Tab 順序

鍵盤焦點順序會影響使用者能否順利理解與操作頁面。這份指南說明互動元素能不能被聚焦、焦點能不能移動到所有必要區域、是否會被困住，以及如何用 DevCheck 輔助人工檢查。

最後更新:

重點摘要

  • 鍵盤操作不是只確認 Tab 鍵能不能移動，也要確認移動順序是否符合頁面與任務脈絡。
  • 焦點順序可能受到 DOM、tabindex、彈窗、展開內容、RWD 與動態狀態影響。
  • 視覺化 Focus Path 提供推估路徑，仍需實際按鍵核對；它不會自動判定 WCAG 是否通過。

為什麼焦點順序值得單獨檢查

鍵盤焦點順序是操作控制項的一種路徑；螢幕閱讀器另外還有閱讀模式、標題與地標導覽，所以走完 Tab 不等於測完所有閱讀方式。當焦點順序和任務或閱讀脈絡差太多時，使用者可能仍然可以按到元素，卻很難理解自己目前在哪裡、下一步能做什麼。

因此，焦點順序檢查不只是「每個元件能不能被 Tab 到」。它也在確認使用者是否能用可預期的方式完成主要任務。

焦點順序不是單純由畫面位置決定

一般情況下，焦點順序會跟 DOM 順序有關，但 tabindex、動態插入的內容、彈窗、選單、展開區塊與 iframe 都可能改變當下的操作路徑。

RWD 也會讓問題更明顯。桌機版看起來合理的畫面順序，到了手機寬度可能換行或重排；如果 DOM 順序沒有跟任務脈絡一致，鍵盤路徑就可能變得難以預期。

<label for="task-name">姓名</label>
<input id="task-name" name="name" autocomplete="name">
<label for="task-email">電子郵件</label>
<input id="task-email" name="email" type="email"
  autocomplete="email">
<button type="button">預覽內容</button>

把這段放進測試頁，從姓名欄位依序按 Tab，預期到電子郵件，再到預覽按鈕；Shift + Tab 則反向移動。這只示範焦點順序，沒有實作預覽功能。不需要用正數 tabindex 排序；若順序不合理，先檢查 DOM 與 CSS 排列，再在窄螢幕重測。

修正前後：不要用正數 tabindex 重排簡單表單

以下是刻意做錯的測試片段，不要放進正式頁面。DOM 先放姓名再放電子郵件，但正數 tabindex 讓鍵盤先到電子郵件。

  • 收合內容仍被 Tab 到：先檢查是否只改 opacity 或 aria-hidden。修正時讓實際收合內容不再參與操作，例如合適地使用 hidden；不要只靠 aria-hidden，因為它不會阻止鍵盤聚焦。若焦點在即將隱藏的內容裡，先移回觸發控制項。
  • 關閉對話框後焦點不知去向：記錄開啟者與關閉前位置，確認關閉後回到仍存在的觸發控制項，或符合後續任務的合理位置。實際開啟、關閉和再次 Tab，而不是只看 DOM 屬性。
<label for="task-name">姓名</label>
<input id="task-name" name="name" tabindex="2">
<label for="task-email">電子郵件</label>
<input id="task-email" name="email" type="email" tabindex="1">
<button type="button">預覽內容</button>

在獨立測試頁從頁面起點按 Tab，修正前是電子郵件→姓名→預覽。刪除兩個正數 tabindex，採用上一段原生 HTML 範例，則是姓名→電子郵件→預覽；Shift+Tab 反向走。這個例子不代表每種視覺順序差異都違反 WCAG：重點是順序能否保留意義與操作關係，不是要求座標完全相同。

常見焦點路徑問題

有些焦點問題不是自動化工具一定能直接判定的錯誤，而是需要人看畫面、任務與互動狀態後確認。下面這些情況通常值得停下來檢查。

  • 互動元素看起來可操作，卻無法被鍵盤聚焦。
  • 焦點突然跳到畫面很遠或目前視窗外的位置。
  • 視覺上在上方或較早出現的內容，Tab 順序卻很後面。
  • 彈窗開啟後，焦點仍然跑到背景頁面。
  • 關閉彈窗、選單或提示後，焦點沒有回到合理位置。
  • 隱藏、不可見或不該操作的元素仍然被 Tab 到。
  • 焦點在選單、彈窗或元件內反覆循環，使用者無法離開。
  • 自訂元件看起來可以操作，但鍵盤無法到達或順序不清楚。
  • RWD 後畫面順序改變，但焦點順序仍停留在原本的桌機脈絡。

傳統檢查方式的限制

一直按 Tab、看瀏覽器的 focus outline、用書籤工具標數字，都是有用的做法。但真實頁面常常很長，元素可能分散在導覽、主內容、側欄、頁尾、彈窗與動態區塊之間。

當焦點跳到遠處或看不見的位置時，只看當前畫面或只看數字，很難快速理解整體路徑。團隊也比較難討論「這一段到底是合理順序，還是需要調整」。

視覺化 Focus Path 可以補上什麼

DevCheck 的 Focus Path 從目前頁面收集候選可聚焦元素，依頁面結構與 tabindex 推估順序，再以編號、線段與縮圖呈現。這不是記錄你每次按 Tab 實際到達的位置。下方小視窗顯示路徑縮圖與目前視窗範圍，協助找到需要複查的區段。

圖上的每個點不一定對應一次 Tab：原生單選群組通常只有一個 Tab 入口，群組內用方向鍵選擇；分頁標籤、選單等複合元件也有各自的按鍵方式。路徑可以讀取開放的 Shadow DOM，但不涵蓋 iframe 框架內部或封閉的 Shadow DOM。請實際用 Tab、Shift + Tab 與適用的方向鍵完成任務，並在相關框架內容中另行檢查。

橘色線段只代表「疑似需要人工確認」的跳躍，不代表已確認錯誤，也不是 WCAG 失敗判定。焦點順序是否合理，仍需要依照頁面目的、畫面排列、互動狀態與使用者任務判斷。

建議檢查流程

焦點路徑檢查最好放在實際頁面狀態中進行。表單錯誤、登入後內容、展開區塊、彈窗與 RWD 斷點都可能改變使用者真正遇到的順序。

  • 打開要檢查的頁面或流程狀態，不只看空白初始畫面。
  • 先用鍵盤走一次主要任務，感受是否能預期下一個位置。
  • 開啟 Focus Path，從整體路徑看是否有明顯跳躍或順序不一致。
  • 特別檢查橘色疑似跳躍區段，確認它是合理流程還是需要調整。
  • 測試彈窗、選單、展開內容、表單錯誤與登入後狀態。
  • 改變視窗寬度或內容狀態後，重新整理路徑再看一次。
  • 把可疑段落交給設計、QA、工程或內容維護者一起討論。

誰適合做這個檢查

焦點路徑不是只有工程師能看。設計師可以確認畫面順序與操作順序是否一致；QA 可以把它放進測試案例；PM 可以檢查主要任務流程是否順；前端工程師可以修正 DOM 順序、focus management 或 tabindex；內容維護者也能在新增區塊後確認沒有破壞操作路徑。

重點不是讓每個人都取代無障礙專家，而是讓更多人能在發現問題的那一刻，先把問題看見、說清楚，再交給合適的人修正。

下一步檢查

依頁面內容選擇適用的下一步。有 PDF 才需要另外檢查文件；完成修正後仍要重測。

  1. 檢查可及名稱

    如何實作可及名稱

    確認按鈕、連結、表單控制項與互動元件是否有可理解的名稱。

  2. 檢查圖片替代文字

    如何寫出有意義的圖片替代文字

    依圖片在頁面中的用途判斷 alt，而不是只描述畫面上有什麼。

相關頁面