深色模板上的表單框線很好看，填錯之後卻只多了一行暗紅字。手機亮度低一點，提示幾乎消失；換成綠色也未必清楚。調整回饋時，先讓文字與符號在真正背景上可辨，再用顏色補充狀態。
這篇處理深色背景的錯誤、成功與焦點配色，不重新設計詢價欄位，也不把前端提示當作郵件已送達。你可以先挑一個現有欄位，依序檢視一般、錯誤、修正與鍵盤焦點四個狀態。
紅與綠都要配文字
只改框線顏色，訪客還得猜「紅色代表哪個地方錯了」。錯誤旁寫出原因，例如「請填有效的Email，例如 [email protected]」。成功或完成狀態則寫真實結果，不能因輸入格式正確，就顯示「已收到詢問」。
若要加符號，可搭配驚嘆號與勾號；它們提供另一種辨識線索，但不取代文字。符號只是重複文字的狀態時，可以對輔助科技設aria-hidden，避免一句提示先讀一次符號名稱，再讀相同意思。
也別只把錯誤和成功放在圖例裡，讓訪客回頭對照顏色。提示應放在對應欄位附近，讓他知道要改哪裡。多欄錯誤需要摘要時，摘要與欄位旁說明要一致，不要一邊寫必填、一邊寫格式錯誤。
先用真正的文字背景算對比
本文示例的面板是 #20242c，錯誤文字採 #ffb4ab，成功文字採 #9de1c4。不要只拿它們與網頁最外層背景比較；提示實際位於面板上，就用面板色計算。
這兩組文字對面板的對比分別約9.16:1與10.37:1。對照較暗的 #7b4444 和 #38634f，同一背景只有約2.04:1與2.27:1；即使一個是紅、一個是綠，都不能只憑顏色名稱判斷一般文字夠不夠清楚。
WCAG的一般文字最低對比要求為4.5:1，大字有3:1的條件。多數表單提示是一般小字，因此先按4.5:1檢查，比套用大字例外更直接。剛好算到門檻時也要注意數值，不要把4.49四捨五入後當成合格。
.dark-form {
background: #20242c;
color: #f3f4f6;
}
.dark-form .feedback-error { color: #ffb4ab; }
.dark-form .feedback-success { color: #9de1c4; }這是此背景的示例配色，不能直接當全站色票。面板若有透明度、漸層或圖片，實際背景可能不是你在CSS寫的那個色碼。先查computed顏色與下層背景，再計算真正的組合；不同位置都需要看。
對比計算也不代替實際閱讀。字太細、尺寸太小或擠在密集欄位裡，仍可能難讀。先保留適當字級與行距，再改善配色，不要因為錯誤訊息太長，就把它縮成很小的灰字。
框線與焦點，別只比正常文字
訪客需要辨識輸入框和目前焦點。與辨識控制項或狀態有關的非文字資訊，依WCAG相關要求需要足夠相鄰對比；例如自行設計的必要框線和焦點指示，不能只看文字已經清楚就略過。
示例輸入框的邊界用較亮灰色，鍵盤焦點用淡藍外框。錯誤狀態可以保留珊瑚色提示，但焦點仍有自己的可見外框，避免一聚焦就把錯誤文字消掉，或用同一條紅線同時表示兩件事。
.dark-form input {
background: #15181e;
color: #f3f4f6;
border: 2px solid #8b95a7;
}
.dark-form input:focus-visible,
.dark-form button:focus-visible {
outline: 3px solid #b9d0ff;
outline-offset: 5px;
}不要直接移除outline，只留微弱的陰影。外框可能碰到面板邊緣或被overflow裁掉，停在第一個與最後一個欄位各看一次。發生錯誤時，也試鍵盤回到該欄，確認焦點與錯誤能同時看懂。
讓文字回饋連到對應欄位
欄位名稱仍用label，說明與回饋可由aria-describedby關聯。錯誤時設定aria-invalid，修正成功後把狀態更新回來。顏色與屬性應描述同一件事，別畫面已經顯示成功，屬性仍停在invalid。
<label for="contact-email">聯絡Email</label>
<input id="contact-email" type="email"
aria-describedby="email-feedback" aria-invalid="true">
<p id="email-feedback" class="feedback-error">
<span aria-hidden="true">!</span>
請填有效的Email，例如 [email protected]。
</p>這段是錯誤狀態的HTML。實際驗證邏輯要根據表單功能更新屬性、文字與class；不要一直把aria-invalid寫死為true。若提示會動態改變，按實際互動安排通知方式，並用支援的輔助工具確認，不要為了讓它被聽見而讓整頁反覆播報。
成功狀態也要照實寫
在本文示例裡，按鈕只檢查Email格式，正確後顯示「格式可用，可以繼續填寫需求」。畫面用綠色與勾號輔助說明，沒有宣稱詢問已送出。接上正式表單後，要等真正處理結果再顯示對應訊息。
發生提交失敗時，保留輸入內容，說明能否重試和是否需要其他聯絡方法。顏色設計可以讓失敗更容易看見，但無法替你修好後台接收或寄信功能。若要重新整理詢價欄位與送出回饋，可另看詢價表單說明與回饋。
最後用真實狀態看一次
不要只在設計稿裡擺紅字和綠字。開啟自己的測試頁面，先留白、填錯、修正，再用Tab經過輸入框與按鈕；觀察提示顏色、文字、屬性與焦點是否一起更新。把系統強制顏色或深淺主題切換也列入需要支援的環境。
若模板有透明面板或背景照片，挑最亮和最暗的位置檢視；不要只選一個對比最好的角落。視窗變窄後，提示可能換成兩行，也要確認沒有被固定高度截斷。文字放大時，錯誤原因和按鈕仍應可讀。
改動先限於這份表單的class，保留原色碼與樣式。別把全站所有紅字換成同一淺紅，因為其他區塊可能是白底。上線前確認實際DOM和不同狀態，必要時只回復這一份表單的配色。
文字和顏色的幾項對比合適，只表示這些組合有明確依據。完整無障礙還包含鍵盤、結構、名稱、錯誤關聯與輔助科技行為，不能憑這張表單截圖宣稱全站符合WCAG。
按鈕文字也要另外算。示例的淡藍按鈕用深色文字，不能直接沿用面板的白字；相同白字放在淺色按鈕上，結果與深色面板不同。錯誤訊息內若有可點連結，保持連結可辨識與可聚焦，別把所有字都染成錯誤色後失去入口。
文字提示可以靠圖示補充，但圖示本身若承擔狀態資訊，也要檢查與周圍背景的對比。把符號藏在陰影裡、縮得很細，或只在滑鼠移入才出現，都不能讓訪客穩定辨識。先讓文字與狀態保持可見，再決定裝飾要加到哪裡。
評論0