顧客只用鍵盤，能否完成彈出對話框的操作？

先判斷是否真的需要模態對話框

模態對話框會暫時中斷原頁，並令後方內容不能操作。若顧客必須先作一個簡短決定，例如確認重要動作或選擇一項設定，這個形式可以合適；若流程包含多頁申請、大量說明，或需要經常對照後方內容，使用一般頁面或頁內區塊通常更易閱讀與導航。W3C 的 ARIA 實作指引把模態對話框描述為開啟期間令背景失去互動能力的視窗。如果顧客要先查看被遮住的日期、價格或政策才能回答，介面選型可能已有問題。工作範圍應小到可以完成或取消，而且不會失去原來脈絡。

設計遮罩外觀前，先寫明啟動按鈕、對話框內的決定，以及不同結果後焦點應去哪裏。預約流程可由「檢查預約」按鈕開啟簡短確認框，顧客核對時段後，可返回修改或正式確認。若控制項是執行動作，觸發器應用真正的按鈕；關閉或取消動作亦要容易找到。不要只因焦點移到某個控制項便突然彈出視窗，鍵盤使用者需要能順暢瀏覽頁面。模態視窗、提示文字、選單及非模態側欄，各有不同鍵盤預期。先釐清用途，後續便較少需要用程式補救焦點問題。

開啟時把焦點放在有用位置

開啟對話框時，焦點必須移入其中。W3C 並沒有規定每種情況都應先聚焦第一個按鈕。簡短問題可以由最常用的下一步開始；若視窗含標題、說明段落或清單，先聚焦頂部的靜態標題，可能更方便讀屏軟件使用者了解結構，然後再移到控制項。指引在此情況建議為靜態元素設置 `tabindex=-1`，讓程式可把焦點移過去，但不會令它成為一般 Tab 停靠點。若決定會刪除資料或提交難以撤回的交易，亦應考慮先聚焦破壞性較低的選項。起點要連同真實文字和畫面捲動位置一起測試，不應只接受元件的預設行為。

視力正常但只用鍵盤的顧客，一開啟便應看到焦點所在。以一般縮放及放大文字設定檢查：目前元素應在畫面內，外框亦不能與變暗背景混成一片。對話框要有說明動作的可見標題，避免只寫籠統的「提示」。W3C 指引要求提供可讀取的名稱，通常連到可見標題；只有程式真的禁止與背景互動時，才可使用 `aria-modal=true`。若遮罩仍容許點擊後方內容或讓焦點走到後方，單靠 ARIA 屬性會誤導輔助技術使用者。語意標籤、視覺狀態和實際操作應一致。

讓視窗內的鍵盤路徑完整可預期

模態視窗開啟時，Tab 應在視窗內的可聚焦元素間向前移動，Shift 加 Tab 向後移動；到了末端，要回到視窗內第一個可聚焦元素，而不是落到背後頁面。W3C 模式亦以 Escape 關閉視窗。所有完成操作所需的控制項，包括求助連結及可見的關閉或取消按鈕，都應放在對話框容器內。可見的關閉控制很重要，並非每人都知道或容易使用 Escape。順序應跟任務一致：標題或說明、需要填寫的資料、再到清楚選項。只能用滑鼠的日曆、看不見的關閉圖示、或被排除在焦點循環外的按鈕，都可能令顧客卡住。

所謂「限制焦點」不等於攔截所有按鍵。視窗內控制項的方向鍵、空白鍵和 Enter，仍要按各自正常方式運作。若對話框有表格，欄位標籤、填寫說明及錯誤訊息應與欄位連結；發生錯誤時，不應無聲地關閉視窗並清掉已填內容。若內容超過畫面，使用者要能捲動閱讀，同時仍找得到操作按鈕。較長視窗先聚焦靜態標題，可避免開首解釋被跳過。如果需要多層捲動區或不斷彈出下一個視窗才可完成工作，就應重新考慮是否使用模態視窗。結構越簡單，越容易跨瀏覽器和輔助技術測試。

關閉後把焦點送回合理位置

關閉視窗後，W3C 模式一般把焦點送回啟動它的元素，讓鍵盤使用者從原處繼續。例外亦有合理情況：觸發按鈕已被移除，或完成任務後新建立的項目才是下一個自然位置。這些例外要事先定義。顧客取消預約檢查時，焦點通常應回到「檢查預約」，方便修改附近欄位。若已確認預約，原按鈕因流程完成而消失，焦點可移到新確認標題或下一步。不要讓焦點掉回文件主體，迫使用戶由頁首重新尋找。Escape 和每個可見按鈕關閉後的去向，都要分別檢查。

驗收可由觸發按鈕開始，全程只用鍵盤：以 Enter 或空白鍵開啟，記錄最先聚焦的元素及標題有否被讀出；順逆方向走遍所有操作；確認背景控制項不能取得焦點；用 Escape 關閉；再開一次，完成正向動作。表格出錯後、流動裝置寬度配接駁鍵盤時也要重做。讀屏軟件測試應核對標題和簡短說明可讀，而較長的結構化內容沒有被壓成一整句難以理解的文字。應記錄實際焦點路徑，不只寫「無障礙通過」。W3C 的 HTML dialog 技術可借助瀏覽器處理不少模態行為，但產品仍須測試自身內容和結果流程。

若網站有兩種語言，兩個版本都要測。翻譯後的標籤可能較長、需要換行，在窄畫面把關閉控制推走，或遮住已聚焦按鈕。對話框名稱和指示應隨所選語言提供；若語言標記錯誤，讀屏軟件不應以不相稱的英語聲線讀出中文決定。即使畫面排版改變，焦點次序仍須符合相同任務邏輯。英文版通過不代表中文版必定可用；換行可能改變捲動位置，用字差異亦可能令高風險動作不夠清楚。測試應使用真實長度文字，不要只放一兩個字作佔位。

還要檢查對話框開啟期間發生其他事件的情況。工作階段提示、網絡失敗或欄位驗證結果，可能在第一個視窗尚未關閉時出現。除非已特別設計和測試，否則避免把多層模態視窗疊在一起。若錯誤屬於目前任務，就在現有視窗內說明並保留已輸入資料。若成功後會跳到新頁，應在新頁設合理起點，讓使用者知道動作已完成。這些轉換最容易令焦點消失，驗收腳本不能只有開啟、Tab、Escape 的順利路徑。

最後的檢查應是一段實際操作旅程。請測試員在每個動作後指出焦點位置、讀屏軟件讀了甚麼，以及只用鍵盤的顧客遇上取消或錯誤後，能否不用重頭開始便繼續。記錄實際瀏覽器及輔助技術，因為細節可能有差異。W3C 模式提供可靠框架，但初始焦點、文案和返回位置仍要按產品任務選擇。寫下一張簡短焦點路徑圖，日後維護者更改表格或替換元件時，就有清楚目標。

把原則用於預約確認

服務企業的預約檢查視窗，可用簡短、有標籤的欄目列出服務、地點和時間。標題寫「確認這次預約」，讓顧客明白決定內容。「修改資料」按鈕關閉視窗後，把焦點帶回相關欄位；「確認預約」送出一次，成功後把焦點帶到結果頁的確認訊息。若提交失敗，保留視窗及原有選擇，清楚說明問題，讓顧客決定下一步。企業不能只靠模態視窗保障交易：伺服器仍須驗證時段是否可用，並防止重複處理。對話框的責任是清楚且可操作地呈現決定，不是取代背後的預約控制。