鍵盤 Tab 鍵順序：無需開發人員即可測試和修復

Tab 鍵順序混亂不只是看起來凌亂，它可能讓人完全無法使用您的網站。 按下 Tab 應當讓焦點按合理的順序依次經過每個互動元素，而焦點永遠到不了的內容，對只用鍵盤的使用者來說根本無法操作。您只需要 Tab 鍵，大約 60 秒就能測試自己的網站。

要點

• Tab 鍵順序是有人按下 Tab 鍵時焦點移動的先後次序，不涉及滑鼠。Shift+Tab 沿同一順序向後移動。
• 這不是小眾問題。 任何無法可靠使用滑鼠的人，無論是因為手抖、癱瘓、重複性勞損，還是暫時性受傷，都完全依賴鍵盤導航來使用網站。
• 有兩種不同的失敗模式，其中一種比另一種嚴重得多。 順序混亂令人惱火。而 Tab 完全到不了的互動元素，是硬性阻斷，而不是可用性方面的抱怨。
• 您現在就可以自己測試，無需開發人員，也無需特殊工具。 點選位址列，然後反覆按 Tab，觀察焦點去了哪裡。
• axe-core 會以高置信度自動修復這個問題的一種特定形式，即 tabindex 的正值，並標記幾個確實需要人來判斷的相關問題，因為判斷順序是否「合理」需要理解頁面。

Tab 鍵順序到底是甚麼

按下 Tab 會把鍵盤焦點移到頁面上的下一個互動元素：連結、按鈕、表單欄位，以及使用者可以操作的任何東西。Shift+Tab 則向後移動。預設情況下，這個順序遵循元素在底層 HTML 中出現的先後，通常與視力正常的使用者從上到下閱讀時遇到它們的順序相同。

可見的焦點指示器，通常是圍繞當前焦點元素的輪廓，讓鍵盤使用者知道自己在哪裡。沒有它，或者背後沒有合理的順序，鍵盤導航就無法使用，儘管使用滑鼠的人看不出任何問題。

為甚麼這很重要

無法使用滑鼠的人，無論是因為手抖、癱瘓、缺失肢體、帕金森病、漸凍症，還是像手腕骨折這樣普通的原因，仍然需要結賬、填寫表單和瀏覽選單。鍵盤是他們完成這一切的方式。螢幕閱讀器使用者也會用 Tab 鍵遍歷互動元素，作為在頁面中移動的幾種方式之一，所以這與螢幕閱讀器無障礙有重疊，但並不完全相同。

混亂的 Tab 鍵順序是真正的可用性問題：焦點從頁首連結直接跳到頁尾按鈕，跳過整個頁面中部，迫使人去猜測並回頭。但最終仍然可以瀏覽。焦點完全到不了的互動元素，則是性質上不同，而不是程度上不同：鍵盤使用者字面上無法用 Tab 到達的按鈕，就是他們無法按下的按鈕，僅憑鍵盤沒有任何變通辦法。

60 秒 Tab 鍵測試

1. 先點選一箇中性位置，比如瀏覽器的位址列，這樣您從一個已知的位置開始，而不是焦點碰巧落在的任何地方。
2. 反覆按 Tab，觀察可見的輪廓如何在頁面中移動。它是否按大致符合您視覺上從上到下、從左到右瀏覽頁面時的順序移動？
3. 嘗試啟用您到達的元素。 在連結或按鈕上按 Enter，按空格鍵切換核取方塊。它在鍵盤上真的有效嗎，而不只是在視覺上獲得焦點？
4. 檢查每個互動元素都有機會獲得焦點。 選單項、表單欄位、按鈕、日期選擇器或手風琴之類的自定義小元件，都應該能透過這種方式到達。
5. 留意陷阱。 如果 Tab 或 Shift+Tab 曾經卡住，無法讓您離開某個元素，那比單純的順序問題更嚴重，這是 WCAG 2.1.2 下的鍵盤陷阱，需要立即修復。
6. 確認您確實能看到自己在哪裡。 如果焦點在移動但沒有可見輪廓顯示位置，那是一個獨立但相關的失敗，即 WCAG 2.4.7「焦點可見」，儘管它不是這裡的主要話題，也值得記下。

混亂的 Tab 鍵順序實際上是甚麼樣的

tabindex 的正值。 試圖強制特定順序的開發人員有時會新增明確的數字：tabindex="1"、tabindex="2"，依此類推。這會覆蓋文件的自然順序，而且一旦以後有人新增新元素卻沒有對周圍所有元素重新編號，它就會失效。

<!-- 失敗：強制編號，之後會逐漸失去同步 -->
<input tabindex="3" name="email">
<input tabindex="1" name="name">
<input tabindex="2" name="phone">

<!-- 透過：不覆蓋，由文件的自然順序處理 -->
<input name="name">
<input name="phone">
<input name="email">

