J5.08.1automated accessibility checking设计研究
自动化只能覆盖部分可判定规则
别名: 自动检测 · axe · 可判定规则
概念解释
对比度比值、图片有没有 alt 属性、重复的 id，机器能给确定答案。标题像不像标题、这张图的 alt 写没写到那条趋势，机器给不了。自动化检测只能覆盖无障碍规则里那一部分可判定的片段，不是整张规则表。
机制
一条规则能被自动判定，当且仅当谓词可以只靠结构、属性和渲染色来计算，不必理解「这句话对人意味着什么」。有没有属性、比值是否过线、节点是否可聚焦，属于这一类。一旦谓词里出现「正确 / 有意义 / 等价」，计算就停了——那不是漏测，是这类问题不在可判定集合里。
工具因此分成「失败 / 需要人工复查 / 通过」。业界常见的口径是：大约两到三成的成功标准可以全自动判定，其余要么只能抓到局部，要么整条都要人看。把工具报告当成规则覆盖率，是把可判定子集误认成全集。CI 里能拦下的，是这个子集里会破的那些。
怎么研究
拿一套含已知缺陷的页面（对比度不够、缺 alt、alt 写着「图片」、标题层级乱、键盘陷阱），分别跑自动引擎（axe、Lighthouse、WAVE）和 WCAG-EM 人工抽样。按成功标准对齐：自动抓住了哪些、标成复查的是哪些、完全没提及的是哪些。
自变量：缺陷类型（可判定 / 需判断语义）、工具。 因变量：检出率、误报、完全未覆盖的成功标准数。
不要用「问题总数」做唯一指标。可判定缺陷被抓光，语义缺陷仍可以全漏。
边界
工具在升级，曾经要人看的局部（某些对比度、某些焦点可见）会进入可判定集，覆盖率不是常数。启发式会把一部分语义问题标成「可能失败」，那是提示不是判定。对 PDF、画布、原生 App，网页引擎的可判定集合不能直接搬。规则本身若写的就是「提供等价替代」这类开放谓词，自动化的上限不是工程没做好，是谓词决定的。
怎么落地
- 把自动检测放进 CI，用来拦可判定的回归：空 alt、对比度、重复 id、缺语言标记。
- 报告里「需要复查」的项按人工流程走，不要当通过，也不要当已经失败。
- 验证：对照所用工具的规则列表，标出它声明能自动判定的成功标准。主任务上其余标准必须另有键盘或阅读器检查。工具没列出的那几条，不在自动化覆盖里。