跳至中央內容區塊 :::
:::

色彩對比檢查：Release 前不只看主色

色彩對比不是只檢查品牌主色。Release 前應確認文字、連結、錯誤訊息、焦點提示、按鈕狀態、圖示與元件邊界在真實畫面中是否清楚。


重點摘要

  • 對比檢查應放在真實頁面狀態中看，包含 hover、focus、錯誤、disabled、深色或淺色背景。
  • 自動化掃描可以找出部分文字對比問題，但圖示、邊框、焦點提示、圖片背景與互動狀態仍需要人工確認。
  • DevCheck 可以協助在目前頁面執行 axe 掃描與視覺情境模擬；它不是專用取色或對比計算器。

先從真實狀態開始，不要只看設計稿主色

很多對比問題不是出現在品牌主色，而是出現在實際流程裡：表單錯誤變紅、按鈕被 hover、欄位取得焦點、連結被放在圖片或卡片背景上、元件進入 disabled 狀態，或深色模式與淺色模式切換後。

所以 release 前的檢查不應只問「這兩個色碼有沒有過」。更實際的問題是：使用者在目前這個畫面狀態下，能不能看清文字、辨識元件、理解錯誤與找到焦點位置。

哪些項目要一起看？

WCAG 2.2 對文字與圖片文字有 Contrast (Minimum)；對元件與必要圖形有 Non-text Contrast；也要求資訊不能只靠顏色傳達。這代表對比檢查不只是一個文字比例問題。

  • 文字與背景：一般文字、說明文字、placeholder、hover/focus 時出現的文字。
  • 連結與互動文字：連結不能只靠顏色和周圍文字區分，必要時要有底線、圖示或其他可見提示。
  • 元件與狀態：按鈕、輸入框、checkbox、radio、switch、selected、error、focus 等狀態。
  • 圖示與邊界：圖示、控制項邊框、焦點框、圖表中必要的線條或區塊。
  • 背景變化：圖片背景、漸層、卡片、深色模式、淺色模式與品牌主視覺。

自動化掃描能幫忙，但不能涵蓋所有狀態

axe-core 這類自動化掃描可以抓出部分可被程式判斷的對比問題，特別是目前 DOM 狀態裡的文字與背景。但它不一定看得到每個 hover 狀態、被動態打開的選單、不同圖片背景、客製圖示含義，或設計者用顏色傳達的業務狀態。

因此比較可靠的流程是：先用掃描工具找出明顯問題，再由設計、QA 與工程在真實畫面中檢查關鍵狀態。需要精確 ratio 時，仍應使用專門的取色或對比計算工具確認。

DevCheck 與 UI Kit 在這裡的角色

DevCheck 可以在目前瀏覽器頁面執行 axe 掃描，也可以用色覺、文字間距、視野缺損、老花、近視與白內障等模擬協助檢查可讀性。這些是初步檢查與討論線索，不是完整人工檢測或法律符合性保證。

UI Kit 的 CSS variables 和元件樣式可以讓團隊有一致的調整入口，但 token 本身不會自動保證對比。真正需要確認的是元件在實際內容、實際背景與實際狀態下是否仍然清楚。

一個可執行的 release 前檢查順序

把色彩對比放進 release checklist 時，不需要一開始就建立大型流程。先針對主要任務頁面建立穩定順序即可。

  • 在本機或測試站開啟主要流程頁面。
  • 執行自動化掃描，先處理明顯的文字對比問題。
  • 手動切換 hover、focus、error、selected、disabled、loading、empty 與 dark/light 狀態。
  • 檢查連結、表單錯誤、焦點提示、圖示、邊框與圖表是否只靠顏色傳達資訊。
  • 需要數值證明時，用專門對比工具取色並記錄 ratio，再修正與重測。

相關頁面