实用教程
Claude Opus 5.5 弹窗焦点修复：检查产品页键盘操作
用 Claude Opus 5.5 检查产品弹窗时，应把它拆成打开、导航、关闭和返回四个键盘状态。弹窗即使居中显示，也可能让用户的焦点留在遮罩后面，或在关闭后跳回页面顶部。提供组件代码和实际焦点轨迹，才能验收模型提出的修改。
用 Claude Opus 5.5 检查产品弹窗时，应把它拆成打开、导航、关闭和返回四个键盘状态。弹窗即使居中显示，也可能让用户的焦点留在遮罩后面，或在关闭后跳回页面顶部。提供组件代码和实际焦点轨迹，才能验收模型提出的修改。
先定义每个动作的结果
| 动作 | 预期结果 | 需要记录的证据 |
|---|---|---|
| 打开产品规格 | 焦点进入有用的弹窗内容 | 打开后的活动元素 |
| 按 Tab 和 Shift+Tab | 焦点留在模态弹窗内 | 首尾可到达控件 |
| 按 Escape 或可见关闭按钮 | 弹窗关闭 | 关闭后的可见状态和焦点 |
| 触发按钮消失后关闭 | 焦点到达合理的下一位置 | 替代位置及选择原因 |
W3C 模态弹窗模式说明了受约束的键盘导航与焦点返回，通常应回到打开弹窗的元素。如果该元素已不存在，就要选择符合操作流程的去处。这是行为要求，不是给普通遮罩加一个 `aria-modal` 就算完成。
产品规格弹窗的焦点轨迹
假设马克杯页面有“查看规格”按钮、较长的规格弹窗，以及弹窗外的“加入购物车”。打开时，把焦点放到带 `tabindex="-1"` 的静态标题，可能比直接跳到下方第一个链接更合适。这个标题供程序定位，不会额外加入正常 Tab 顺序。简短确认弹窗则可能更适合先聚焦相关控件。
可以把轨迹写成：查看规格 → 弹窗标题 → 关闭 → 保养说明链接 → Tab 循环后回到关闭 → Escape 后回到查看规格。具体顺序取决于文档。如果商品切换使原触发按钮消失，应明确替代位置，例如新商品标题或下一个相关控件。不要为了让断言通过而随便选一个页面按钮。这是假设测试场景，不是已执行的 Opus 测试记录。
保留可见的关闭控件。点击遮罩不能代替明确的关闭入口和键盘操作。新实现可先了解原生 dialog 元素及 `showModal()`。如果项目已有弹窗组件库，优先沿用其生命周期和焦点接口，避免另加一套焦点圈定代码与它冲突。
可直接使用的修复提示词
检查这个产品弹窗的键盘生命周期。我会提供组件、使用中的弹窗库版本、触发按钮代码、相关 CSS，以及打开、正向 Tab、反向 Tab、Escape、可见关闭按钮的焦点轨迹。缺失的运行证据标为未知。
建立动作、预期焦点、实测焦点对照表。分别判断初始焦点、范围约束、关闭和返回焦点的问题。说明初始位置是否适合长篇静态内容或简短操作弹窗。保留现有可访问名称、可见关闭入口和组件接口。不要假定 aria-modal 本身就能让背景不可操作。
利用现有组件库或原生 dialog 行为提出最小修改。处理触发元素已被移除的情况，并给出有理由的返回位置。输出补丁，以及普通关闭和触发元素移除两类键盘验收步骤。没有真实日志就不要宣称已做辅助技术测试；没有必要性证据就不要重写整个界面。官方 Opus 指南提供了上下文和明确要求的组织方法。这里提出的是审查流程，并不表示模型已经通过这些验收。
不只测试打开，还要测试返回
在真实应用里用键盘执行这条轨迹。覆盖重复打开关闭、反向 Tab、最长内容，以及会移除触发按钮的状态更新。逐步检查焦点是否可见。DOM 中存在弹窗，并不能证明背景控件不可操作，也不能证明焦点已正确返回。实际执行辅助技术检查时，应记录浏览器和辅助技术的版本。
常见问题
**焦点总要放到第一个按钮吗？** 不需要。较长的结构化内容可能需要静态起点；破坏性确认操作可能更适合先选风险较小的动作。
**只靠点击遮罩关闭够吗？** 不够。要保留明确的关闭控件，以及适合该弹窗、已经验证的键盘关闭路径。
**自动焦点轨迹能证明无障碍合格吗？** 它能捕捉特定回归，但不能代替名称、阅读顺序和真实辅助技术行为的检查。
交互修好后再进入广告制作
产品页面可正常使用后，把已确认的商品图和文案交给 Panelly Studio制作广告变化。如果问题是提交失败而非弹窗导航，请看独立的表单错误恢复流程。这里的 Panelly 是创意工作区，不代表已集成 Opus。
