想象一家美国维修公司的员工用 AI 起草客户回信，点击“检查草稿”后打开一个模态对话框：必须先关闭它，才能操作背后页面。现在只用键盘走一次完整流程。文字再准确，如果员工进不去、改不了或退不出审核窗口，这个助手仍不能供他们独立使用。这是虚构评审场景，不是客户测试结果。

W3C 的模态对话框模式要求打开后把焦点移入框内，但不等于一律放在第一个按钮。 长篇草稿可先聚焦顶部标题或静态内容，让用户从开头理解材料。我们的建议是清楚显示“检查回信草稿”，把发送与编辑区分开；不要让首次按键轻易触发对外发送。

按 Tab 应在框内依次移动，到末项后回到首项；Shift+Tab 反向移动。 在测试记录里逐个写下实际停靠的控件，检查修改、取消和确认是否都能找到。模态框背后的页面应不可交互，不能只盖上一层灰色。若只是并排阅读的非模态面板，不应照搬这种焦点圈。

W3C 模式提供 Escape 关闭，并建议保留可见的关闭或取消按钮；关闭后通常把焦点还给打开窗口的控件，若该控件消失或下一步流程需要，可选择合理位置。 对回信工具，我们建议关闭审核并不等于发送，未保存修改应按明确规则处理，避免员工回来时找不到草稿或误以为已经寄出。

验收记录应写出浏览器、辅助技术、实际焦点顺序，以及打开、编辑、退出、返回的结果。W3C 的键盘准则要求功能可通过键盘接口操作，并规定路径依赖输入的例外。 本文的回信审核不依赖自由手绘。本文只提出测试路线，未运行应用测试，也不构成合规认证；应让实际使用键盘和辅助技术的人参与验收。