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

色彩對比怎麼檢查？文字、焦點與錯誤狀態

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

最後更新:

重點摘要

  • 在實際頁面檢查文字、焦點、錯誤與選取狀態；真正停用的控制項有對比例外，不能與可操作狀態套用相同判斷。
  • 自動化掃描可以找出部分文字對比問題，但圖示、邊框、焦點提示、圖片背景與互動狀態仍需要人工確認。
  • DevCheck 可以協助在目前頁面執行 axe 掃描與視覺情境模擬；它不是專用取色或對比計算器。

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

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

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

哪些項目要一起看？

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

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

先選對判斷規則，再量色彩

WCAG 2.2 AA 的 1.4.3 對一般文字要求至少 4.5:1；大字至少 3:1。大字的門檻是 18 pt（24 CSS px），或 14 pt 粗體（約 18.67 CSS px）；東亞字型需依規範的大字定義確認等效尺寸。placeholder 和錯誤文字不因為是輔助資訊就免測。不要將未達門檻的數值四捨五入成通過。

1.4.11 的 3:1 用於辨識控制項、狀態或必要圖形所需的視覺資訊，與其相鄰顏色比較，不是要求每條裝飾邊線都達標。未經作者修改外觀的瀏覽器原生控制項有例外。

真正不可操作的停用控制項在上述兩項準則有例外；不是只要塗灰就算停用。仍建議讓人理解它是什麼、為何不能操作，這是可用性建議，不能把較淡的停用按鈕直接記為對比失敗。

一個可重算的文字例子

假設一般大小的說明文字為不透明 #777777，背景是純白 #FFFFFF，沒有圖片、漸層或其他疊層。計算結果約 4.478:1，未達 4.5:1；改為 #666666 後約 5.742:1。這是色碼計算例子，不是本站實測結果，也不代表整頁通過。

實作時先在瀏覽器確認套用後的字色、字級、字重及背景，再用對比工具計算。透明度、圖片或漸層會改變文字底下的實際背景；檢查文字可能覆蓋的最不利位置，不要只量背景的一個平均色。不要把反鋸齒後的字緣像素當成 CSS 字色。

把數值放回焦點、錯誤與選取狀態

焦點：用鍵盤移到送出按鈕，檢查自訂焦點框與相鄰背景，不是拿 focus 色和 hover 色相比。除了對比，還要確認焦點可見、控制項沒有被固定頁首完全遮住。AA 的 2.4.7、2.4.11 與 AAA 的 2.4.13 不同；後者另有面積及同一位置像素前後對比要求，不能把「一定要 2 px 外框」當成 AA 通則。

錯誤：在授權測試環境以測試資料觸發必填提示，不送出正式訂單或信件。檢查錯誤文字對背景的對比，也確認有「請填寫電子信箱」之類的文字，而不只是把邊框變紅。

選取：切換 checkbox、radio 或頁籤，分別檢查每個狀態與背景。使用勾選記號、形狀或清楚文字協助辨識，不只把同一圖案從紅色換成綠色。

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

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

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

DevCheck 與 UI Kit 在這裡的角色

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

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

一個可執行的上線前檢查順序

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

  • 在本機或測試站開啟主要流程頁面。
  • 執行自動化掃描，先處理明顯的文字對比問題。
  • 手動切換 hover、focus、error、selected、disabled、loading、empty 與 dark/light 狀態。
  • 檢查連結、表單錯誤、焦點提示、圖示、邊框與圖表是否只靠顏色傳達資訊。
  • 記錄頁面、元件與狀態、前景／背景、字級／字重、未四捨五入的對比值、適用準則及判斷；未量測的狀態記為未測，不把掃描零發現當成通過。修正後回到同一狀態，連同其他主題與背景重測。

下一步檢查

依頁面內容選擇適用的下一步。有 PDF 才需要另外檢查文件；完成修正後仍要重測。

  1. 把發現整理成修復計畫

    網站無障礙修復計畫

    依使用者任務、影響範圍、負責角色、修復層級與回測方式整理下一步。

  2. 如果有 PDF，檢查結構訊號

    PDF 無障礙結構訊號檢查

    檢查語言、標籤、圖片、連結、表單、書籤與頁面一致性等線索。

相關頁面