如何编写可验证的无障碍用户故事。
无障碍需求应描述可观察的交互行为。使用提供的相关标准，并说明如何检查行为。
按任务需求调整流程。
描述对应访问需求的交互结果，附上可观察的验收检查。适用时包含焦点、控件名称等要求，再用合适的测试方法验证实现。
- 你需要提供什么
- 界面场景和提供的无障碍标准。
- 你会得到什么
- 面向实现的无障碍需求。
查看输入和结果。
演示用输入和输出 · 教学示例，并非 WebAct 实时运行结果
示例 个输入项
Draft a keyboard-accessibility user story for a dialog. Opening moves focus inside; a labeled close action is keyboard-operable; closing returns focus to the opener. Include acceptance checks.
完整示例
Story: As a keyboard user, I want to open, use and close the dialog without losing my place. Acceptance checks: - Opening the dialog places focus on a sensible element inside it. - The close control has an understandable accessible name and works from the keyboard. - Closing returns focus to the control that opened the dialog. Verification: exercise these behaviors in the implemented interface; this draft alone does not establish conformance.
将这份输入载入提示词，再复制到 WebAct 中尝试任务。实际结果可能与示例不同。
决策与问题排查。
无障碍用户故事可以代替测试吗？
不可以。它定义预期行为和检查项。仍需实际键盘、辅助技术或其他相关测试来评估实现。
为什么“让它无障碍”这样的要求很难验证？
明确交互与可观察结果，例如关闭对话框后，将焦点返回到打开它的元素。
使用自己的资料试一试。
将任务提示词中的示例换成你的材料。保留所需条件，再把任务复制到 WebAct。
自定义并复制任务 ↑