发布与验证
让 AI 写弹窗回归测试：关闭后焦点去哪
把打开、操作、关闭看成同一条键盘路径。
资料核验2026.11.12 · W3C WAI · 网页可访问性
点「删除草稿」打开弹窗，Esc 关闭后再按 Tab，焦点却跑到页头。用鼠标很难留意，纯键盘操作时会丢掉刚才所在的位置。
交给编码助手的任务
交给助手删除草稿弹窗的两个路径。取消后触发按钮还在，确认后那条草稿会消失。要求它先给出初始焦点、Tab 约束和关闭落点，再补代码与键盘测试。
先约定打开和关闭的落点
模态打开时，按内容选择合适的初始焦点。对难撤销的操作，考虑先落在取消按钮。Tab 应留在模态内，Esc 能关闭。关闭后通常返回触发按钮。
如果触发按钮所在的草稿已经删除，选择一个逻辑上相邻的元素，比如下一条记录或列表标题附近的操作。测试时分别走取消和确认两条路径。
不要只验弹窗是否消失。最后再按一次 Tab，确认用户真的知道下一步可以去哪里。
先准备一个对照样例
从列表第二条打开删除弹窗。先 Esc 关闭并验证回到第二条按钮，然后重新打开并确认删除。此时原按钮消失，应将焦点移到合理的相邻操作。再次 Tab 确认顺序可以继续。
用这些结果验收
- 打开时焦点在适合的控件。
- Tab 可在弹窗内循环。
- Esc 取消后返回触发按钮。
- 确认删除后焦点移到逻辑相邻的元素。
审查时容易漏掉什么
只测弹窗的可见性抓不到键盘断点。请在每次关闭后再按一次 Tab，检查实际焦点顺序。弹窗内部和关闭后都要能看见焦点。
打开弹窗时，默认焦点未必总要落到第一个按钮。对难撤销的删除，初始焦点放在取消一侧有实际价值。让助手走一遍键盘流程，并确认关闭后目标在视口内，别把焦点交给已经被移除的 DOM。
