如何在不安裝任何工具的情況下稽核色彩對比

色彩對比稽核常被視為一項專門的無障礙工作：打開設計檔、安裝外掛、匯出螢幕截圖、產生報告，然後為品牌色爭論。這些做法可能有用，但不應該是大多數團隊的起點。

對於正式上線的網站，最快且可靠的稽核通常就在你已經開著的瀏覽器中完成。現代瀏覽器 DevTools 可以檢查計算後的色彩、顯示對比率、揭露狀態樣式，並協助你測試自動化報告容易漏掉的棘手案例。

本指南假設你不安裝任何東西。沒有瀏覽器擴充功能。沒有設計外掛。沒有付費稽核套件。只有頁面、瀏覽器，以及一套簡單方法。

你實際需要的對比規則

對大多數網頁工作而言，WCAG 對比主要可歸納為幾個門檻：

• 一般文字： 與背景之間至少要有 4.5:1 的對比。
• 大型文字： 至少 3:1。WCAG 將其定義為約 24 CSS pixels，若為粗體則約 18.66 CSS pixels。
• UI 元件與圖形物件： 對於理解介面所需的有意義邊界、圖示、狀態與圖表部分，至少 3:1。
• 增強對比： 若你的目標高於基準，一般文字為 7:1，大型文字為 4.5:1。

有些例外，例如非啟用控制項、裝飾性元素與標誌。請謹慎使用這些例外。「這是品牌的一部分」不是例外；它是一項設計限制。

也請記得，對比只是可存取色彩使用的一部分。如果紅色錯誤狀態有足夠對比，但沒有文字、圖示標籤或程式化提示，對於無法區分紅色與相近顏色的使用者而言，仍可能造成失敗。

從渲染後的頁面開始，而不是設計檔

設計檔很有用，但它們不包含所有真實世界變因：CSS 覆寫、透明度、hover 狀態、瀏覽器字型渲染、使用者縮放、深色模式、繼承樣式、CMS 內容，以及行銷嵌入內容。

請稽核使用者實際收到的頁面。

在目前版本的桌面瀏覽器中開啟頁面。Chrome、Edge、Firefox 和 Safari 都有實用的檢查工具。確切標籤會有所不同，但流程相同：

1. 在文字或 UI 元素上按右鍵。
2. 選擇 Inspect。
3. 找出計算後的 color 與 background-color。
4. 使用瀏覽器的色票或無障礙面板讀取對比率。
5. 記錄通過、失敗與不確定項目。

在 Chromium-based 瀏覽器中，色彩選擇器通常會顯示對比率，以及文字的 WCAG 通過／失敗指引。Firefox DevTools 也會提供無障礙資訊與色彩工具。Safari 的 Web Inspector 可以顯示計算後樣式與無障礙資訊，雖然流程略有不同。

重點不是特定瀏覽器。重點是讀取計算後結果，而不是某人以為該元件使用的值。

先建立一份小型稽核清單

不要隨機檢查文字直到疲乏為止。先建立一份簡短的模式清單：

• 主頁面背景上的內文。
• 弱化文字、說明文字、中繼資料與 placeholder。
• 一般、hover、visited 與 focus 狀態的連結。
• 主要、次要與破壞性按鈕。
• 表單標籤、輔助文字、錯誤與成功訊息。
• 導覽項目、麵包屑與分頁。
• 卡片、徽章、膠囊標籤與標籤。
• 傳達意義的圖示。
• 圖表、地圖、進度列與狀態色。
• 圖片、影片、漸層或半透明疊加層上的文字。

這足以找出典型網站中的多數問題。它也能讓稽核綁定到元件，而不是一次性的像素。

如果你的稽核包含按鈕，請將對比檢查與 our accessible web buttons checklist 中的基礎項目一起檢視。按鈕對比問題經常與缺少焦點狀態、標籤不清楚或鍵盤行為損壞同時出現。

在 DevTools 中檢查文字對比

對於純色背景上的一般文字，瀏覽器通常可以替你計算對比。

檢查元素並尋找 color 屬性。從色票開啟色彩選擇器。如果瀏覽器能判斷背景，就會顯示對比率。有些工具也會在色彩選擇器中畫出一條線，顯示該色彩在哪裡會通過 3:1、4.5:1 或 7:1。

當瀏覽器回報失敗時，在你能證明相反之前，請先相信它。當它回報通過時，仍要運用判斷。細小纖細的字體、品質較差的顯示器、重度反鋸齒與繁忙背景，都可能讓技術上通過的文字看起來偏弱。

一項實務規則：如果內文只是勉強以 4.55:1 通過，不要急著慶祝。給它更多餘裕。對比要求是最低標準，不是理想目標。

排版也很重要。更大、更清楚的字體系統，會在你調整色彩之前就先降低閱讀負擔。如果頁面即使通過對比仍難以閱讀，請用更廣泛的可讀性角度重新檢視行長、尺寸、字重與間距，例如 this practical guide to readable type。

檢查真實背景，包括透明度

許多對比錯誤發生的原因，是可見背景並不是宣告的背景。

常見陷阱包括：

• 半透明卡片中的文字。
• 文字位於套用 opacity 的父層上。
• 使用 rgba() 或 color-mix() 的疊加層。
• 標題後方的漸層。
• 文字區域後方會變化的背景圖片。
• 在深色模式中會改變的主題變數。

如果 DevTools 無法有把握地計算對比，請手動識別渲染後的前景與背景色。使用計算後樣式面板、暫時停用圖層，或在瀏覽器支援時使用內建色彩選擇器取樣可見色彩。

