想像一家美國維修公司的員工用 AI 起草客戶回信，點選“檢查草稿”後開啟一個模態對話方塊：必須先關閉它，才能操作背後頁面。現在只用鍵盤走一次完整流程。文字再準確，如果員工進不去、改不了或退不出審核視窗，這個助手仍不能供他們獨立使用。這是虛構評審場景，不是客戶測試結果。

W3C 的模態對話方塊模式要求開啟後把焦點移入框內，但不等於一律放在第一個按鈕。 長篇草稿可先聚焦頂部標題或靜態內容，讓使用者從開頭理解材料。我們的建議是清楚顯示“檢查回信草稿”，把傳送與編輯區分開；不要讓首次按鍵輕易觸發對外傳送。

按 Tab 應在框內依次移動，到末項後回到首項；Shift+Tab 反向移動。 在測試記錄裡逐個寫下實際停靠的控制項，檢查修改、取消和確認是否都能找到。模態對話方塊背後的頁面應不可互動，不能只蓋上一層灰色。若只是並排閱讀的非模態面板，不應照搬這種焦點循環。

W3C 模式提供 Escape 關閉，並建議保留可見的關閉或取消按鈕；關閉後通常把焦點還給開啟視窗的控制項，若該控制項消失或下一步流程需要，可選擇合理位置。 對回信工具，我們建議關閉審核並不等於傳送，未儲存修改應按明確規則處理，避免員工回來時找不到草稿或誤以為已經寄出。

驗收記錄應寫出瀏覽器、輔助技術、實際焦點順序，以及開啟、編輯、退出、返回的結果。W3C 的鍵盤準則要求功能可透過鍵盤介面操作，並規定輸入依賴移動路徑時的例外。 本文的回信審核不依賴自由手繪。本文只提出測試路線，未執行應用程式測試，也不構成合規認證；應讓實際使用鍵盤和輔助技術的人參與驗收。