表單欄位如何讓輔助工具讀懂？核對名稱、必填與錯誤提示

從欄位名稱、必填狀態、錯誤關聯到修正後回饋，逐步檢查使用者能否透過輔助工具完成表單。

表單能不能順利完成，不只看欄位有沒有顯示在畫面上，也要看使用者能否聽懂每一欄要填什麼、知道哪些項目必填，並在出錯後找到修正方式。以下從名稱、提示、錯誤關聯與實際操作逐項檢查，適用於已經完成欄位規劃的表單。

核對欄位可讀名稱

檢查時先逐欄閱讀畫面文字，暫時不看圖示與位置，只問：只聽到這個名稱，能否知道要填什麼？「姓名」通常明確；「資料」、「其他」沒有說明內容，可按用途改成「聯絡人姓名」或「希望回覆的方式」。名稱要和實際用途一致；若欄位接受電話或電子郵件，不要只叫「電話」，可寫成「方便聯絡的方式」。

接著檢查名稱是否與控制項建立程式關聯：畫面可見文字要能成為該輸入欄位的可讀名稱。原生表單可用 label 包住欄位，或讓 label 的 for 對應欄位唯一的 id；只把字放在旁邊，輔助工具未必知道它屬於哪一格。若用 placeholder 放例子，輸入後文字會消失，不宜單獨當名稱；圖示旁的提示也要有文字。

對單選或複選題，先為整組寫清楚問題，再為每個選項提供名稱；「聯絡方式」與「電話」不能只靠縮排猜成一組。用鍵盤移到每個欄位，確認讀屏軟體朗讀的是目前要回答的問題；若只聽見「編輯框」或「按鈕」，就回頭查名稱關聯。同一頁若有「帳單地址」和「收件地址」，即使欄位結構相同，也要讓名稱說出用途，避免使用者猜測。

修改後可把名稱單獨唸出來，請同事判斷要填什麼，再按順序走完表單；若仍需要看旁邊段落才能理解，名稱可能不夠自足。核對結果記在欄位清單：畫面名稱、輔助工具實際讀到的名稱、控制項類型及差異，讓後續調整有明確落點。

標示必填與格式提示

先依已決定的資料需求，逐欄確認哪些項目必填、哪些可以略過。必填狀態不能只靠紅色、星號或版面位置傳達；可以在欄位名稱旁寫「必填」，或在表單開頭交代星號的意思，再確認每一欄的程式狀態也有對應標記。若欄位不是必填，直接標示「選填」有助於使用者決定是否略過。

格式提示放在輸入欄位附近，並在焦點移入時仍能讀到。說明要指出需要的內容或格式，不要只寫「格式錯誤」。例如，電子郵件欄可提示「請輸入可收信的電子郵件地址」；若系統要求特定日期格式，就把格式寫清楚。不要要求使用者猜測分隔符號、長度或大小寫規則，也不要提供與實際驗證條件不一致的例子。

提交時，若必填欄位未完成，讓使用者找到該欄並理解缺少什麼；不要只在頁首顯示一個紅色符號。使用原生控制項時，確認必填狀態與畫面文字一致；自行製作的控制項則要檢查對應的狀態資訊是否提供給輔助工具。欄位標記、格式說明與實際驗證三者一致，才算完成核對。

連結錯誤和對應欄位

錯誤訊息要讓使用者知道哪一欄需要處理，不能只在頁首出現「有資料錯誤」，也不能只把欄位框線改成紅色。提交後若有多個問題，可提供錯誤摘要並連到對應欄位；每個欄位旁也要有文字說明，讓使用者逐一修正。摘要與欄位訊息應使用一致的稱呼，避免摘要叫「聯絡方式」、欄位卻叫「其他資料」。

檢查訊息和欄位的程式關聯。可以讓錯誤文字有唯一 id，再由對應欄位透過 aria-describedby 參照；欄位處於錯誤狀態時，也可提供 aria-invalid。若同一欄另有格式提示，確認兩段文字都能被讀到，並留意更新後參照仍指向正確內容。這些標記要反映當下狀態，不能在沒有錯誤時仍宣告欄位無效。

錯誤文字要指出問題和下一步，例如「電子郵件地址缺少 @，請檢查輸入內容」，比「輸入無效」更能協助修正。不要把原因藏在顏色、圖示或短暫消失的通知裡。訊息應靠近欄位，讀屏時也能和欄位名稱一起理解；若表單有錯誤摘要，鍵盤操作要能從摘要移到需要修正的欄位。

再實際檢查修正後的狀態：更正內容並重新驗證時，已解決的錯誤要清楚解除，欄位狀態及摘要也要同步更新；仍有問題的欄位則保留明確提示。若使用者已修正但錯誤訊息還留著，或焦點跳到另一欄，應記下實際發生的步驟與欄位，回頭檢查狀態更新、訊息關聯和焦點安排。

測試修正前後回饋

把錯誤流程當成一段完整操作來測：先填入錯誤內容或略過必填欄位，提交後確認系統指出哪裡有問題；再依提示修正、重新提交，確認錯誤消失且其他欄位的內容仍保留。這樣才能知道提示是否幫得上忙，而非只確認畫面曾出現一段紅字。測試前先列出預期狀態，方便比較結果。