對於圖片上的文字，不要取樣圖片中最理想的部分。請取樣文字後方最可能不利的區域。如果圖片會透過 CMS 上傳、輪播或響應式裁切而改變，這就不是穩定的對比系統。請加入可靠的疊加層、文字陰影、實色容器或漸層處理，確保不論圖片為何都能保護文字。

好的圖片疊加系統是平淡的：一致的疊加強度、可預測的裁切區域，即使是明亮照片也有足夠對比。平淡沒有問題。使用者只是想閱讀。

不要忘記狀態

靜態螢幕截圖會漏掉許多對比失敗。請直接在瀏覽器中稽核互動狀態。

在 DevTools 中，強制套用 pseudo-classes，例如：

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

接著再次檢查計算後色彩。

焦點指示器值得特別留意。WCAG 2.2 強化了對焦點外觀的期待，而淺灰卡片上的淡藍色外框仍是常見失敗。焦點指示器需要相對於相鄰色彩有足夠對比，並且有足夠面積可被注意到。

對於 disabled 控制項，WCAG 對比規則對非啟用元件有例外。這不表示 disabled 控制項預設就應該難以辨識。如果 disabled 狀態承載有用資訊，請讓它可讀。如果沒有，請考慮它是否根本應該存在。

使用 Lighthouse，但不要把判斷外包給它

Lighthouse 等瀏覽器稽核可以快速捕捉某些對比失敗。如果你的瀏覽器提供內建稽核，請執行它，然後把結果視為起點。

自動化檢查擅長找出具有明顯計算後對比失敗的文字節點。它們較不擅長：

• 嵌入圖片中的文字。
• Canvas-rendered 標籤。
• SVG 邊界案例。
• 只在 hover 時出現的失敗。
• 焦點指示器品質。
• 色彩關係承載意義的圖表。
• 隱藏在驗證、選單或表單步驟後方的元件。

如果報告全綠，你仍需要檢查具代表性的元件。如果報告出現紅色，請避免恐慌，並依使用者影響程度分流處理失敗。這項原則也普遍適用於效能與無障礙報告：把工具輸出讀成證據，而不是判決。我們在 our guide to reading a Lighthouse report without panicking 中也使用這種心態，這裡同樣適用。

也要稽核非文字對比

文字獲得最多關注，但 WCAG 也涵蓋理解或操作介面所需的非文字內容。

至少檢查以下情況：

• 輸入框邊框相對於頁面背景。
• Checkbox 與 radio 外框。
• Toggle 狀態。
• 純圖示按鈕。
• 錯誤圖示與警告符號。
• 圖表線條、長條與標籤。
• 進度指示器。
• 已選取分頁或作用中導覽指示器。

目標通常是相對於相鄰色彩達到 3:1。例如，白色背景上的淺灰輸入框邊框可能幾乎看不見。具有五條粉彩線的圖表可能看起來優雅，卻仍然不可用。

對圖表而言，光有對比仍不足夠。請使用標籤、圖樣、線條樣式、直接註解或間距，讓資訊不只依賴色彩。這能幫助色盲使用者、低視能使用者、在眩光下觀看的人，以及任何在文件中閱讀螢幕截圖的人。

以開發者可使用的格式記錄發現

有用的對比稽核不會只說「有些灰色不合格」。它會指出元件、狀態、目前值、預期門檻與建議修正。

精簡格式很有效：

| Component | State | Foreground | Background | Ratio | Target | Result | Suggested fix | |---|---:|---:|---:|---:|---:|---|---| | 卡片中繼資料 | Default | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Fail | 使用 --color-text-muted-strong | | 主要按鈕 | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Pass | 保留 | | 輸入框邊框 | Default | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Fail | 加深邊框 token |

如果網站有設計 token，請將修正綁定到 token。不要在真正問題是一個薄弱 token 時，修補二十個個別元件。

讓修正略高於最低標準

對比失敗常常很容易被修得很糟。團隊把顏色微調到檢查器顯示 4.51:1，然後繼續下一項。這不會為字型渲染、透明度、瀏覽器差異、主題化、圖片變異或未來品牌調整留下餘裕。

請偏好更舒適的目標：

• 內文：可行時接近 7:1。
• 弱化文字：如果它是真正內容，仍應高於 4.5:1。
• UI 邊框與圖示：明顯高於 3:1。
• 圖片上的文字：使用受控疊加層，而不是逐張圖片猜測。

網頁會在廉價筆電、昏暗手機、明亮人行道、帶色偏的螢幕與老化顯示器上被觀看。最低合規不等於舒適閱讀。

<!-- tool-cta:start -->

💡 試試這個： 檢查從 DevTools 擷取的對比度配對時，Color Converter 可協助在 hex、RGB 和 HSL 之間轉換，讓這些值與你的稽核筆記一致。

<!-- tool-cta:end -->

不需安裝工具的對比稽核清單

當你需要快速但可信的稽核時，請使用以下順序：

1. 在現代瀏覽器中開啟正式環境頁面。
2. 列出主要文字、UI 與狀態模式。
3. 在 DevTools 中檢查計算後的前景與背景色。
4. 使用內建色彩選擇器或無障礙面板讀取對比。
5. 強制 hover、focus、active、visited 與 invalid 狀態。
6. 針對最可能不利的背景，檢查圖片與漸層上的文字。
7. 依 3:1 要求檢查非文字 UI 部分。
8. 執行內建自動化稽核作為安全網，而不是完整稽核。
9. 依元件與 token 記錄失敗。
10. 修正時保留餘裕，而不是剛好跨過門檻。

這已足以在不為技術堆疊加入另一個工具的情況下，捕捉大多數對比問題。更進階的稽核仍有其位置，特別是大型設計系統、受監管產品或複雜資料視覺化。但對許多網站來說，瀏覽器已經提供你所需的證據。困難之處在於是否能夠足夠有系統地使用它。