軟體無障礙設計：為什麼鍵盤操作
除了 WCAG，國際上還有幾套常被引用或作為法規依據的標準，包括歐盟的 EN 301 549、美國康復法案第 508 條（Section 508），以及我國的政府網站無障礙開發規範。這些文件在細節上略有差異，但對「鍵盤可操作」的要求幾乎是完全一致的——它是所有無障礙規範的交集，也是各家標準的公約數。
1-2 誰真正需要鍵盤操作？被嚴重低估的使用者輪廓
談完標準，我們來看人。實務上，「純鍵盤使用者」的輪廓比一般人想像的寬得多，而且往往與你我重疊。大致可以分成以下幾類：
把這些族群加總起來，你會發現「純鍵盤使用者」根本不是一個邊緣小眾，而是一個橫跨年齡、職業與健康狀態的龐大集合。這也解釋了為什麼國際標準會把鍵盤可及性放在 A 級——因為它服務的對象，其實就是「所有人某個時刻的樣子」。
二、為什麼鍵盤比滑鼠更「可靠」：從技術層面拆解
理解了使用者輪廓，接下來要談的是技術。很多人以為鍵盤支援只是「多設幾組快捷鍵」，但真正的鍵盤可及性是一整套系統工程，涉及焦點管理、事件處理、語意結構與輔助技術的協作。以下幾個環節，是我們在評測時必定檢查的重點。
2-1 焦點順序、焦點可見性與鍵盤陷阱
鍵盤操作的基礎是「焦點」（focus）。畫面上任何一個可互動的元件，只要能被 Tab 鍵選中，就代表它取得了焦點；使用者按下 Enter 或空白鍵，就能觸發它。這套機制看似簡單，但要讓它運作順暢，至少得滿足三個條件。
第一是順序合理。瀏覽器預設的焦點順序，基本上跟隨 DOM（文件物件模型）的排列順序。問題在於，許多團隊為了視覺排版，用 CSS 把元素在畫面上重新排列，導致「看起來的順序」與「Tab 的順序」完全不同。使用者按著 Tab 鍵，焦點會先跳到頁尾，再跳回中間，最後跑到右上角——這種體驗對仰賴螢幕閱讀器的人來說是災難性的，因為他們必須在腦中重建一份與視覺完全脫節的地圖。比較好的做法，是讓 DOM 順序與視覺順序保持一致，必要時用 CSS Grid 或 Flexbox 重新排版，而不是改動 DOM 結構。
另一個常見的錯誤，是使用正數的 tabindex（例如 tabindex="1"、tabindex="5"）。這種寫法會強制把元素拉到焦點序列的最前面，並且依數字大小排序，一旦頁面上的正數 tabindex 變多，整個順序就會變得難以維護、也難以預測。業界普遍的做法是：只用 tabindex="0" 讓元素進入自然序列，用 tabindex="-1" 讓元素可被程式聚焦但不進入 Tab 序列，其餘一律交給 DOM 順序決定。
第二是焦點可見。這一條在實務上是翻車頻率最高的。不少設計師覺得瀏覽器預設的藍色外框「很醜」，於是在 CSS 裡寫下 outline: none 或 outline: 0，把焦點樣式一刀砍掉。結果就是：視覺正常的滑鼠使用者完全不受影響，但鍵盤使用者在畫面上「迷路」了——他們不知道焦點現在在哪裡，也就無從操作。正確的做法不是移除焦點樣式，而是重新設計一套符合品牌視覺、但足夠醒目的焦點指示，並使用 :focus-visible 讓它只在鍵盤操作時出現，兼顧美觀與可及性。
第三是不要製造鍵盤陷阱。最典型的場景是彈出式視窗（modal）：開啟之後，焦點應該被限制在視窗內部循環，避免使用者 Tab 到背景內容；但必須同時提供明確的關閉方式（通常是 Esc 鍵或一個可聚焦的關閉按鈕），讓使用者能順利離開。如果開發者只做了「鎖定焦點」卻忘了「放行」，使用者就會被困在視窗裡，只能重新整理頁面。同樣的問題也常發生在嵌入的第三方元件上，例如影片播放器、地圖、客服聊天外掛、驗證碼元件等——這些元件的鍵盤行為往往不受主要團隊控制，因此更需要在上線前實測。
2-2 螢幕閱讀器與鍵盤的共生關係，以及自製元件的陷阱
很多人沒有意識到，螢幕閱讀器本身的操作完全是鍵盤驅動的。以 Windows 上最普及的 NVDA 為例，使用者必須用組合鍵在「瀏覽模式」與「焦點模式」之間切換，用方向鍵逐字、逐行、逐標題地瀏覽內容，用特定按鍵跳轉到表單欄位、地標區域或清單。這意味著，一款軟體如果沒有正確的語意標記，螢幕閱讀器就讀不出結構，使用者只能一格一格地盲目摸索，效率極低。
更麻煩的是「自製元件」的問題。原生 HTML 的 <button>、<input>、<select> 天生就具備完整的鍵盤行為與語意，但許多團隊為了視覺一致性，會用 <div> 或 <span> 搭配 CSS 與 JavaScript 重造按鈕、下拉選單、開關、分頁、日期選擇器。這些自製元件如果沒有補上對應的 role 屬性、tabindex、鍵盤事件處理與 ARIA 狀態（例如 aria-expanded、aria-selected、aria-checked），下場就是「滑鼠能用、鍵盤完全失效、螢幕閱讀器唸不出來」。
我們在評測時，會特別檢查以下幾種自製元件的鍵盤行為：
開關與勾選框：空白鍵能否切換？狀態改變是否有被朗讀？
日期選擇器：能否完全不用滑鼠選擇日期？是否有純文字輸入的替代方案？
拖曳排序：是否提供「上移／下移」按鈕或鍵盤快捷鍵作為替代？
還有一個容易被忽略的細節，是「單字元快捷鍵」與輔助技術的衝突。假設某款筆記軟體用 e 鍵代表「封存」、n 鍵代表「新筆記」，這對熟悉快捷鍵的人是福音，但對螢幕閱讀器使用者可能是災難——因為 NVDA 在瀏覽模式下，字母鍵常用於快速導覽（例如 h 跳到標題、k 跳到連結），兩套快捷鍵會正面撞車。WCAG 的 2.1.4 就是為此而設：開發者必須提供關閉快捷鍵的選項，或把快捷鍵限定在特定元件取得焦點時才生效。我們在評測中會實際測試「有沒有關閉快捷鍵的設定」，這一項經常是零分。
三、實測方法：我們如何評測一款軟體的鍵盤可及性
談完原理，回到評測本身。很多讀者會問：無障礙這種東西，不是要請專業顧問才能驗嗎？其實不然。只要掌握方法，一般使用者也能在十五分鐘內，對一款軟體的鍵盤可及性做出相當可靠的判斷。以下是我們在編輯部內部使用的流程。
3-1 測試清單與評分表
我們的核心原則是「只用鍵盤完成核心任務」。具體做法是：把滑鼠移到一旁（或直接拔掉），只用 Tab、Shift+Tab、Enter、空白鍵、方向鍵、Esc 這幾顆鍵，嘗試完成該軟體最典型的三到五個任務，例如「登入並修改個人資料」、「建立一筆新資料並儲存」、「在清單中找到特定項目並刪除」、「播放一段影片並調整音量」。過程中記錄以下項目：
評測項目
觀察重點
通過標準
核心任務可完成率
只用鍵盤能否走完主要流程
核心任務 100% 可完成，不需中途改用滑鼠
焦點可見性
每個可聚焦元件是否都有清楚的視覺指示
所有元件皆有可見焦點樣式，且對比足夠
焦點順序
Tab 順序是否與視覺順序一致
順序合理、可預期，無跳躍或重複
鍵盤陷阱
焦點是否會被困在某個區塊內
任何元件皆可正常進入與離開
對話框與浮層
開啟後焦點是否移入、關閉後是否歸位
Esc 可關閉，焦點回到觸發按鈕
自製元件
下拉、分頁、開關、日期選擇器是否支援鍵盤
符合 ARIA 作者實務規範的鍵盤互動模式
快捷鍵設計
單字元快捷鍵是否可關閉或重映射
提供設定選項，或限定焦點範圍
拖曳替代方案
拖放、滑動手勢是否有非拖曳的操作路徑
提供按鈕、選單或鍵盤指令替代
縮放與焦點遮蔽
頁面放大至 400% 時，焦點是否被固定元素遮住
取得焦點的元件仍完整可見
輔助技術相容性
搭配螢幕閱讀器時，元件是否被正確朗讀
名稱、角色、狀態皆正確播報
除了上述清單，我們還會做兩個「壓力測試」。第一個是縮放測試：把瀏覽器縮放拉到 400%，模擬低視力使用者的情境，然後只用鍵盤操作。這個測試非常容易抓出「焦點被固定在頂端的導覽列遮住」的問題，因為在放大狀態下，固定元素的相對面積會大幅增加。第二個是螢幕閱讀器測試：安裝免費的 NVDA（Windows）或直接使用 macOS 內建的 VoiceOver，關閉螢幕，嘗試完成同一組任務。這個測試不需要專業訓練，任何人都能在半小時內感受到「這款軟體到底有沒有把結構做對」。
3-2 常見的失敗案例類型：從評測現場帶回來的觀察
累積數十款軟體的評測經驗後，我們發現鍵盤可及性的問題有很明顯的模式，而且高度集中在幾種寫法上。以下是最常見的六種「翻車類型」，你可以拿這份清單去對照自己手上的工具。
第一種：焦點樣式被移除。 這是最經典、也最不該出現的錯誤。只要在樣式表裡搜尋 outline: none，往往就能抓到一堆問題。這種寫法的出發點通常是「美觀」，但代價是讓所有鍵盤使用者失去方向感。值得注意的是，這個問題在近幾年因為設計系統的重視而有所改善，但仍有不少中小型產品沒有處理。
第二種：用 div 假裝按鈕。 畫面上看起來是按鈕，但實際上是 <div onclick="...">。這種元素沒有預設的焦點行為、沒有 Enter 與空白鍵的觸發、也沒有角色語意，對螢幕閱讀器來說它只是一段普通文字。修正方式其實很簡單：能換成原生 <button> 就換，真的不能換才補上 role="button"、tabindex="0" 與鍵盤事件處理。
第三種：只靠 hover 觸發的選單。 滑鼠移過去才展開的下拉選單，在鍵盤上完全無法觸及。正確做法是讓選單同時支援 hover、點擊與鍵盤（Enter 展開、方向鍵移動、Esc 關閉），並且在失去焦點時自動收合。
第四種：對話框的焦點管理缺失。 開啟 modal 之後，焦點仍留在背景頁面，使用者按 Tab 會跑到背後的內容上；或者關閉 modal 之後，焦點掉回頁面頂端，使用者必須重新走一次。這兩種情況都會讓流程變得不連續。理想行為是：開啟時把焦點送到對話框內的第一個可聚焦元素，關閉時送回原本觸發它的按鈕。
第五種：拖放與手勢沒有替代方案。 檔案上傳要靠拖曳、看板排序要靠拖曳、圖片裁切要靠拖曳，這些操作對鍵盤使用者來說都是死路。WCAG 2.2 新增的 2.5.7 就是針對這件事，要求開發者提供點擊式的替代操作。實務上最常見的解法，是在拖曳項目上加上「上移」「下移」按鈕或對應的鍵盤快捷鍵。
第六種：快捷鍵與瀏覽器、輔助技術打架。 有些軟體會攔截 Ctrl+W、Ctrl+T 這類瀏覽器原生快捷鍵，或者用大量的單字元快捷鍵覆蓋掉螢幕閱讀器的導覽指令。這類問題在評測時特別明顯，因為受測者會突然發現「按了某個鍵之後瀏覽器分頁關掉了」。
四、評測觀察：不同類型軟體的鍵盤支援現況
接下來這一段，是我們把評測經驗按軟體類型整理出的觀察。必須先聲明：以下描述是「類型層級」的趨勢，不代表所有產品都如此，而且軟體版本更新頻繁，實際狀況請以你手上的版本為準。
4-1 作業系統與辦公軟體：鍵盤支援的傳統強項
如果要比鍵盤支援的成熟度，作業系統與文書處理軟體大概是資優生。Windows 與 macOS 都內建了完整的鍵盤導覽機制，前者有焦點提示、放大鏡與螢幕朗讀，後者有全鍵盤控制（Full Keyboard Access）模式，可以讓使用者完全不用滑鼠操作整個系統。這套機制的歷史可以追溯到數十年前，也因此相對穩定。
辦公軟體方面，試算表大概是鍵盤操作的典範：Excel 的儲存格導覽、範圍選取、快速跳轉、公式輸入，幾乎全部都能用鍵盤完成，資深使用者甚至會覺得用鍵盤比用滑鼠快得多。文件編輯軟體也類似，格式化、樣式套用、尋找取代、大綱導覽都有對應快捷鍵。
不過，這些老牌軟體的鍵盤支援並非毫無死角。隨著功能不斷堆疊，愈來愈多新功能（特別是雲端協作、即時通訊、AI 面板、側邊欄）是以網頁技術打造的，這些部分的鍵盤可及性往往與本體有明顯落差。我們曾測到某套辦公軟體的主編輯區鍵盤支援完美，但內建的「評論面板」完全無法用鍵盤操作——使用者可以編輯文件，卻無法回覆同事的留言。
另一個值得注意的趨勢，是新一代的協作型筆記與專案管理工具。這類產品多半以網頁應用為主，鍵盤支援的落差極大。有些團隊把「鍵盤優先」當成核心設計理念，提供了完整的指令面板、快速切換、區塊導覽，甚至連拖曳排序都能用鍵盤完成；但也有不少產品在鍵盤導覽上明顯不足，選單展開後焦點會亂跳，或者根本無法用鍵盤建立新項目。
4-2 網頁應用與設計工具：最容易失守的戰場
網頁應用是鍵盤可及性問題最密集的地方，原因很現實：網頁應用的開發速度快、元件庫選擇多、視覺需求導向強，而鍵盤可及性需要設計與工程兩邊同時配合，很容易在時程壓力下被跳過。
我們在評測這類產品時，最常遇到的狀況是「核心功能可用、周邊功能崩壞」。例如：一個線上表單工具，填寫欄位沒問題，但表單欄位的「拖曳排序」完全無法用鍵盤進行；一個專案管理看板，卡片可以開啟，但無法把卡片移到另一個欄位；一個設計工具，圖層列表可以用 Tab 進入，但進入之後焦點被困住，只能重新整理頁面。
設計工具特別值得單獨討論，因為它們的操作模型本來就高度依賴滑鼠：拖曳畫布、框選、對齊、縮放。這類產品近年來在無障礙上投入不少，開始提供完整的鍵盤快捷鍵、指令面板、圖層巡覽，甚至針對螢幕閱讀器使用者提供替代的屬性面板。但整體而言，設計工具仍是鍵盤可及性最不平均的一類，產品之間落差可以非常大。
另一個容易被忽略的，是「第三方嵌入元件」。許多產品本身做得不錯，但嵌入了外部的客服聊天、cookie 同意橫幅、影片播放器、金流表單，而這些元件往往沒有處理鍵盤焦點。結果就是使用者一路順暢地走到結帳頁，卻在最後一步被一個無法關閉的彈窗困住。這也是我們在評測時會特別把「第三方元件」單獨列為檢查項目的原因。
4-3 影音、遊戲與行動應用：不同脈絡下的鍵盤思維
影音平台是鍵盤支援相對成熟的一類，這要歸功於早期使用者自發的快捷鍵文化。播放／暫停、前後快轉、音量調整、全螢幕、字幕切換，幾乎都有對應的單鍵操作，而且這些快捷鍵通常會被清楚列在說明頁面或快捷鍵面板裡。不過，影音平台的「周邊功能」——例如播放清單管理、留言、訂閱設定——鍵盤支援就明顯較弱，焦點順序也常出現跳躍。
遊戲的情況比較特殊。遊戲的鍵盤支援本質上與無障礙設計高度重疊，但關注點不太一樣：除了「能不能只用鍵盤玩」，還包括按鍵重映射、單手模式、字幕大小、顏色對比、減少動態效果、視覺提示的音效化等。近年來遊戲產業對可及性的投入明顯增加，不少大作會在上市時公布完整的可及性功能清單，這股風氣值得其他軟體類型借鏡。
行動應用的鍵盤支援，則是另一個常被忽略的領域。很多人以為手機沒有鍵盤，但實際上外接鍵盤在平板與手機上的使用率並不低，而且 iOS 與 Android 都提供了完整的鍵盤導覽機制。此外，行動裝置上的「全鍵盤控制」「切換控制」與「語音控制」等輔助功能，本質上都需要應用程式正確標示元件的名稱與角色。我們在評測行動應用時，會特別測試「接上藍牙鍵盤後，能否完成核心任務」，這一項的通過率至今仍偏低。
五、從評測到改善：開發團隊可以落地的鍵盤可及性清單
如果你讀到這裡，心裡想的是「我們家產品好像也有這些問題」，那接下來這段就是為你準備的。改善鍵盤可及性不需要一次到位，但需要把它從「有空再做」變成「流程的一部分」。以下按照階段整理。
5-1 設計階段：把鍵盤思維放進設計稿
鍵盤問題有一大半是在設計階段埋下的，因為工程師往往只是忠實實作設計稿。因此，最有效的改善起點是設計：
:focus-visible 的樣式當成設計系統的一部分，明確規範顏色、粗細、外框偏移，而不是留給瀏覽器預設值。5-2 開發與驗收階段：把檢查變成日常
開發階段的原則可以用一句話總結：能用原生元素，就不要自己造。原生 <button>、<input>、<select>、<dialog> 已經幫你處理好大量鍵盤行為與語意，自己重造只會製造更多漏洞。真的必須自製時，請參考 ARIA 作者實務規範（WAI-ARIA Authoring Practices）提供的鍵盤互動模式，並逐一補上 role、tabindex、鍵盤事件與 ARIA 狀態。
幾個具體的實作要點：
:focus-visible 保留鍵盤焦點樣式，不要用 outline: none 全域移除。對話框開啟時把焦點移入，關閉時歸還給觸發元素，並支援 Esc 關閉。
避免使用正數 tabindex，讓 DOM 順序決定焦點順序。
為單字元快捷鍵提供開關，或限定在特定元件聚焦時才生效。
為拖放功能補上鍵盤替代操作。
為表格、圖表提供文字或表格形式的替代內容。
aria-live 區域播報動態更新的狀態（例如「已儲存」「載入中」），讓螢幕閱讀器使用者能得知非視覺的變化。驗收階段則要建立「只用鍵盤走一遍」的流程。這件事不需要額外工具，成本極低，卻能攔下大部分的嚴重問題。我們建議把它寫進 Pull Request 的檢查清單，或者至少在新功能上線前由 QA 執行一次。此外，自動化檢測工具（如 axe、Lighthouse、WAVE）可以協助抓出部分結構性問題，但必須理解它們的能力邊界——自動工具通常只能偵測約三到四成的無障礙問題，鍵盤操作流程、焦點順序、使用體驗這些項目，仍然必須靠人工實測。
最後一個建議，是把真實使用者納入測試。這裡說的不是找同事模擬，而是邀請實際使用螢幕閱讀器或輔助裝置的使用者參與測試。一次這樣的測試，往往比十份規範文件更能讓團隊理解問題的嚴重性。許多產品團隊在第一次看到螢幕閱讀器唸出自己的介面時，都會有非常直接的震撼——那種「原來我們的產品對某些人來說是這個樣子」的體認，是推動改變最有效的動力。
六、結語：鍵盤操作，是軟體品質的照妖鏡
回過頭來看，為什麼我們會在軟體評測裡，花這麼多篇幅談鍵盤？因為鍵盤可及性有一個很特別的性質：它幾乎無法造假。一款軟體可以買漂亮的介面、可以做流暢的動畫、可以寫很好的行銷文案，但如果它的焦點順序混亂、對話框把使用者困住、自製元件的鍵盤行為亂七八糟，那這些問題會在一次純鍵盤操作中全部現形。
換句話說，鍵盤操作是軟體品質的照妖鏡。它反映的不只是無障礙意識，更是整個團隊對細節的掌握程度：HTML 結構有沒有寫對、元件抽象有沒有做乾淨、狀態管理有沒有想清楚、測試流程有沒有涵蓋非視覺路徑。一個鍵盤可及性做得好產品，通常在其他工程品質指標上也不會太差；反過來說，鍵盤操作一塌糊塗的產品，往往也藏著其他看不見的技術債。
對一般使用者而言，這篇文章希望帶給你一套簡單的判斷方法：下次評估一款新工具時，不妨先把滑鼠放一邊，試著只用鍵盤走完一次核心流程。你會很快知道這款軟體有沒有把你當成一個「可能無法使用滑鼠的人」來設計。而對產品團隊而言，鍵盤可及性不是額外的慈善工作，而是把產品做得更扎實的一種方法——因為你為邊緣情境所做的努力，最終會回饋到所有使用者的日常體驗上。
輪椅坡道的故事告訴我們：當你為某群人把路鋪平，受惠的往往是推嬰兒車的人、拖行李箱的人、騎腳踏車的人。軟體的鍵盤支援也是一樣的道理。當你讓一款軟體可以只用鍵盤操作，受益的不只是視障者與肢體障礙者，還有手受傷的你、在搖晃車廂裡的你、以及單純想少動幾下滑鼠的你。
這條線，值得我們在每一次評測裡，認真地畫下去。
（本文為雅寶社區 · 頂客論壇軟體評測版專欄內容，歡迎在討論區分享你自己的鍵盤實測經驗，或推薦我們下一款應該受測的軟體。）
```