由顧客要做的事決定必填資料
表格範本常把許多欄位預設為必填，這不足以成為向顧客索取資料的理由。先寫清表格承諾完成甚麼事：回覆產品問題、安排回電，或準備服務報價。逐欄問職員若缺少該資料，能否完成承諾。W3C 的表格教程建議只要求完成流程所需的資料。若服務是電郵回覆，電郵地址與問題內容可能必要；電話、職銜和公司規模可能可選，甚至不需要。若顧客明確要求回電，電話才可能成為必要欄位，畫面亦須解釋原因。
建立簡短欄位決定表，記下欄位、用途、是否必填及理由，並標明負責決定的人。銷售或客服希望取得某項資料，可能只是偏好，未必是完成顧客當前行動的必要條件。要把營運需要與日後推廣方便分開；若資料只協助分流，可考慮先接受查詢，再由職員跟進，而非阻止顧客提交。表格增加用途時要重查決定表。若同一頁同時處理回電與一般問題，可先讓顧客選擇行動，避免兩條流程硬套同一組必填欄位。
每個控制項都要有持續可見的標籤
W3C 的標籤指引涵蓋文字欄、核取方塊、單選按鈕及下拉選單。一般 HTML 表格可用持續可見的 label，透過相同的 for 與 id 對應到控制項，讓輔助技術辨認關係，也擴大可點擊範圍。標籤應指出顧客要輸入甚麼，例如「用作回覆的電郵」，不要只寫含糊的「聯絡」。輸入框提示可提供例子，但不應是唯一標籤，因為顧客打字後提示可能消失。驗收要看真正輸出的頁面，不只看設計稿或程式元件名稱。
一組選項要同時標示整體問題與各選項。「希望怎樣回覆」作為組別標題，不能代替每個單選項的標籤；反過來，單獨的「電郵」「電話」若沒有問題，也可能含糊。W3C 說明可用 fieldset 與 legend 把組別描述連到相關控制項。選項宜寫出後果，例如「以電郵回覆」「請致電給我」，比只列渠道名稱有用。若選「請致電」後才顯示電話欄，須同步更新其必填狀態與說明，鍵盤及屏幕閱讀器使用者也應感知變化。
提交前清楚標示必填狀態
HTML 的 required 屬性告訴瀏覽器，支援該屬性的控制項提交前必須有值。MDN 亦建議在欄位附近提供可見提示；只有紅色邊框並不足以讓所有人理解。可在標籤或旁邊寫「Required」「必填」，或在表格開始解釋一致使用的符號。手機長表格的顧客可能直接到中段，不能只依賴頁頂圖例。若大部分欄位必填，也可清楚標示少數「選填」欄並說明總規則，但仍要檢查顧客在每個欄位附近能否判斷狀態。
須讓三層規則一致：畫面文字、控制項的程式狀態，以及伺服器接受資料的條件。標籤寫「選填」而 HTML 又設 required，便自相矛盾。MDN 指出 aria-required 可向輔助技術表達狀態，卻不會令瀏覽器強制輸入；相反，伺服器若拒絕畫面說可選填的電話，顧客提交後才會意外受阻。先在產品要求中定義規則，再逐層核對。條件式欄位變成必填時，須在相關選擇出現時同步更新並預先告知；顧客所選流程用不到的隱藏欄位不應保持必填。
在需要的欄位旁說明限制
必填標記只表示需要內容，沒有說明甚麼內容才合格。W3C 的「標籤或指示」準則涵蓋所有接受輸入的欄位，包括可選填欄。格式不常見、有限字數或須提交證明的欄位，應在旁邊提供簡短說明。例如報價查詢可能要知道工程地點以判斷服務範圍，但只寫「地點」無法讓顧客知道應填區域、完整地址還是場地名稱。若現階段只需地區，便只要求地區並說清楚。一般文字欄不應無故加上僵硬格式限制。
例子應協助理解可接受答案，不應暗中變成唯一規則。若寫「電話號碼，例如 9123 4567」，除非有明確業務需要，不應拒絕其他合理空格寫法。若某類查詢必須附文件，要說明所需文件、可接受檔案類型與大小限制，以及顧客暫時無法提供時的處理方式。指示應放在所管的欄位附近，讓使用放大畫面或小屏幕的人毋須記住遠處段落。中英文要用相同的接受情境測試，避免其中一種語言暗示較嚴格的規則。
用條件式查詢作完整例子
設想一家小型零售商，用同一表格處理一般產品問題和回電要求。第一項先讓顧客選擇途徑。產品問題需要問題內容和回覆電郵；回電要求需要查詢主題與電話，若職員不用電郵也能完成回電，電郵可維持選填。這些只是商店政策例子，並非法律規定。顧客若由回電改選電郵，電話便不應繼續必填，已輸入內容也須按清楚規則處理。提交後確認訊息應反映顧客選的渠道，讓他知道下一步會怎樣。
實作前先列簡短測試表：兩條途徑的空白提交、各缺一項必填資料、省略選填資料、填到一半才轉途徑，以及完整提交。每種情況都記下預期畫面標籤、瀏覽器狀態及伺服器回應。不能只因職員流程偏好取得資料，就把原本選填欄暗示為必填。若業務真的無法在缺少額外資料時處理查詢，便要在提交前說清要求，或提供顧客現在可完成的較簡單行動。這樣才不會出現技術上通過、營運上卻無法處理的表格。
驗收實際表格及提交結果
用鍵盤、觸控和屏幕閱讀器檢查真正輸出的表格。逐項移動，聽取標籤、組別問題、必填狀態及附近指示，再試交空白表格，看瀏覽器是否指向正確而可見的欄位。MDN 指出 required 適用於支援的輸入類型、select 與 textarea，並非每種控制項都適用；自訂控制項更需要自己的實作與測試。原生 required 有用，但請求可以繞過瀏覽器，伺服器仍須驗證。應核對兩層是否執行同一條規則，而非只確認兩邊都能顯示某種錯誤。
最後請一位沒有參與表格設計的同事，分別用英文及繁體中文完成一項真實情境查詢。只給任務，不預先解釋要填哪些欄位，觀察他在哪裏猶豫：沒有解釋的星號、含糊的公司欄，或突然變必填的電話欄，都反映決定規則有問題。把觀察記作易用性檢查，不要宣稱為轉換率或法律合規證據。按猶豫原因修正標籤、指示或規則，再重測該流程。發佈標準是顧客提交前能知道何者必要，並且有效查詢能向職員提供足夠資料完成承諾。
進行前先確認
- 商店能否解釋每個必填欄對所選行動有何必要？
- 中英文的可見標籤、HTML 狀態和伺服器規則是否一致？
- 顧客提交前能否知道每欄應填甚麼？
