步骤1：先锁定页面和目标
案例是一页电商结算页，包含收货地址、优惠券、支付方式和提交订单按钮。团队原本只关心转化率，我建议先做一轮无障碍检查，因为结算页一旦表单不可用，影响的不只是体验，还有真实成交。
这次 wave对比只看两个状态：上线前旧版和修复后的新版。目标不设成“报告清零”，而是三件事：用户能读懂表单，键盘能完成下单，错误提示能被发现。
wave对比：一次改版复盘
wave对比最有说服力的方式，不是罗列工具功能，而是拿同一个页面改前改后看差异。我用一个电商结算页案例，复盘 WAVE 如何发现问题、怎么筛选优先级、哪些地方必须靠人工补测。
步骤2：旧版用 WAVE 扫第一遍
旧版 WAVE 报出的问题很典型：多个输入框缺少 label，优惠券区域用了浅灰字导致对比度不足，支付方式卡片是 div 点击，没有按钮语义。Summary 数字不重要，真正关键的是这些问题都卡在结算主流程上。
我把问题分成三档。第一档马上修：label、按钮语义、错误提示关联。第二档跟设计确认：低对比度、焦点样式太弱。第三档记录观察：标题层级不连续，但不影响当前主流程，排到后面处理。
步骤3：把 WAVE 结果翻译成任务
直接把 WAVE 截图丢给开发，效率很低。我改成任务单写法：手机号输入框缺少可编程名称，添加可见 label；优惠券删除按钮只有图标，补充 aria-label='删除优惠券'；支付方式卡片改为 button 或 radio 组。
这里的对比很明显：工具报告说的是“检测项”，开发需要的是“改哪里、怎么改、验收标准是什么”。同一个 WAVE 结果，翻译得好，半天能修完；翻译得差，来回解释三天。
步骤4：新版再测，不只看少了多少红点
新版再跑 WAVE，红色错误明显减少，对比度错误也清掉了。但我没有立刻通过，因为工具只能说明当前 DOM 好了不少。接着用 Tab 从地址栏一路走到提交按钮，检查焦点顺序是否符合视觉顺序。
发现一个新问题：选择优惠券后，页面顶部出现成功提示，但焦点还停在按钮上，读屏用户不一定知道发生了什么。这个问题 WAVE 不一定直接抓到，最后用 aria-live 区域解决，并控制提示文案别太啰嗦。
步骤5：复盘 WAVE 和人工测试的差异
改前改后对比下来，WAVE 对结构性问题非常高效，特别是表单、链接、颜色、标题。它让团队第一次具体看到“无障碍问题长什么样”，沟通成本降了很多。
但最终通过验收靠的是组合拳：WAVE 找显性问题，键盘测试找流程问题，读屏抽查找反馈问题。这个案例最大的经验是，别把 wave对比做成工具炫技，要把它做成业务流程能落地的检查清单。
常见问题
- WAVE 改前改后怎么做对比最清楚？
- 固定同一页面、同一状态、同一浏览器环境，分别保存 Summary 数字和关键截图。更重要的是记录每个问题的业务位置和修复结果。
- 结算页最该优先修哪些无障碍问题？
- 优先修表单 label、错误提示、按钮语义、键盘焦点和颜色对比度。这些直接影响用户能不能完成购买。
- WAVE 适合做改版验收吗？
- 适合做第一轮验收，但不能单独作为最终标准。改版验收还要加键盘操作、交互状态、读屏反馈和核心任务走查。