只改變視覺順序、不觸及底層順序。 flexbox 或 grid 佈局中的 order 之類 CSS 屬性，可以改變視力正常的使用者看到的內容，卻不改變 Tab 鍵遵循的實際 HTML 順序。結果是：滑鼠使用者和鍵盤使用者在同一頁面上體驗到兩種不同的順序，而螢幕上看不出任何問題。

沒有真正鍵盤支援的自定義元素。 一個樣式做成按鈕的 <div>，繫結了點選處理程式，卻沒有 tabindex="0" 也沒有鍵盤事件處理，對 Tab 導航來說完全不可見。這不是順序混亂，而是徹底阻斷，因為鍵盤使用者根本無法到達它。

仍然可獲得焦點的隱藏元素。 已摺疊的移動選單，其連結在技術上仍然存在於頁面中，或者本應不可見卻仍能接受焦點的元素，會產生「幽靈」Tab 停靠點：焦點明顯在移動，卻移向使用者看不見的東西。

axe-core 能發現甚麼，以及只有您能判斷甚麼

規則	檢查內容	修復路徑
tabindex	元素有正的 tabindex 值	始終自動修復，重寫為 0
aria-hidden-focus	隱藏的元素仍可單獨獲得焦點	自動修復，盡力而為，範圍較窄：修復該元素本身，而不是僅僅包含可聚焦元素的隱藏容器
focus-order-semantics	實際 Tab 鍵順序是否與頁面的視覺和邏輯順序一致	手動
scrollable-region-focusable	鍵盤無法到達或操作的可滾動區域	手動

這裡的模式與其他每個值得坦率討論的修復類別一致。tabindex 的正值是明確的，沒有任何正當理由使用它，所以 axe-core 每次發現都會完全有把握地重寫它。整個頁面的 Tab 鍵順序在邏輯上是否合理，則是關於那個具體頁面想要表達甚麼的判斷，需要一個能看著頁面並做出決定的人。

Axeazy 在這裡修復甚麼

Axeazy 會完全有把握地自動修復 tabindex 的正值，把它重寫為 0，讓瀏覽器的自然順序接管。它還會自動修復範圍更窄的「隱藏但可獲得焦點」的情形，即一個在隱藏時不應被到達的獨立元素。兩者都是真實、可用的自動修復。

關於順序是否真正合理，或自定義小元件是否內建了真正的鍵盤支援，都需要開發人員親自檢視頁面。這不是 Axeazy 在隱瞞的缺口，而是這份清單中每個修復類別最終都會劃出的同一條誠實界線：指令碼可以有把握地重寫一個屬性，但無法決定頁面內容在邏輯上應該按甚麼順序閱讀。

修復路徑也取決於您的平臺。在連線 GitHub 的 React、Next.js 或其他程式碼庫上，tabindex 修復會以真實的 pull request 送達。在 Shopify 上，掃描仍然會發現它，但沒有自動的程式碼更改，它會成為引導式清單中的一項。在 WordPress 上，這一特定類別不屬於免費外掛的三項即時修復（跳過導航、語言屬性、替代文字後備），因此目前在 WordPress 上也沒有自動路徑。檢視完整的修復類別說明。

常見問題

Tab 鍵順序混亂與鍵盤陷阱有甚麼區別？

Tab 鍵順序是有人按 Tab 時焦點移動的先後次序。鍵盤陷阱更嚴重：焦點卡在一個元素上，Tab 和 Shift+Tab 都無法讓它離開。順序混亂是可用性問題。陷阱則是硬性阻斷，而且它本身就是一條獨立的 WCAG 要求，即 2.1.2「無鍵盤陷阱」。

新增 tabindex="0" 能解決一切嗎？

它能讓原本無法獲得焦點的元素（比如樣式做成按鈕的 <div>）可以透過 Tab 到達，並把它放進頁面的自然文件順序中。它並不保證那個順序合乎邏輯。元素在實際 HTML 中所處的位置，仍然決定它何時獲得焦點。

如果正的 tabindex 會引起問題，開發人員為甚麼還會使用？

通常是出於好意，想在不重新排列實際 HTML 的情況下強制特定順序。短期內往往更省事，之後卻更費事，因為之後每新增一個元素都需要手動重新編號，才能避免再次破壞順序。

我可以在手機上用同樣的方法測試 Tab 鍵順序嗎？

不太行。Tab 鍵導航是硬體鍵盤的互動，所以這項測試是圍繞桌面瀏覽器設計的。移動端的鍵盤無障礙仍然重要，主要針對在移動瀏覽器上使用外接鍵盤或開關控制裝置的人，但測試方式不同。

只修復 Tab 鍵順序就能讓我的鍵盤導航完全可用嗎？

沒有任何單一修復能涵蓋只用鍵盤的使用者可能遇到的一切。Tab 鍵順序是真實而有意義的一部分；頁面仍可能存在其他問題，比如缺少焦點指示器或真正的鍵盤陷阱，需要各自單獨檢查。

參考來源

• W3C：理解成功準則 2.1.1，鍵盤
• W3C：理解成功準則 2.4.3，焦點順序
• W3C：理解成功準則 2.1.2，無鍵盤陷阱