工具列把「預覽」移到最前面，Tab卻先停在第二個位置的「儲存」。CSS的order改變了視覺排列，沒有一起改掉DOM順序。滑鼠使用者看到的新位置，與鍵盤依序走到的位置可能因此不同。
order適合處理某些視覺排列需求，但包含表單與按鈕的區塊，要先想清楚合理的閱讀與操作順序。若只是用CSS把重要按鈕往前搬，再用一串正數tabindex追回畫面，維護成本往往會更高。
先看同一份按鈕的兩種順序
以下工具列的DOM順序是儲存、預覽、分享。CSS把預覽的order設成負數，使它在橫向flex排列中出現在最左邊。三個按鈕仍然都是原生button，沒有額外tabindex。
<div class="actions">
<button id="save" type="button">儲存</button>
<button id="preview" type="button">預覽</button>
<button id="share" type="button">分享</button>
</div>.actions {
display: flex;
gap: 12px;
}
#preview {
order: -1;
}本機Chromium案例讀取按鈕位置，畫面由左至右是預覽、儲存、分享；從頁面起點連按Tab，焦點卻依序是儲存、預覽、分享。order控制flex項目的視覺排序，沒有重排原始HTML，也不能當成改變正常鍵盤巡覽順序的方法。
此例沒有其他焦點控制。實際頁面若加入tabindex、隱藏控制項、正反方向排列或程式化focus，結果還會受到那些因素影響。先縮小到三個原生按鈕，就能確認是哪一層造成差別，避免同時改很多設定卻看不出原因。
視覺次序不一定要求完全相同，但不能讓操作難懂
焦點順序應保留意義與可操作性。若是沒有先後關係的裝飾卡片，某些視覺調整未必讓理解出問題；如果是填寫姓名、選方案、確認後送出的流程，焦點突然從下方跳回上方，就可能讓人難以追蹤。評估的是實際流程，不是只看CSS有沒有order。
閱讀順序同樣值得確認。DOM通常是輔助技術取得內容順序的重要來源；把說明文字在視覺上移到欄位前面，卻仍放在DOM的很後面，可能使使用者先遇到控制項才看到必要說明。不能只用一張桌面截圖確認排列，還應讀原始結構與實際焦點路線。
例如你希望使用者先預覽，再決定儲存，可以讓HTML一開始就採這個合理順序，再用樣式安排間距與尺寸。不要用order偷偷建立產品流程，而DOM仍是舊流程。若三個動作本來沒有先後，則也要確認視覺位置不會暗示一套相反的操作順序。
優先讓DOM承載穩定的閱讀與操作邏輯
修正範例最直接的方法，是把預覽按鈕放到DOM第一個位置，再移除它的order覆寫。這樣畫面與普通Tab順序都沿著同一份結構。修改前要確認事件綁定、測試與程式選取沒有依賴「第幾個子元素」，避免只調順序就把動作接錯。
<div class="actions">
<button id="preview" type="button">預覽</button>
<button id="save" type="button">儲存</button>
<button id="share" type="button">分享</button>
</div>元件框架裡也應從實際輸出的DOM檢查，不要只看資料陣列。排序後的資料、條件顯示和不同版面元件都可能影響最後結構。若你同時輸出桌面與手機兩套工具列，再用CSS隱藏其中一套，要確認隱藏的那套不留在Tab路徑，也不要保留重複ID。
另外，order只影響作為flex或grid項目的元素。若你把它設在深一層的按鈕，真正的flex項目卻是外面的容器，它不會改變外層項目次序。先查看容器的display與直接子項目，再調整排序；否則可能以為order沒有生效，繼續增加錯誤的選擇器。
不要用正數tabindex補一套獨立排序
把預覽設成tabindex=1、儲存設成2、分享設成3，看似能追上畫面，卻建立了另一套焦點優先次序。正數tabindex的元素會先於普通順序的其他控制項進入巡覽，可能讓這排工具列突然跑到頁首搜尋或導覽之前。局部順序修好了，全頁反而更難理解。
tabindex=0可以讓適合互動的非原生元素進入正常順序，但它不會按視覺位置自動排序；原生button本來就可取得焦點。tabindex=-1則通常退出依序Tab巡覽，仍可被程式focus。不要把其中一個按鈕設成-1來掩蓋跳動，結果讓鍵盤使用者根本到不了那個動作。
自訂複合元件可能有自己管理焦點的模式，例如工具列採方向鍵移動，那需要完整實作相應的元件規則。本文處理的是普通一排按鈕，沒有建立這種模式。不要只取一個tabindex技巧，就把其他鍵盤行為與狀態管理省略。
不同螢幕寬度要各走一次Tab
桌面工具列可能是一排，手機則換成多行或直排。如果只有手機media query加order，問題也可能只在窄螢幕出現。先在兩種寬度看按鈕位置，再實際按Tab與Shift+Tab，確認焦點路線仍能順著內容理解，而不是在不相鄰位置反覆跳動。
測試時保留明顯的focus樣式。若焦點框被移除，你可能看不到現在停在哪裡，錯把位置差異當成按鍵失效。也不要在每次Tab時自行把頁面捲到固定位置；先讓瀏覽器正常帶出焦點，再檢查固定頁首或浮動工具是否遮住控制項。
本機範例的修正版本將DOM改成預覽、儲存、分享，並移除order。位置與三次Tab都得到相同順序；原版本則保留兩種不同順序。這組比較只確認普通flex按鈕案例，實際網站還需核對全頁其他控制項與響應式規則。
讓版面調整不改掉使用者理解的流程
需要在手機把摘要移到圖片上方時，可以先檢查兩者是否有獨立意義，及DOM順序是否仍清楚。若段落是前後相依的步驟，就不適合只用CSS換位；如果是同一項目的兩種呈現資訊，則可以按內容關係評估。沒有一條適用所有版面的「永遠不能重排」規則，但重要流程需要有可理解的順序。
維護時可以把HTML讀成沒有樣式的內容，再把鍵盤焦點順序列出來，和視覺版面一起對照。優先整理結構與資訊關係，樣式負責尺寸與佈局，就比較少需要用tabindex或強制focus補救。改版面後也應重新檢查，避免原本合理的DOM在新排版下變得難以追蹤。
如果工具列是多人維護，可以把預期順序寫在元件文件，並保留這個小型鍵盤檢查。之後換圖示、加按鈕或調整斷點時，就有具體基準可比對。重點是操作之間的關係能被理解，不是要求每一排沒有先後關係的連結都採相同外觀。
評論0