为什么无障碍审查不该把“模拟器截图”当成全部答案

很多团队做色觉无障碍审查时，第一反应都是开模拟器、截一张图、贴进评审文档。这个动作不能说没用，但它真的只是开胃菜。截图能帮你发现明显的问题，比如成功和失败全靠红绿区分，或者折线图两条线在模拟视图里几乎黏成一条。可一旦你把审查停在这里，后面最致命的坑反而容易漏掉。

因为用户不是来欣赏截图的，用户是来完成任务的。

截图适合做第一轮筛查

我其实挺喜欢先看模拟器截图，原因很简单，快。做设计评审、走查组件库、整理风险清单时，它很适合用来抓那些一眼就能确认的颜色依赖。

比如这些场景：

• 表单报错只有红字，没有错误图标，也没有字段级提示
• 数据图表只靠红线和绿线区分系列，图例文字又写得很短
• 审批状态、库存状态、告警状态都只剩一颗彩色小圆点
• 按钮的可点击、禁用、已完成，主要靠颜色深浅在表达

这一步很像安检。你先把明显危险品挑出来，别让团队还停留在“我们配色已经很统一了，应该没问题”这种错觉里。

真问题往往出在流程里

但截图有个天然短板，它只会告诉你某一刻长什么样，不会告诉你人在这个页面上到底怎么做事。

举个最常见的例子。一个后台列表里，红色标签表示异常，绿色标签表示正常。截图看上去没什么，大家甚至会说“文字也写了呀”。可真到任务走查时，问题就出来了。用户要先筛选，再批量勾选，再看侧边抽屉里的状态解释，还要在不同页签之间来回切。颜色只是其中一小段信息链。要是抽屉里的解释文案太短、筛选项命名又模糊，用户照样会在关键节点上犹豫。

还有一种更隐蔽。页面静态状态没问题，交互状态才有问题。比如 hover、focus、loading、成功 toast、失败 toast，这些东西做截图时经常不会一起出现，可用户真实使用时恰恰最依赖它们。你不把任务完整走一遍，就不知道颜色之外的提示是不是足够。

所以我们在审查里最该问的，不是“这张图看起来像不像色弱用户视角”，而是“如果颜色信息突然不可靠，这个任务还能不能走完”。

比起单张图，更值得看任务链路

任务走查不是高大上的方法，反而很土，很实用。选三到五条核心路径，真机打开，按真实顺序走一遍。注册登录、提交表单、看报表、处理异常、导出结果，这几条通常就够你抓出一大半问题。

走的时候别只盯页面本身，重点看三个点：

• 关键决策是不是只有颜色在提醒
• 用户出错时，系统有没有用文字、图标、位置变化把信息补全
• 状态切换以后，上一秒和下一秒的差异能不能被稳定看懂

很多团队一做这个动作就会发现，最该改的根本不是某个绿色太浅，而是组件从头到尾都默认“大家会看颜色”。

一轮靠谱审查，通常是三种方法一起上

如果你问我怎么排，我会这样组合：

先用模拟器截图做大面积扫雷。它很适合组件库、设计稿、历史页面盘点，成本低，推进也快。
再用真机检查把亮度、反光、屏幕调校这些现实变量补上。桌面显示器看着没事，手机在地铁里看就是另一回事。
最后做任务走查，把“看得见”换成“做得成”。这一步最花时间，但也最值钱。

谁都别指望单一方法包治百病。截图不是没用，只是它解决不了流程问题；任务走查最接近真实使用，但不适合拿来扫全站。把三种方法拧在一起，审查才不会虚。

延伸阅读

如果你还想继续把这条线看清楚，可以接着读 成功、失败、警告只用颜色区分，会带来哪些真实问题、招聘、驾驶、学校场景之外，普通 SaaS 为什么也该重视色觉无障碍 和 用在线色觉测试做团队培训，最适合讲清楚哪些概念。这三篇跟你现在这个阶段更贴近，读完以后通常会更容易决定下一步。