先说结论：WAVE 是放大镜，不是裁判
WAVE 的价值在于把网页里看不见的可访问性信息摊开给你看。图片有没有替代文本，表单控件有没有 label，标题结构是不是乱跳，颜色对比度是否明显不足，这些问题它很擅长。
坑也在这里。很多人看到报告就逐条机械清零，结果把页面改得更糟。无障碍不是为了让工具安静，而是让真实用户能理解、能操作、能完成任务。
wave避坑：别被报告带偏
wave避坑的核心不是少用 WAVE，而是别把自动检测报告当判决书。WAVE 能帮你快速定位页面无障碍问题，但它也有边界：能判断结构，不能理解业务；能提示风险，不能替你做语义决策。
坑一：把所有 Alert 都当错误
WAVE 的 Alert 是“请你看一眼”，不是“必须改”。比如它提示 nearby image has same alt text，可能确实重复，也可能是一组装饰图被错误保留。再比如 suspicious link text，是否可疑要看上下文。
解决办法是给团队定判断标准：红色错误默认修；黄色警告必须人工确认；确认不修的要写理由。这样既不会漏掉风险，也不会让开发陷入无意义返工。
坑二：alt 文本为了填而填
缺 alt 是 WAVE 很容易抓到的问题，但补 alt 最容易写废话。商品图写“图片”，活动海报写“海报”，图标写“icon”，对屏幕阅读器用户几乎没有帮助。
判断方法很简单：这张图如果消失，用户会少知道什么？商品主图可以写“黑色 13 英寸笔记本电脑正面图”；装饰分割线就应该 alt 为空，而不是硬塞描述。
坑三：只测静态页面，不测交互状态
很多问题藏在点击之后：弹窗打开后焦点有没有进入弹窗，关闭后焦点是否回到触发按钮，下拉菜单能不能用键盘展开，错误提示是否被读到。WAVE 能检查当前状态，但它不会替你走完整流程。
实操时我会在三个状态各跑一次：初始页、表单报错后、弹窗或菜单展开后。尤其是注册、支付、提交这类关键路径，别只扫首页。
坑四：用 ARIA 修补错误语义
看到 WAVE 报问题，有人第一反应是加 aria-label、role、aria-hidden。ARIA 很有用，但也容易越修越乱。原生 button 能解决的，别用 div 加 role='button' 硬凑。
优先级记住一句话：能用原生 HTML，就别先上 ARIA。链接用 a，按钮用 button，输入框配 label，标题按层级写。结构对了，WAVE 报告通常会干净很多，用户体验也更稳。
收个尾：好报告要能指导修改
真正有用的 WAVE 报告，不是截一张满屏红黄图标，而是把问题转成可执行任务。比如“结算页手机号输入框缺少可见 label，建议添加 label for='phone'，错误提示用 aria-describedby 关联”。
你可以把 WAVE 当第一道筛子：筛出低级结构问题，再用键盘、读屏、人工语义检查补上空白。这样做，既快，也不容易被报告带偏。
推荐阅读
常见问题
- WAVE 的黄色警告必须全部处理吗？
- 不用全部机械处理。黄色警告代表需要人工复核。确认影响理解或操作的就修，确认合理的可以保留，但最好记录判断理由。
- 为什么 WAVE 没报错，用户还是说不好用？
- 因为 WAVE 主要做自动化检测。键盘焦点、交互流程、文案是否清楚、读屏顺序是否自然，都可能需要人工测试才能发现。
- WAVE 报 ARIA 问题怎么修最稳？
- 先检查能不能换成原生 HTML 控件。只有原生语义满足不了时，再使用 ARIA，并对照 WAI-ARIA Authoring Practices 验证键盘行为。