让 AI 写确认弹窗，把 Tab、Esc 和焦点返回也验一遍

让 AI 写“清空草稿”的确认弹窗，只看成品图，很容易漏掉一件事：键盘刚打开弹窗，焦点到底落在哪？如果落在“确认清空”，连续两次 Enter 就可能直接把操作做完。

附件放了一份能直接打开的 HTML。目标很小：把“取消、确认、Esc、焦点返回”这条交互走通。里面只有三条虚构草稿，清空只改当前页面，不连服务、不删文件，刷新就恢复。

先打开试一下

下载 ZIP，解压后双击 index.html，用支持原生 dialog.showModal() 的现代浏览器打开，无需安装依赖。页面有“清空演示草稿”和“恢复3条演示草稿”两个按钮。

用 Tab 选中“清空演示草稿”，按 Enter，再照这张表走一遍：

最后一步别省。这个示例每次打开都会把 returnValue 清空，只有明确确认才清列表。触发按钮也一直保留且可聚焦，才能兑现“关闭后回到原位置”。

把行为写进给 AI 的需求里

可以直接复制这一段，让模型交付可运行文件后再按表验收：

交付一个离线单文件 index.html，展示3条虚构草稿。
用原生 dialog + showModal 做“清空演示草稿”确认框，
关联可见标题和说明，初始焦点到取消，提供可见焦点样式。
Tab/Shift+Tab 在框内循环，Esc和取消都保留草稿；
只有明确确认才清空本页列表，并用 role=status 提示结果。
每次打开重置确认返回值，关闭后焦点回到始终可用的触发按钮。
提供恢复3条按钮；不接网络、存储、真实文件或服务。
请实际验证上述路径，不能把截图当作交互测试结果。

完整提示词在 prompt.txt，手动检查表在 CHECKLIST.md，代码都在 HTML 里。这一页只有两个弹窗按钮，里面的 Tab 处理也只服务这两个按钮；加输入框、链接或动态控件后，要重新处理焦点顺序，别当成通用组件直接套。

这份固定原型已经在本地 Chromium 154 的桌面视口和390像素宽视口跑过15项检查；从 ZIP 解压后又跑了一遍。另做了一份仅存在于验证过程的错误版本，故意把初始焦点改到确认，检查确实抓到了这个差异，第二次 Enter 会清空演示列表。错误版本没有放进附件。

包内 BROWSER-CHECKS.json 保存具体检查结果。这里验证的是本地示例，不是某个模型的生成效果；也没有覆盖读屏软件、其他浏览器或真实删除接口。键盘行为能用，不等于整个产品已经通过可访问性验收。

下载完整 HTML、提示词、检查表及验证记录（ZIP，5个文件）

参考：MDN 的 dialog、showModal、cancel、returnValue 文档，以及 W3C WAI-ARIA APG 的模态对话框模式，均于2026-10-23查阅。