試想一間美國維修公司嘅員工，用 AI 草擬客戶回信，按「檢查草稿」之後開咗一個模態對話框：要先關閉佢，先可以操作後面嘅頁面。依家只用鍵盤行一次完整流程。文字再準確都好，如果員工入唔到、改唔到，或者退唔出審核視窗，佢哋仍然冇辦法獨立使用呢個助手。呢個係虛構審核情境，唔係客戶測試結果。

W3C 嘅模態對話框模式要求，開啟之後將焦點移入框內，但唔代表一律放喺第一個按鈕。 長篇草稿可以先聚焦頂部標題或者靜態內容，等用戶由開頭理解材料。我哋建議清楚顯示「檢查回信草稿」，分開傳送同編輯；唔好令第一次按鍵就輕易觸發對外傳送。

按 Tab 應該喺框內依次移動，到最後一項就返去第一項；Shift+Tab 就反方向移動。 喺測試記錄逐個寫低實際停靠嘅控制項，檢查修改、取消同確認係咪全部搵得到。模態對話框後面嘅頁面應該唔可以互動，唔係淨係蓋一層灰色就算。如果只係畀人並排閱讀嘅非模態面板，就唔應該照搬呢種焦點循環。

W3C 模式提供用 Escape 關閉，亦建議保留睇得到嘅關閉或者取消按鈕；關閉之後，通常將焦點交返畀開啟視窗嗰個控制項。如果嗰個控制項已經消失，或者下一步流程有需要，可以揀另一個合理位置。 對回信工具，我哋建議關閉審核唔等於傳送；未儲存嘅修改要按清楚規則處理，避免員工返嚟嗰陣搵唔返草稿，或者誤以為已經寄出。

驗收記錄應該寫明瀏覽器、輔助技術、實際焦點次序，同開啟、編輯、退出、返回嘅結果。W3C 嘅鍵盤準則要求，功能可以經鍵盤介面操作，亦訂明輸入依賴移動路徑時嘅例外。 本文嘅回信審核唔依賴自由手繪。本文只係提出測試路線，冇執行應用程式測試，亦唔構成合規認證；驗收應該有真正使用鍵盤同輔助技術嘅人參與。