Wizard / Stepper 用于多步骤表单和流程。
解决的问题 Wizard / Stepper 模式帮助团队以可靠的方式将一个长流程拆分为有序步骤，并提供可见的进度和复核检查点。当团队需要处理引导与设置（onboarding and setup）时，该模式最为有用。与相邻模式相比，该模式应在不隐藏人们持续前进所需的状态、规则或恢复路径的前提下减少阻力。
何时使用
- 引导与设置（Onboarding and setup）
- 结账与申请流程（Checkout and application flows）
- 多步骤的内部工具（Multi-step internal tooling）
何时避免
- 当产品界面还很小的时候，使用更简单的可见导航或单页流程。
- 如果团队无法很好地支持其状态复杂度，避免使用高级交互模式。
- 在简单路径已经足够强大之前，不要引入隐藏的高级用户行为。
实现工作流
- 在复制示例之前，先确认该模式是否匹配问题与约束。
- 从 references/pattern.md 中的结构与示例入手，然后选择最小的可行变体。
- 在叠加视觉打磨之前，先应用无障碍、性能和交互护栏。
- 使用测试指南验证键盘、屏幕阅读器、响应式和失败场景下的行为。
无障碍护栏 键盘交互
- 验证仅用键盘即可完成 wizard / stepper。
- 当模式打开、更新或显示额外 UI 时，保持逻辑焦点顺序。
- 保持在高倍缩放时仍可读的可见焦点状态。
屏幕阅读器支持
- 优先使用语义元素，仅在语义不足处添加 ARIA。
- 在正确位置以正确的礼貌程度宣布错误、加载或完成等状态变化。
- 在有用时，用 aria-describedby 或结构化标题关联标签、提示和状态文本。
视觉无障碍
- 不要仅依赖颜色来传达严重程度、完成状态或选中状态。
常见错误 只设计顺利路径（happy path） 问题：该模式在加载、空和失败状态出现之前显得很精致。 如何修复：在默认状态之外明确完整生命周期，以免后续实现时临时发挥。 让交互与内容脱节 问题：当控件、状态和支持信息感觉不连贯时，用户需要付出更多努力。 如何修复：让该模式的信息架构贴近交互模型。 把无障碍当作最后一轮工作 问题：一旦交互已经固定，键盘、播报和阅读顺序问题会变得昂贵。 如何修复：在第一次实现时就融入语义、焦点行为和播报。
相关模式 https://uxpatterns.dev/patterns/e-commerce/checkout https://uxpatterns.dev/patterns/forms/form-validation https://uxpatterns.dev/patterns/user-feedback/progress-indicator
完整实现细节、示例和测试说明见 references/pattern.md。
模式页面：https://uxpatterns.dev/patterns/advanced/wizard