網站文字看不清楚怎麼改？逐項檢查文字與互動狀態對比
從主要文字組合、按鈕狀態與低對比畫面開始，建立可重複的檢查、修正與上線抽查流程。
網頁上有文字，不代表使用者能快速讀清楚。真正要盤點的是每組字與背景、控制項輪廓與周圍，以及不同互動狀態下的視覺差異。不要只看一張設計稿或品牌色預覽；沿著常見任務，把標題、內文、輔助文字、按鈕、欄位、錯誤訊息和圖示逐一檢查。本文從清單、狀態、低對比例子、非顏色提示、責任紀錄到上線抽查，整理成可重複操作的流程。檢查目的不是挑一組好看的配色，而是確認重要內容和控制提示在日常使用條件下足夠分明。
整理主要文字組合
先選一條使用者常走的任務路徑，例如閱讀方案、填表送出或查詢訂單，再沿途列出所有文字與圖示所在的底色。不要只記「深綠配白」這類大方向，應逐一記下頁面區塊、元件名稱、文字用途、前景色、實際背景，以及是否有透明度、圖片或漸層。內文、標題、欄位標籤、提示、placeholder、連結、價格、小字、圖示和必填符號都可能使用不同組合；同一顆按鈕的文字、底色、邊框也要分開看。最簡單的盤點表可包含位置、內容用途、前景／背景、字級粗細、元件狀態、截圖與待辦。比如「結帳頁／欄位提示／灰字／淡底／預設」，比「灰色看不清」更容易重現。若文字壓在照片上，背景不是單一色碼，就要標出圖片與取樣位置。品牌色可以當起點，不能直接當成通過依據；不同字級、粗細和底色都需重測。也要標出哪些圖示承載功能，哪些純裝飾，免得只查文字而漏掉搜尋、展開或勾選符號。完成後先按出現頻率和任務重要性排序，優先看付款、送出、錯誤處理等關鍵流程，再逐步擴及其他頁面。這份清單描述的是實際畫面，不是設計稿中的理想設定。盤點時可以先從文字最密集、背景最常變化的頁面開始，再比對共用元件是否出現在其他路徑。若同一色票被用在白底卡片、深色頁尾與照片遮罩上，請拆成多筆組合，而不是以色票名稱合併。標題加粗不會自動修好底色過近，字級與字重只是決定採用哪個文字門檻的條件之一。紀錄中保留色碼和畫面截圖，工程調整後才能重複相同測量。同一段文字若跨越卡片或固定頁尾，也須按背景拆開。
檢查按鈕不同狀態
按鈕不是一種畫面，而是一組會隨操作改變的狀態。至少檢查預設、游標移入、鍵盤焦點、按下、已選取、載入中、成功、錯誤與停用；若元件沒有某個狀態就註明不適用，不要憑想像補畫面。每一狀態都看文字與底色、邊框與周圍、圖示與填色是否清楚，焦點框是否被裁切或被其他區塊遮住。可用鍵盤逐個切換焦點，再按下 Enter 或空白鍵，確認視覺提示跟實際操作一致；觸控頁面則檢查按下後是否短暫顯示足以辨認的回饋。WCAG 2.2 對辨認元件及其狀態所需的非文字視覺資訊，列出與相鄰顏色至少 3:1 的條件；可參考 W3C 的非文字對比說明，但不要把這個數字誤套成所有文字的門檻。停用狀態在規範中有例外，也不代表使用者就容易理解；仍應以清楚標籤、說明原因或可辨識的外框降低誤判。最後逐個記錄問題是出在字色、底色、焦點樣式還是狀態沒有呈現，避免只說「按鈕不清楚」而無法交辦。不要只截取變色後的靜態圖片；實際操作時要看焦點是否從上一個元件移到下一個，錯誤訊息是否在送出後才出現，載入狀態是否把原本標籤換成旋轉圖示。若按鈕透過透明度變淡，背景透出後的對比也會改變；若用陰影或細線提示輪廓，確認它沒有在手機縮放或深色背景上消失。對每個狀態可分別標記「字可讀」「控制可辨」「狀態可認」，避免有一項看似正常就整組判定通過。手機版也要確認焦點提示不被固定導覽遮住，別只看桌面畫面；重測前先將視窗縮窄。滑鼠移入不等於鍵盤焦點，請分開留存畫面。
測試低對比示例
低對比常藏在看似精緻的淡色文字、小型次要標籤和照片背景裡。先用對比檢查工具輸入實際前景色與底色，不要只靠螢幕觀感；一般文字至少 4.5:1，大型文字至少 3:1，是 WCAG 2.2 AA 的文字對比門檻，細節可看 W3C 的文字對比說明。比例要用畫面實際使用的顏色計算，不能先把結果四捨五入，也不要把「大字較寬鬆」延伸成所有粗體或標題都適用。以下是假設的表單例子：送出按鈕旁的淡灰提示在白底上不易讀，工具測得未達該文字類型的門檻；先加深字色，再重測正常、焦點與錯誤畫面，確認其他背景也能讀。如果提示覆蓋在照片或漸層上，逐處檢查文字後方最亮與最暗的位置；必要時加穩定底色或遮罩，不要只挑看起來最好的那一小塊。也要核對透明度、疊色、陰影和實際字重，因為素材或樣式改動都可能改變結果。修完先回到同一畫面、同一狀態重測，再檢查相鄰文字與邊界，確認補救沒有製造新的難讀區。測量時要取字實際覆蓋的底色；若文字下方有半透明遮罩，先確認合成後的顏色，而不是直接拿 CSS 裡互不相鄰的兩個色碼猜結果。背景影像會隨裁切移動，因此桌機中心取樣不能代替手機版邊緣取樣。若一組文字跨過亮暗區，處理方式可改為固定底板、加深遮罩或移動文字位置，完成後再從最不利位置重測。為了避免修一處壞另一處，更新主色後也要查同色系的連結、標籤和按鈕，確認各自仍符合文字或元件用途的條件。每次只改一個主要因素，方便看清改善來源。不要拿鄰近空白區的色碼代替字後方底色。
區分顏色與其他提示
顏色可以加強訊息，卻不該是唯一線索。連結除了換色，可加底線或清楚的字重差異；目前所在的分頁可配合底線、外框或標記；核取狀態要有勾號或形狀變化，錯誤也應有文字說明，不要只把欄位染紅。圖表若以不同色塊表示分類，可直接標註名稱、數值或圖例，並檢查灰階畫面中是否仍能分辨。設計檢查時，可把畫面轉成灰階或使用色覺模擬，找出只靠紅綠、藍紫色相區隔的訊息；這是找問題的輔助方法，不能取代對比計算或實際操作。圖示也要問「拿掉顏色後，使用者是否知道它可點、目前是否選取，以及接下來會發生什麼？」若答案是否定的，就補上文字、形狀、線條或位置提示。錯誤訊息應指出哪個欄位、發生什麼情況與可採取的下一步；成功訊息也要清楚標示完成，而不是只顯示綠色。需要回應的人不一定能辨別色相，也可能在低亮度螢幕、強光環境或列印內容中閱讀。把顏色和文字、圖形、位置搭配，才能讓狀態在不同情境下仍有意義；檢查時請同時看提示是否貼近所屬欄位，而非只核對色票。同一訊息若有多個呈現方式，語意應互相吻合：顏色變化、文字標示、圖示形狀與互動後的回饋不可彼此矛盾。像「已選取」可同時用勾選符號與清晰外框；如需辨認必填，可加文字或星號並在旁說明符號意義。重新檢查深色模式、列印樣式或瀏覽器自訂色彩時，重要標籤仍應出現，不能因底色被移除而融入背景。只要一個提示離開原本顏色便失去含義，就表示還要補上獨立線索。提示圖示若需解讀，附上可見文字或圖例。
記錄元件修正責任
修正若沒有負責人和驗收方式，很容易在設計稿、元件庫與頁面之間來回遺漏。每筆問題先留頁面網址或路徑、元件名稱、文字用途、前景與底色、狀態、重現步驟和截圖，再寫下使用者會遇到的影響，例如「焦點移到送出鍵時外框看不見，鍵盤操作的人難以確認位置」。接著指定一位修正負責人、優先順序、預計處理版本與複查人；這些欄位是團隊的工作紀錄，不是對外保證。修正方案要寫到可驗收，例如「將提示文字改為符合門檻的色組，保留原本底色，並在預設、焦點和錯誤狀態重測」，不要只寫「提升對比」。若問題來自共用按鈕或欄位，先確認元件負責人，再盤點哪些頁面共用它；如果只修單一頁，其他使用者仍可能看到舊樣式。驗收時沿用原始截圖和同一操作步驟，記錄實測色碼、對比結果、瀏覽器與版面條件，通過後標明日期與版本。未通過就保留原紀錄、補上新觀察，再交回負責人處理。內容、設計、前端與測試角色若分工不同，紀錄應明確指出誰提供文案、誰改樣式、誰確認頁面；跨角色交接才不會把「已處理」誤當成「已驗證」。問題如果反覆出現在同一種元件，應把共用樣式的修正列為根因，並列出受影響頁面供複查；臨時只在單頁加覆寫，可能讓後續維護更難追蹤。相反地，若只有某張圖片上的文字不清楚，則記錄素材和位置，避免無關的全站改色。每項待辦要有明確的完成定義，例如對比工具結果達到目標、鍵盤焦點可見、提示在實際尺寸可讀，並由不同於修改者的人重走一次任務。只改色票時，仍要確認文字與背景的實際搭配。
在真實頁面再次抽查
最後回到實際上線頁面抽查，因為設計稿不會呈現所有字型載入、圖片裁切、瀏覽器效果和動態狀態。選一條常用任務，從入口走到完成或錯誤回復，逐頁檢查內文、表單、按鈕、選取項目、提示和圖示；至少用桌機與手機版面看一次，並用鍵盤移動焦點。照片、卡片、彈窗、固定頁尾或驗證訊息出現時，背景可能已不同，要重新核對文字所在位置。把瀏覽器文字放大，確認內容沒有被截斷、按鈕標籤沒有溢出、焦點外框沒有被容器遮住；若頁面在放大後改變排版，也要檢查新背景組合。測試資料要避開真實客戶個資，可以用不具敏感性的示例輸入觸發必填、格式錯誤、送出中和成功提示。每修一項，就在同一瀏覽器、同一尺寸和同一狀態重做原步驟，保留前後截圖與結果；最後再換一個常見視窗大小，確認修正沒有只對單一截圖有效。現在先挑一頁與一個最常見任務，完成文字和狀態清單，再將負責人與複查步驟填上。若盤點牽涉到影響營運的工作流程，可到 ZhenheAI 首頁 描述目前卡點，作為討論下一步的起點。若抽查發現問題，回報必須帶頁面、視窗尺寸、操作步驟、當下狀態和截圖，才方便另一位同事重現。不要只在元件預覽確認：載入中的字可能被替換，錯誤提示可能擠壓欄位，固定導覽可能遮住焦點，這些都要在實際流程中查看。將已通過、已修正待複查、尚未修正分開記錄，避免把程式已合併或截圖已更新當成使用者畫面已驗收。下次複查時間也要記進清單。若首次抽查通過，仍要在共用元件版本更新後抽樣複查。