例如，假設電子郵件是選填，但使用者填入不符合表單規則的內容。提交後，訊息應指出對應欄位和可採取的修正方式；使用者改正後，欄位不應繼續標示錯誤。如果該欄留白應可通過，就一併確認系統沒有把它誤判為必填。這是假設情境，實際預期要依表單本身的規則設定。

至少走過幾種輸入狀態：空白的必填欄、可略過的選填欄、符合格式的內容，以及不符合格式的內容。若允許空白或多種格式，按表單的既定規則測，不要把個人偏好的寫法當成驗證標準。每種狀態都記下畫面提示、輔助工具讀到的文字、焦點所在位置和使用者能否找到下一步。

也要觀察提示何時出現。若尚未碰過欄位就被判錯，使用者可能無法知道如何避免；若直到提交後仍沒有回應，也可能找不到原因。依表單的互動設計，選擇適當時機顯示錯誤，並確認同一條錯誤規則在滑鼠、鍵盤和輔助工具操作下都會回饋。修改完成後重跑同一組步驟，避免只確認初次載入的狀態。

測試紀錄要分開寫預期與實際：例如預期修正後錯誤解除，實際卻仍被朗讀為無效。這比「提示有問題」更容易定位，也能供負責調整的人重現。若已修正，再從相同的錯誤輸入走一次，確認新的回饋與欄位狀態一致。

用輔助工具走查

走查時先收起滑鼠操作，只用鍵盤按 Tab、Shift+Tab 和控制項適用的方向鍵，從表單第一個欄位走到提交位置。每到一欄，記下焦點落點、輔助工具讀到的名稱、是否必填、格式提示及控制項類型；按順序完成、略過選填欄，再觸發一次錯誤。這能發現名稱缺漏、焦點順序不清或無法操作的問題。

接著使用螢幕閱讀器逐欄確認資訊是否在適當時機被讀到。先聽欄位名稱，再確認必填狀態和格式說明；送出含錯誤的表單後，確認錯誤摘要或欄位錯誤能被發現，也能回到需要處理的位置。不要只憑一段朗讀推斷整張表單都正常；逐項記錄，才知道哪一個欄位或狀態需要調整。

若表單有單選題、複選題或下拉選單，依控制項的操作方式測試：移動選項時能否知道目前選到哪個項目，改變選擇後狀態是否清楚，離開再回到欄位時是否仍可理解。也可在支援語音控制的環境中，嘗試以畫面上可見的欄位名稱定位；若名稱不同或無法辨認，記下畫面文字和讀到的名稱供比對。

操作時不要只檢查頁面初始狀態。錯誤訊息出現、內容修正、必填欄留白和表單重新提交，都可能改變欄位名稱以外的資訊。每個狀態都重新聽一次，特別注意提示是否重複朗讀、錯誤更新後是否仍可找到，以及焦點是否跳離目前正在處理的欄位。

測試環境不必假裝涵蓋所有使用者組合。把使用的瀏覽器、作業系統和輔助工具記下來，說明實際測到的範圍；若手邊沒有螢幕閱讀器，就標記尚未測試，先完成鍵盤走查並安排後續檢查。明確寫出已驗證的操作，比籠統寫「相容輔助工具」更能支持下一步修正。

記錄未能完成項目

遇到無法完成的檢查，先留下可重現的紀錄，不要把未測寫成通過。記錄表單頁面或欄位名稱、操作步驟、預期結果、實際結果、使用的瀏覽器與輔助工具，以及發生問題時的輸入狀態。若缺少測試設備、帳號或可操作環境，也寫出限制是什麼；下次接手的人便知道目前證據涵蓋到哪裡。

描述問題時寫具體行為，例如「按 Tab 到電子郵件欄後只聽到編輯框，沒有欄位名稱」，比「表單無障礙不足」更容易排查。若只在提交後發生，補上觸發條件、錯誤出現位置、焦點是否移動，以及修正內容後是否解除。保留可以安全重現的步驟，不要在紀錄中放入真實個人資料；需要測試資料時使用虛構內容。

接著區分已確認的問題和仍待確認的項目。前者附上重現步驟及預期、實際差異；後者說明缺少哪個條件，並標記尚未驗證。若有暫時替代操作，也記錄它是否真的測過，以及使用者仍需付出的額外步驟。不要只因為找不到測試工具，就推論欄位一定有問題或一定正常。

安排後續時，先處理會阻止使用者辨認欄位、修正錯誤或送出表單的項目，再回頭檢查較不影響流程的提示細節。每次調整後，重跑原本失敗的操作，確認結果改變；若環境或表單版本不同，也在紀錄中更新測試條件。完成一項就標明證據，剩下的項目保留未完成狀態，讓接手者知道從哪裡繼續。

現在挑一張正在使用的表單，先走查一個必填欄和一個錯誤修正流程，記下第一個無法理解或操作的地方，再依本文順序逐欄補查。若要了解 ZhenheAI，請前往官方網站。