說清楚哪裏有錯及下一步
顧客提交表格失敗時，正面臨一個具體決定：網站拒絕了哪個答案、原因是甚麼、應改成甚麼。W3C 的「錯誤識別」準則要求自動偵測到輸入錯誤時，以文字指出出錯項目並描述問題。「錯誤建議」準則進一步要求，在已知修正方法時提供建議，除非這會損害內容的安全或用途。兩者相關，但要求並不完全相同。「資料有問題」沒有指出欄位；「無效數值」也沒有提供可用範圍或修正方法。若日期已不可預約，「到訪日期：請從日曆選擇仍可預約的日期」便較可執行。錯誤文案應根據真實驗證規則寫，不應只套一個通用訊息。若電話欄實際容許空格和加號，就不能錯誤地叫顧客把它們刪掉。安全許可下保留原答案，讓顧客看出錯字，毋須重建整份表格。
按真實規則建立錯誤清單
先列出一條顧客流程的欄位及每項驗證規則：必填而留空、格式、可接受範圍、限定選項，或必須待伺服器核對即時資料才知道的衝突。每項規則記下顧客看見的欄位名稱、錯誤文字、可接受的選擇或格式，以及原答案會如何處理。外觀格式正確，不代表業務上仍可接受。預約時間的格式可以完全正確，但時段已被別人選走；此時應展示仍可選的時間，而非叫顧客重打同一時間。產品數量可能是正整數，卻超出現有庫存；網站要交代新上限或讓顧客改選。反過來說，姓名中的撇號，或規則原本容許的香港電話國際寫法，不應被過窄的格式檢查擋下。先用真實本地輸入方式測試驗證規則，再潤飾訊息。W3C G177 技術例子展示建議可以是文字、可選的替代答案，或通往選項清單的連結；用哪一種，視乎系統是否真的知道安全而準確的替代選擇。
以預約失敗流程作例子
假設顧客預約家電維修，已填電話、地區及星期二下午到訪時段。填寫故障描述期間，最後一個星期二時段被別人選走。提交時伺服器應保留仍然有效的電話和故障描述，指出「期望到訪時間」有問題，說明所選時段已無空位，並提供現時可選時段或清楚的重新選日方法。不能暗中改成星期三，也不應把整份表格籠統說成無效。若顧客改了地區，時段可能需要重新計算；提供替代時段前應交代這個關係。若兩欄同時出錯，可在表格前列出摘要，亦在每個相關欄位旁放上針對性的訊息，配合連結或焦點安排方便顧客跳到問題位置。這些是實作選擇，並非說 W3C 強制指定某一種版面。驗收時要確認顧客明白哪項答案被拒絕、其他工作仍在、能改選有效答案，最後確認前又看得到正確詳情。中英文頁面的營運規則要一致，但表達應按各語言自然寫法處理。
讓錯誤訊息找得到、看得見
提交後，錯誤訊息要放在顧客找得到的位置，並持續顯示至足以採取行動。W3C 要求以文字識別錯誤，但沒有強制唯一呈現方式；訊息可在表格開首、欄位旁或其他合適位置。單靠紅框不能說明問題；一閃即逝的提示也可能在顧客讀完前消失。長表格可在前方列出需處理的欄位並提供跳轉，欄位旁再寫具體修正方法。使用屏幕閱讀器逐欄瀏覽時，欄位名稱與錯誤訊息的關係也要清晰。若系統邊輸入邊驗證，須測試新增訊息是否在合適時刻讀出，不要每打一個字就打斷或重複播報。提交後若仍留在同頁，可以有意識地安排焦點；顧客正在編輯時則不應突然移走焦點。放大頁面及窄屏幕下同樣要看得到訊息，固定頁首不可遮蓋被聚焦的欄位。修正後顧客亦應能返回摘要，核對所有問題是否已處理。
分辨何時不宜給具體建議
「錯誤建議」準則容許一個例外：提供具體建議會損害安全或內容用途。但這不等於所有錯誤都可變成「發生問題」。網站仍可指出受影響欄位，提供安全的下一步。例如登入流程若回應某電郵是否有帳戶，可能洩露帳戶資料；可以改為提供中性的復原途徑。驗證挑戰不應透露秘密答案，或指出哪些數字答對。相反，預約日期超出可選範圍、產品尺碼已無貨，通常有已知且安全的替代選擇。要分清秘密本身與修正方法。建議值不能帶出另一顧客資料，搜尋相近紀錄亦不能變相披露私人內容。由安全負責人針對每項驗證規則記錄例外理由，讓前線分辨真實資訊洩露風險與單純不想寫清楚訊息。底層規則變動時要重看文案；今天正確的格式指示，在表格明天接受新格式後可能變成誤導。
按語言及狀態分別寫訊息
雙語表格不能只把「輸入無效」直譯一遍。欄位名稱、例子、指示及可選替代值，應分別在英文與繁體中文版本決定。英文可按真實規則說明是否需要地區號碼；中文的自然語序和例子可以不同，但實際接受的數值必須一致。避免「上面的方格」等位置描述，因為手機版面可能已改變排序。相同資料再輸一次仍會失敗時，不能只叫顧客「再試一次」。動態條件會令靜態訊息失準：送貨方式若受地區或截單時間影響，錯誤要交代當前限制及可用選項。伺服器驗證失敗後，回應應維持顧客正在使用的語言；瀏覽器自帶的通用提示亦未必能說清營運規則。把錯誤文案放在可管理的內容系統，讓員工在欄位標籤和規則改動時一起覆核。這不只是前端程式工作，也是內容管理工作。
在真實流程驗收修正
每項規則至少試留空、錯誤格式、邊界數值，以及另一選擇改變後才失效的答案。記錄實際訊息、有否指出欄位、有否提供允許的修正、有效答案是否保留，以及最終提交是否真的使用改正後數值。英文和中文頁面都要用鍵盤、觸控、放大及屏幕閱讀器走一次。伺服器拒絕也要測，單靠前端測試可能漏掉即時庫存或時段變動後的回應。若因安全理由刻意用較概括的訊息，要記下風險，並確認安全的復原動作仍可用。讓不熟悉程式細節的客服同事讀訊息；若他無法據此指導顧客前進，文字大概還需修改。上線決定應根據這些證據，而非統計寫了多少錯誤句子或看一張有紅色欄位的截圖。真正目標是顧客犯下常見錯誤後，仍可保留正確資料，不必猜測公司暗中的驗證規則。
進行前先確認
- 每項偵測到的錯誤有否以文字指出受影響欄位？
- 已知安全修正方法時，訊息有否交代下一步？
- 伺服器拒絕提交後，有效答案是否保留？
- 中英文及輔助技術路線是否已測試？
