J5.08.3automated accessibility score设计研究
通过自动检测不等于可用
别名: 自动通过不等于可用 · Lighthouse 分数 · 假阳性合规
概念解释
Lighthouse 一百分、axe 零违规，结账仍可能在阅读器里走不通。通过自动检测证明的是可判定子集里没有被抓住的失败，不是一个人用辅助技术能完成任务。绿分数不是可用性结果。
机制
自动检测回答「这些可计算谓词破了没有」。可用性回答「目标用户在其辅助技术上能否完成主任务」。两个谓词的外延不同：前者的通过，只排除了一小类缺陷；键盘陷阱、错误的阅读顺序、名不副实的按钮、移动端轻扫走不通，都可以活在满分下面。
分数还会制造停测。团队把绿门当成收工条件，阅读器走查和障碍用户测试被挤出迭代。假信心比漏掉几个对比度更贵——对比度还能在下一轮补，被分数挡住的人工测试会让结构性的走不通一直活到上线。自动通过是必要的过滤器，不是终点证明。
怎么研究
选一批自动分数高的真实页面（或本产品发布候选），用键盘和至少一对阅读器组合走主任务，记录任务成功、卡住的步骤。有条件时请使用自己设备的障碍用户再走一遍。
自变量：自动分数 / 违规数、是否另做人工 AT 走查。 因变量：主任务完成率、只被人工发现的阻断缺陷数。
把「零违规」和「结账成功」当成两个独立结果看。不要用分数预测完成率。
边界
自动失败通常仍是真失败，该修；这条不给「工具报了也可以忽略」做掩护。很小、几乎没有交互的静态页，自动通过和能用之间的缝会窄一些。分数被拿去应付采购问卷时，它的社会功能是合规信号，不是可用性证据——两种用途混在一份报告里，最容易把绿当成能用。障碍用户测试也替代不了自动回归：自动拦的是可判定回归，人测拦的是能不能用，两边都要。
怎么落地
- CI 的绿门只用来拦可判定回归，发布清单上另列「键盘走完主任务」和「阅读器走完主任务」。
- 不要把自动分数写进对外声明当作可用证明；声明里应写测了哪些组合、主任务是否走通。
- 验证：取一个自动满分的构建，关掉显示器只用键盘走完结账，再用阅读器听完同一流程。任一步走不通，满分就不等于可用。