把按钮变大、把标题加粗，可以强化界面层级；把红色和绿色放在一起，也会产生明显的色相差异。但这些变化不等于文字一定更容易读。文字能否从背景中被识别，需要检查前景与背景的明度对比，还要考虑字号、字重、图片背景和使用状态。
例如白底上的浅灰说明文字，在设计软件放大到200%时可能看着很精致，缩回真实尺寸后却很难辨认。本文把“视觉上有差异”和“文字满足对比要求”分开检查，给出一套从单个颜色对到组件、页面和实际运行环境的验收方法。
1. 先区分层级对比、色相对比与明度对比
层级对比通过大小、粗细、位置和留白决定先看什么；色相对比帮助区分颜色家族；文字对比度则衡量文字与相邻背景之间的相对明度关系。三者会同时影响界面，但不能用一个代替另一个。红字配绿底，即使颜色看起来截然不同，也可能因为明度接近而难读。
同样，“互补色对比最强”不是无障碍配色的验收结论。把浅黄色与白色搭配，或把两种很饱和但明度接近的颜色叠在一起，都需要实际测量。图标、标题和文字可以用同一个品牌色，却未必适合出现在同一背景上；每一种相邻关系都要单独检查。
一个简单的工作顺序是：先保证信息能够被识别，再通过字号和留白组织层级，最后调整风格细节。不要先把次要内容都调成很浅的灰，再期待增加字号解决所有问题。次要内容如果仍然需要阅读，就应该保持清晰。
2. 按文字类型判断阈值，不凭肉眼“差不多”
在WCAG 2.2的AA层级，普通文字最低对比度为4.5:1，大文字为3:1。大文字一般指至少18pt，或至少14pt的粗体；CJK字体需要考虑等效尺寸，不能把设计稿中任意一个“18”都当作合格大文字。具体定义、例外与计算方法见W3C最低对比度说明。
验收时使用最终呈现的字体大小、字重、前景与背景值。例如白色背景上，#767676文字的对比度约为4.54:1，#999999则约为2.85:1。前者刚超过普通文字阈值，后者不能作为普通正文合格的依据。这里显示的两位小数只用于解释，实际判定应使用未四舍五入的计算结果。
不要把“次要说明”理解成可以随意降低对比度。帮助说明、可输入时的占位文字、错误文字，仍是用户需要读的信息。禁用控件等存在规范例外，但“看起来像禁用”并不等于真的不可操作；如果浅灰链接仍然能点击，就应该按它的实际功能检查。
也不要为了恰好过线，把所有正文都压在临界值附近。细字体、长时间阅读和复杂背景可能让名义达标的配色仍然吃力。项目可以选用更有余量的正文色，同时用字号、间距和分组表达主次，不必让辅助说明消失在背景里。
3. 输入框、图标和选中状态检查自己的边界
文字达标后，还要检查用户是否能识别控件和状态。W3C非文字对比度要求对识别界面组件、状态或理解图形所必需的视觉信息提出3:1的相邻颜色对比要求，并列出例外。它不是要求界面中每条装饰分隔线都必须达到3:1。
例如输入框只有边框能够表明可填写区域，就应该重点检查边框与外侧背景；如果边框极浅，但一个明确的填充区域已经能识别输入框，也要依据实际识别方式判断。不要只在组件规范里写“边框灰色”，而不给它所处的背景颜色。
选中、聚焦、错误和按下状态需要逐一检查。按钮从默认到焦点和禁用的变化，可结合按钮尺寸与状态设计逐个比较。浅底上的紫色焦点环可能清楚，到了同色深底卡片上却消失；单选按钮中心的小圆点在默认状态可见，禁用后的细节也许完全不可辨认。把各状态放在对应背景上成组查看，比单独展示一排色块更有意义。标签切换则需同时检查选中态与其他标签的可见性。
4. 错误、链接和图表不要只靠颜色解释
对比度解决能否看清，并不自动解决能否理解。用户看见红色边框，未必知道是格式错误、必填提醒还是安全警告。W3C颜色使用说明要求信息不能只通过颜色表达，可以结合文字、图标、形状或其它可辨认线索。
以手机号输入为例，边框变红之外，写清“请输入可接收预约通知的手机号”，在格式错误时再给出具体修正提示；不要仅显示一个红点。正文链接可以用下划线等方式让它与普通文字区分，图表的多个系列可以配直接标签或线型，不把“红色就是A、绿色就是B”作为唯一解释。
设计图上的图标也需要语义。感叹号能提示有问题，但不能代替原因；一个问号图标若必须点击才知道含义，交付时应说明可访问名称与键盘操作。涉及实际输入流程时，可把移动表单的错误恢复状态和配色一起检查；涉及图表时，则同时核对图表编码与口径。
5. 在真实背景与主题上测量
透明文字、半透明卡片、渐变按钮和图片横幅不能只取一个基础色作为背景。透明度叠加后，最终颜色会变化；图片也可能随着裁剪或内容更新让文字落在更亮的区域。检查应覆盖文字实际经过的最不利背景位置，必要时增加稳定的底色区域，避免靠一张恰好合适的照片过关。
深色主题也不适合简单把颜色取反。浅色主题的强调色在深底上可能合适，但同一个颜色用于按钮文字时未必合适。分别定义页面背景、容器背景、普通文字、辅助文字、链接和状态色的搭配关系，再检查弹窗、浮层和表格等叠加场景。
如果页面支持自定义品牌色，验收范围还要包括用户输入的颜色。可以限定可用于文字的色阶，或在不满足条件时提示更合适的搭配。不要只测试默认主题，发布后却允许任何颜色直接成为正文或按钮前景。
6. 把修正落实到组件与交付记录
在Pixso中建立一页对比度检查稿：左侧放实际组件，右侧记录前景值、背景值、字号、字重、状态和检查结果。先挑出正文、表单提示、链接、按钮文字等高频组合，再补齐悬停、聚焦、错误和深色背景。使用插件或外部检查器时，记录工具结果对应的具体颜色对。
修正颜色不要只改一张画板中的某个文字层。找出它属于哪个语义角色，例如辅助正文或输入提示，再修改相应样式或变量，并查看所有引用位置。某个灰色可能同时被当作分隔线和辅助正文，直接全局加深会改变无关视觉；更合理的做法是拆分这两种用途。
团队维护检查表时，建议同时保存通过和未通过的组合。只保留一组“合格灰色”，后来的人可能把它放到另一种背景上继续使用。把背景角色、状态与适用字号写在同一行，才能说明这个结果适用于哪里，也能知道主题改动后哪些组合必须重新测量。
交付记录可以写成：“辅助正文在白底上原为#999999，改为#767676；默认与错误状态已分别检查；图片背景中的相同角色使用独立规则。”这让研发知道修改对象和边界，也能在后续主题迭代中找到依据。将记录纳入UI评审问题清单，避免下一个版本再次把颜色改回去。
7. 颜色通过后，再检查文字能否完整呈现
高对比度文字如果被固定高度裁切，仍然无法阅读。最后一轮应该改变浏览器缩放、系统文字设置和页面宽度，检查正文、按钮、表单错误是否换行、溢出或遮挡。对于用户调整文字间距的情况，W3C文字间距说明关注的是内容与功能不因调整而丢失；这并不是要求所有界面都只能采用一种固定排版。
- 颜色对是否来自实际实现，而不是设计稿中未落地的旧值？
- 普通文字、大文字与非文字组件是否分别按适用要求检查？
- 透明、渐变、图片和深色主题是否覆盖真实背景？
- 错误与选中状态是否同时提供非颜色线索？
- 放大文字后，标签、按钮和提示是否仍然完整可用？
把这些结果写成可复查的记录，下一次换品牌色或改组件时就有明确的回归范围。可读性不是把所有元素做得一样醒目，而是让用户在每一种必要状态下，都能看清信息、理解含义并继续完成任务。
