生成配色后怎样确认文字看得清？按钮、提示和图表分开验

从图片提取出一组颜色后，不要马上把最顺眼的两种颜色分给文字和背景。先标明每种颜色的用途，再分别检查按钮文字、状态提示和图表要表达的信息；色票是候选清单，不是无障碍合格证明。

先从图片提取候选色，不把结果当成最终配色

色票撷取器会在浏览器里读取图片，选择 5、8 或 12 个候选色，并给出 HEX 与 RGB。当前组件会缩小取样图片、忽略接近透明的像素，再用 k-means 对不透明像素分组；初始化带有随机性，所以同一张复杂图片重复分析时，结果和排序可能有小幅差异。

例如一家餐饮门店想从海报延伸点餐页配色。先保留主红、米白和深棕，但不要认定红底白字一定清楚。把颜色写成角色清单：深棕用于正文，米白用于背景，主红用于主要按钮，浅红只用于提示背景，另外保留一组图表色。

工具结果卡为了展示 HEX，会按一个简单亮度阈值自动选择黑字或白字。这只是结果卡自身的显示策略，不是 WCAG 对比度计算。工具也不会替图片改色、生成完整设计系统、判断焦点状态或认证整个页面符合无障碍要求。

按钮上最先检查的是文字与按钮背景。根据 W3C 对 WCAG 2.2 对比度最低要求的说明，普通文字至少需要 4.5:1，大号文字至少需要 3:1，而且 4.499:1 不能四舍五入成通过。

接着检查用户怎样识别按钮和当前状态。若边框、焦点环或选中标记是识别控件所必需的视觉信息，非文本对比说明要求它与相邻颜色达到 3:1。不要只测默认按钮，还要逐项查看悬停、键盘焦点、按下和错误状态。

可以用颜色选择器准确复制候选色的 HEX 或 RGB，避免从截图猜数值，但它不会计算两种颜色的 WCAG 比值。把前景色和背景色交给可信的对比度检查器，再记录实际比值、文字大小和使用场景；只写“深色配浅色”无法复核。

错误、警告和成功提示需要文字或图标承担含义，颜色只作为辅助。例如订单页可以显示“支付失败”文字并配错误图标，而不是只把圆点从绿色变成红色。这样即使用户分不清色相，仍能知道发生了什么以及下一步该做什么。

检查提示时，把文字、图标、边框和背景拆开。浅红背景上的红色小字可能对比不足；边框若是识别错误输入框的唯一线索，也要核对相邻背景。若颜色代表严重程度，再加上“需立即处理”等明确标签。

还要在真实文案下测试。“失败”和两行退款说明的换行不同；把最长提示放进组件，再用键盘移动焦点，确认焦点环没有被背景吃掉。

折线、柱形和饼图不能只因为颜色彼此不同就算清楚。W3C 的非文本对比说明把理解图表所需的线条和形状视为关键图形对象；折线相对背景需要足够对比，饼图切片若必须靠边界辨认，也需要让边界可见。

一张销售趋势图可以同时使用深浅不同的线、实线与虚线、不同数据点形状和直接标签。即使两条线在灰度下接近，用户仍能凭线型与标签区分。饼图若附有清晰的分类名和数值，读者就不必只靠相邻色块判断比例。

背景是渐变时，不能只取渐变两端的平均效果。用 CSS 渐变生成器可以生成样式代码，但它不是对比度检查器；文字跨过多个背景位置时，应在最不利的位置逐一测量，或为文字增加稳定的纯色底层。

先保存原图与一份色票记录，再在目标页面中检查真实组件。每个颜色都应有名称、HEX、用途和搭配对象，不能只保留一排色块。

这套检查只能覆盖视觉配色的一部分。页面是否整体符合 WCAG，还涉及键盘操作、语义、焦点顺序、替代文本和其他要求；配色工具不能给出整站合规结论。

结果卡只用简单亮度阈值选择显示颜色，没有计算 WCAG 对比度，也没有考虑实际字号、字重和状态。请把真实前景色与背景色放进对比度检查器核对。

它满足 WCAG 2.2 AA 普通文字的最低对比检查，但页面还要验证键盘焦点、语义、缩放和其他要求。最低比值不是整个产品的合格证。

色相差异对部分用户并不稳定，而且颜色可能在低质量屏幕、投影或打印中改变。文字、图标和形状能提供不依赖颜色的判断依据。

要看哪些边界和图形是理解数据所必需的。关键线条需要相对背景可见；若分类和值已有清晰标签，可以减少对色块边界的依赖，但仍要人工检查整体可读性。

不会。色票撷取器只在浏览器里分析图片并列出候选 HEX/RGB，不会编辑来源图片、替换页面样式或自动证明无障碍合规。