北京
自动化无障碍测试扫过现代着陆页时，最大的标题栏往往不会直接通过，而是返回一个奇怪的“需要审查”状态。根源在于页面那层漂亮的渐变背景。这到底是怎么一回事？
问题出在主流无障碍检测引擎（如 axe-core）的工作方式上。它判断文字是否易读，靠的是把文字颜色和它背后的背景色放到一起算对比度。方法很直接：读取元素及其祖先元素计算后的 background-color 值，得到一个单一的纯色，然后套公式。可 CSS 渐变不是纯色，它通过 background-image: linear-gradient(...) 来设置，整片背景在不同位置颜色都不一样。当文字直接叠在渐变上时，检测引擎找不到一个固定的背景值来做算术，于是老老实实把这条结果标记为“不完整”——也就是“需要审查”。
这个处理逻辑本身没错，但它带来了一个尴尬的副作用：被“踢”出来不让自动判断的文字，常常是页面上最显眼的文字，也就是那个压在彩色渐变横幅上的主标题。它恰好是设计师最想确保可读性的地方，却成了自动化测试的盲点。
解决这个盲点，并不需要对渐变上的每一个像素都去采样。渐变完全由它的色标（color stops）定义。在任意两个相邻色标之间，颜色沿着路径平滑过渡，而文字颜色和这段背景之间的对比度也会跟着平滑变化，中间不会突然冒出某个危险的低谷。这意味着，最糟糕的情况——最低的对比度——一定就出现在其中的某一个色标上。整个问题就简化成了：拿文字颜色去和渐变的每一个色标计算对比度，找出最小的那个值，再和 WCAG 的门槛比一下。如果最差的色标都能通过，那么整个渐变背景上的这段文字就都能通过；如果最差的色标不达标，也拿到了一个实打实的失败数值，方便设计师去调整。
这里的对比度门槛来自 WCAG 1.4.3 最低对比度标准：普通文字至少 4.5:1；大文字（24px 及以上，或粗体 18.66px 及以上）至少 3:1。对比度本身则是从相对亮度算出来的：先把红绿蓝通道从 0–255 的色阶值线性化，再按 0.2126、0.7152、0.0722 的权重加权求和得到亮度，最后用 (较亮者 + 0.05) / (较暗者 + 0.05) 得出比例。这和检测引擎在纯色背景上用的公式一模一样。我们并没有改变对比度的评判标准，只是让检测工具拿到了正确的颜色去评判。
具体到自动判断流程里，对于每一个被标为“需要审查”的文字元素，可以这样做：先取出文字的计算后 color，以及字号和粗细，锁定该文字对应的合格比例是 4.5 还是 3；然后沿着 DOM 树向上查找，找到最近一个 background-image 属性值里确实包含 gradient( 的祖先元素；接着从这个值里把色标一个个抽出来——浏览器已经将关键词和十六进制都算成了 rgb() 或 rgba() 的具体数值，所以拿到的就是一组实实在在的颜色；最后用前面提到的公式算出文字色与每个色标的对比度，取最小值。只要这个最小值过了对应的阈值，文字就过关。
整个过程只增加了一小块运算，却能覆盖掉绝大多数因渐变背景被搁置的对比度审查项。它没有引入新的判断逻辑，只是把“没有单一背景色”这个信息缺口填上了。对于每天都在处理无障碍报告的前端工程师来说，标题栏的那个“需要审查”标签，终于可以变成一个明确的通过或失败结果。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
