表單即時驗證 UX 完整指南

三種驗證時機與適用情境

• 失焦驗證（onblur）：離開欄位時檢查，最常用、最不擾人。適合 Email、電話、地址等格式檢查
• 即時驗證（onchange/oninput）：每次輸入都檢查，適合密碼強度、字數限制等需即時回饋的場景
• 提交驗證（onsubmit）：送出前最後檢查，作為雙重保險防止跳過前面驗證

關鍵原則：不要「正在輸入時」就跳紅字錯誤訊息，那會很煩。最佳做法是顧客「離開欄位」才檢查，只有密碼強度等特殊情境才邊輸入邊驗證。

錯誤訊息撰寫的三個原則

• 明確：說出具體哪裡錯了，不要只說「輸入有誤」
• 具體：提供正確格式範例，讓顧客知道怎麼修正
• 不指責：用「請輸入...」而不是「你填錯了」

範例對比：

• ❌ 不佳：「Email 格式錯誤」
• ⭕ 良好：「請輸入有效的 Email 格式（例如 name@example.com）」
• ❌ 不佳：「電話無效」
• ⭕ 良好：「手機請輸入 09 開頭 10 碼，市話請含區碼如 02-XXXXXXXX」

視覺回饋的設計

完整的視覺回饋系統：

• 成功狀態：欄位邊框淺綠 + 右側小綠色勾號（簡短鼓勵）
• 錯誤狀態：欄位邊框紅色 + 右側 ⚠ 圖示 + 下方紅色錯誤訊息
• 輸入中：欄位邊框淺藍 + 焦點高亮（讓使用者知道目前在這個欄位）
• 禁用狀態：欄位灰底淺色文字（明顯不可編輯）

重要：不要只靠顏色傳達狀態（色盲使用者看不出來），要搭配圖示與文字訊息。

常見欄位的驗證範例

• Email：檢查 @ 與 . 結構，建議用 RFC 5322 標準正規表示式
• 台灣手機：09 開頭共 10 碼純數字（可含 - 符號自動移除）
• 市話：區碼開頭，台北 02、台中 04 等
• 統一編號：8 碼純數字，可加上財政部 API 驗證真實存在
• 身分證字號：1 碼英文 + 9 碼數字，可實作檢查碼演算法
• 信用卡號：13-19 碼數字，可用 Luhn 演算法驗證
• 密碼：至少 8 碼，建議包含大小寫、數字、特殊字元

密碼強度的即時顯示

密碼強度檢查是即時驗證的經典案例：

• 強度條：顯示弱（紅）/中（橘）/強（綠）三段
• 條件清單：「至少 8 碼 ✗」「含英文 ✓」「含數字 ✓」「含特殊字元 ✗」
• 顯示密碼按鈕：眼睛圖示讓顧客切換明碼/密碼顯示，確認沒打錯
• 常見弱密碼提示：偵測到 123456、password 等弱密碼時提示更換

無障礙設計考量

無障礙標準（WCAG 2.1）對表單驗證的要求：每個欄位都要有 <label> 連結（讓螢幕閱讀器知道是什麼欄位）；錯誤訊息要用 aria-describedby 連結到欄位（讓螢幕閱讀器讀出）；錯誤狀態要用 aria-invalid="true" 標記；不要只靠顏色判斷錯誤（要有圖示或文字）；錯誤訊息對比度至少 4.5:1；提交失敗時將焦點移到第一個錯誤欄位，鍵盤使用者也能找到問題。

行動版的特殊處理

行動版表單驗證要注意：錯誤訊息不要被軟鍵盤遮住（自動捲動到錯誤欄位上方）；輸入 Email 時喚起 Email 鍵盤（type="email"）；輸入電話時喚起數字鍵盤（type="tel"）；輸入郵遞區號時喚起純數字鍵盤；觸控目標至少 44px 高度；錯誤訊息字級至少 14px 確保看得清楚。

常見問題解答