Web 无障碍配色实战深入理解对比度比率与 WCAG 一致性等级The Odin Project 课程【免费下载链接】curriculumThe open curriculum for learning web development项目地址: https://gitcode.com/GitHub_Trending/cu/curriculum给网页添加颜色能让页面更美观但错误的颜色组合、或者仅靠颜色传达信息都可能让一部分用户更难感知和理解内容。本文基于本仓库中 archive/html_css/accessible_colors.md 一课其最新修订版位于 advanced_html_css/accessibility/accessible_colors.md系统讲解对比度比率contrast ratio的定义、WCAG 的 AA/AAA 一致性等级要求、如何用浏览器 DevTools 等工具检查对比度以及颜色不能单独作为信息载体这一核心设计原则。学完本文你将能自主评估任意文本/背景配色是否达标并在表单、按钮、链接等场景中给出不依赖色觉的备选信息呈现方案。为什么配色会成为无障碍问题在 introduction_to_web_accessibility.md 中我们了解到Web 无障碍常简写为 a11y意味着网站、工具与技术要尽量让残障人士以及处于情境性限制situational limitations中的用户无障碍使用。视觉障碍正是其中最常见的类型之一——包括永久性失明、低视力、色觉缺陷色盲也包括阳光下看不清屏幕这类临时性情境限制。颜色在这个语境下是双刃剑恰当的前景/背景配色可以显著提升可读性对比度不足的配色让低视力用户难以辨认文字仅靠颜色例如红色表示必填传达信息则会让色盲用户彻底丢失这部分信息。这不意味着在设计配色方案时要束手束脚而是在使用颜色时格外谨慎。课程原文archive/html_css/accessible_colors.md反复强调的正是这一点你依然可以自由选择配色只是必须承担起让这些颜色真正可感知的责任。对比度比率Contrast Ratio是什么对比度比率是两种颜色之间亮度差异的量化比值。它的取值范围从最低的 1:1 到最高的 21:1场景对比度比率白底白字1:1最低完全不可见白底黑字21:1最高对比度比率同时适用于普通文本和文本图片images of text即内容为文字的图片。从原理上看对比度比率并非任意颜色距离公式而是基于 WCAG 定义的相对亮度relative luminance计算得出先将 sRGB 颜色值转换为线性 RGB再按权重R×0.2126 G×0.7152 B×0.0722计算相对亮度 L最终比率取(较亮颜色的L 0.05) / (较暗颜色的L 0.05)其中 0.05 是补偿环境光与显示设备黑位的常量。你可以把这理解为公式衡量的是人眼感知到的亮度差而非颜色本身的色相差——因此两张色相差异巨大但亮度接近的配色例如红色与绿色也可能得出很低的对比度比率。好消息是你不需要亲手计算这些公式。后文介绍的工具会替你完成全部计算。正常文本与大文本的划分WCAG 的一致性等级规则针对两类文本分别设限其分界线来自印刷排版中的磅值point体系换算到屏幕像素后如下正常文本normal text字号小于 18pt/24px或粗体文本字号小于 14pt/18.66px。大文本large text字号至少 18pt/24px或粗体文本字号至少 14pt/18.66px。也就是说粗体文本的大文本门槛更低14pt 即可因为粗体本身增加了字形的视觉重量人眼更容易辨识。这些具体数值18.66px、4.5:1……确实不好记但正如课程所说你完全不必死记硬背——交给工具计算即可。WCAG 一致性等级AA 与 AAAWCAG 对对比度设置了两个需要达标的一致性等级conformance levels一致性等级正常文本最低对比度大文本最低对比度AA最低要求4.5:13:1AAA增强级7:14.5:1在实践中AA 是多数组织努力达到的目标等级。正如仓库中 the_web_content_accessibility_guidelines_wcag.md 所总结的WCAG 的一致性等级共三级Level Aessential support最低、Level AAideal support多数组织追求、Level AAAspecialized support不建议全站追求。满足 AAA 自动意味着同时满足 A 与 AA但某些内容本身可能使 AAA 无法达成因此 AAA 通常只用于特定关键内容。AAA 的 7:1 是相当苛刻的标准很多好看的配色方案在它面前都会落败因此不建议把全站所有文字都强行压到 AAA。需要说明的是对比度规则存在豁免例外以下三类文本无需遵循上述对比度要求advanced_html_css/accessibility/accessible_colors.md偶然性文本incidental text图片中作为其他显著视觉内容一部分出现的文字或纯装饰性文字。禁用/非活动 UI 组件中的文本例如一个被禁用且降低了不透明度的按钮上的文字。这也提示我们禁用态通过降低透明度来传达不可用是常见的辅助手段。Logo 与品牌名称中的文本。如何检查对比度比率方法一在线对比度检查工具WebAIM Contrast Checker 是课程首推的检查工具输入前景与背景颜色的 HEX 值它会自动计算对比度比率并给出该比率通过的对应一致性等级。工具页面同时提供链接对比度检查器link contrast checker用于评估未被下划线标注的文本链接应达到的对比度——因为链接需要同时满足与背景的对比度以及与正文的对比度才能被用户可靠识别为可点击项。方法二浏览器 DevTools无需离开浏览器即可完成检查。课程原文分别给出了 Chrome 与 Firefox 的操作路径ChromeElements 面板点击 Elements 标签页中的元素选择器element picker工具然后在网页上悬停目标元素弹出的提示框中会显示该元素文本的对比度比率或者在 Elements 标签页中选中一段包含文本的元素在 Styles 面板中找到color属性点击其颜色选择器即可查看对比度比率。Firefox无障碍面板点击 Accessibility 标签页中的accessible object picker工具再在页面上悬停元素查看对比度在 Inspector检查器中选中含文本的元素同样可以点击 Styles 下color属性的颜色选择器查看对比度比率。这两种方式都属于快速审计配合 accessibility_auditing.md 一课会更成体系该课介绍了 Chrome DevTools 默认内置的 Lighthouse可单独跑无障碍类别审计、axe DevTools 扩展按严重程度列出问题以及 WebAIM WAVE 网页审计工具其中 WAVE 专门把问题划分为对比度错误contrast errors等类别。养成用 DevTools 快速检查、再用第三方工具全面审计的习惯就能系统性地追查遗漏的无障碍问题。不要只用颜色传达信息理解了对比度之后还有一个更隐蔽的陷阱颜色本身也是信息载体但色觉缺陷用户接收不到这份信息。课程用了一个经典例子下图原文所配的色盲模拟图模拟的是全色盲 achromatopsia即完全无法区分颜色中的四个按钮请读者判断哪一个才是红色的。正确答案是第 4 个按钮。在这个模拟视角下所有按钮的色相信息全部消失只剩下灰度明暗——如果你无法从图中分辨出红色按钮就说明仅凭颜色的信息传达方式对全色盲用户是完全失效的。由此得出本课最核心的一条铁律你不应该仅用颜色来传达信息。虽然存在不得不只用颜色的例外场景但一般情况下都应遵守此规则。课程给出的补救方案是把颜色与第二种信息通道形状、文字、符号、纹路叠加使用表单必填字段不要只写必填字段以红色文字显示而应使用红色文字 星号*的组合。这样即使色盲用户分辨不出红色也仍能通过星号识别必填项表单错误提示同理见 meaningful_text.md错误信息应明确哪个输入无效、为什么无效、如何修复而不是笼统的Error: Invalid input状态、选中、成功/失败等 UI 状态都应为颜色补充图标、文字或边框等非颜色线索链接的识别若不使用下划线等非颜色线索仅靠颜色区分链接与正文就需要特别高的对比度要求这正是上文链接对比度检查器存在的意义。这种做法与 WCAG 的四大原则POUR直接呼应。仓库的 the_web_content_accessibility_guidelines_wcag.md 指出Perceivable可感知用户必须能感知呈现的信息与界面——浅色背景上的浅色文字对低视力用户难以感知正是对比度问题Operable可操作用户必须能操作界面与导航Understandable可理解用户必须能理解所呈现的信息与界面——红色表示错误如果无法被识别信息就不再可理解Robust健壮内容需兼容当前及未来的辅助技术。配色无障碍主要落在Perceivable对比度与Understandable颜色语义的冗余表达两个原则上。将配色无障碍落实到 CSS 与组件开发结合课程与仓库其他无障碍课程可以在日常 CSS 开发中落实以下具体做法1. 为交互元素提供非颜色线索。键盘焦点样式就是典型的例子。仓库 keyboard_navigation.md 强调永远不要完全移除 focus 样式如*:focus { outline: none; }。改用自定义焦点样式时可以配合transform: scale()、加粗边框、提升边框宽度与不透明度等方式让焦点位置不只依赖颜色明暗变化保证键盘用户在任意背景下都能定位焦点。2. 建立对比度达标的配色令牌。在实际项目中可把文本色/背景色抽成 CSS 自定义属性并逐一用检查工具验证其对比度对带透明度的颜色如rgba覆盖层要按最终叠加后的实际颜色去测而不是按原始色值测。课程原文对禁用组件的豁免提醒我们降低透明度会让对比度跌破阈值这既是合规上的例外也应视为一种有意的视觉降级手段。3. 文本与背景的全局默认值。默认正文采用接近黑白的最高对比21:1是最稳妥的起点彩色仅用于强调性内容并始终为这些强调补充文字、图标等第二通道。4. 用模拟工具主动验证。现代浏览器 DevTools 支持模拟视力缺陷如色盲、视力模糊可用来检查去掉颜色后信息是否依然完整第三方审计工具accessibility_auditing.md 中介绍的 axe DevTools、Lighthouse、WAVE会直接标注对比度错误。当然最可信的验证仍来自真正依赖无障碍功能的真实用户反馈。记住这些数字虽然工具会替你计算但下面这张速查表值得记住方便在写样式时快速自查项目数值正常文本普通字号 18pt/24px正常文本粗体字号 14pt/18.66pxAA 正常文本≥ 4.5:1AA 大文本≥ 3:1AAA 正常文本≥ 7:1AAA 大文本≥ 4.5:1豁免偶然性文本、禁用组件文本、Logo/品牌文本知识检查什么是对比度比率用 DevTools 检查对比度比率有哪两种方式向用户传达信息时应当避免什么做法延伸阅读最新版课程正文advanced_html_css/accessibility/accessible_colors.mdWCAG 的四大原则POUR与三级一致性等级the_web_content_accessibility_guidelines_wcag.md以及旧版存档 archive/html_css/wcag.md无障碍审计工具Lighthouse、axe、WAVEaccessibility_auditing.md有意义文本链接、表单错误、alt 属性meaningful_text.md键盘导航与焦点样式keyboard_navigation.md无障碍入门概念introduction_to_web_accessibility.md【免费下载链接】curriculumThe open curriculum for learning web development项目地址: https://gitcode.com/GitHub_Trending/cu/curriculum创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考