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

English version: [https://accesserty.com/en/ai/guides/color-contrast-checks-before-release.md](https://accesserty.com/en/ai/guides/color-contrast-checks-before-release.md)

Page version: [https://accesserty.com/guides/color-contrast-checks-before-release/](https://accesserty.com/guides/color-contrast-checks-before-release/)

Last updated: 2026-09-30

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

## 重點整理

- 在實際頁面檢查文字、焦點、錯誤與選取狀態；真正停用的控制項有對比例外，不能與可操作狀態套用相同判斷。
- 自動化掃描可以找出部分文字對比問題，但圖示、邊框、焦點提示、圖片背景與互動狀態仍需要人工確認。
- 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 狀態。
- 檢查連結、表單錯誤、焦點提示、圖示、邊框與圖表是否只靠顏色傳達資訊。
- 記錄頁面、元件與狀態、前景／背景、字級／字重、未四捨五入的對比值、適用準則及判斷；未量測的狀態記為未測，不把掃描零發現當成通過。修正後回到同一狀態，連同其他主題與背景重測。

## 接下來可以做什麼

- [網站無障礙修復計畫](<https://accesserty.com/guides/web-accessibility-remediation-plan/>) — 依使用者任務、影響範圍、負責角色、修復層級與回測方式整理下一步。

- [PDF 無障礙結構訊號檢查](<https://accesserty.com/guides/pdf-accessibility-structure-checks/>) — 檢查語言、標籤、圖片、連結、表單、書籤與頁面一致性等線索。

## 延伸閱讀

- [Accesserty DevCheck](<https://accesserty.com/devcheck/>) — 用瀏覽器內工具檢查本機、測試站、登入後頁面與互動狀態。

- [看懂 WCAG 檢測結果](<https://accesserty.com/wcag-compliance-tool/>)

- [色彩對比術語頁](<https://accesserty.com/glossary/color-contrast/>)

- [自動化檢測限制指南](<https://accesserty.com/guides/automated-accessibility-checks-limits/>)

- [UI Kit](<https://accesserty.com/uikit/>)

- [W3C Contrast Minimum](<https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum>)

- [W3C Non-text Contrast](<https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast>)

- [W3C Use of Color](<https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html>)

- [焦點提示：AA 與 AAA 的差別](<https://accesserty.com/glossary/focus-indicator/>)

- [網站無障礙檢測工具](<https://accesserty.com/web-accessibility-checker/>) — 針對實際頁面、登入後狀態與互動狀態做初步無障礙檢查。

- [無障礙實作與維護指南](<https://accesserty.com/guides/>) — 依實際任務瀏覽公開訊號、上線前檢查、上線後維護與標準限制指南。