先判斷表格要填的是誰的資料
聯絡表格可能要求填表者的姓名、電郵及電話，也可能要求填收件人、同事或查詢對象的資料，兩種用途不可混為一談。W3C 的「識別輸入目的」指引針對收集使用者本人資料、且具有既定用途的欄位。設計時先在每個欄位旁註明是否屬填表者本人，切勿因為欄位都能輸入電郵，就把個人自動填寫標記加到第三者資料上。瀏覽器提出看似合理的建議，仍可能填入錯誤的人，造成實際業務錯誤，而非單純畫面問題。
編寫欄位前，先說明每項資料的用途。回覆電郵決定職員將答案寄到哪裏；若電郵足以處理查詢，回電電話或可選填；稱呼所需的姓名不應暗中變成提交門檻。還要決定表格服務已登入的帳戶持有人，還是未登入訪客。若帳戶已有聯絡資料，應顯示將採用哪個數值，並在流程容許時讓顧客修正。帳戶保存的資料與瀏覽器建議來自不同來源，顧客應能分辨，才可在按「送出」前發現舊資料或共用裝置留下的數值。
讓標籤、輸入類型與用途標記一致
簡單的填表者資料欄，可用 name 標示全名、email 標示本人電郵、tel 標示本人電話。HTML 標準定義了這些自動填寫欄位名稱；W3C 的 H98 技術也要求核對標記是否有效，並與欄位標籤所說的用途相符。可見標籤仍然重要。「你的回覆電郵」比孤立的「電郵」清楚，尤其當查詢內容另有顧客電郵欄位。HTML 輸入類型亦應合適，但不可把格式與用途混淆：type=email 表示欄位格式，autocomplete=email 則表示這是填表者本人的電郵。
不要單憑欄位外觀猜用途標記。若要求公司名稱，應核對標準中的 organization，並判斷它是否真的指填表者所屬機構。訂單編號則不應偽裝成電話或使用者名稱。若同一欄同時接受電郵或客戶編號，便沒有單一而明確的個人資料用途；W3C 亦指出，技術不能表達兩種用途時要另作處理。若有助顧客理解，可改成兩條清楚標示的輸入途徑。把各欄位的標籤、資料主人及用途標記列入簡短清單，日後改版才不會無意破壞。
中英文欄位須維持相同意思
自動填寫標記是固定技術名稱，畫面標籤則按讀者語言撰寫。英文「Your name」和繁體中文「你的姓名」若都收集填表者全名，可以使用同一 name 標記；翻譯不應悄悄把填表者資料改成收件人資料。也不要因中文姓名的顯示次序，便交換 given-name 與 family-name；兩者描述姓名部分，不是欄位在畫面上的位置。若業務只需要全名，清楚標示的一個 name 欄位可能比強迫訪客按兩段姓名填寫更合適。
標籤應在瀏覽器建議清單出現或手機窄屏時仍可辨認。不要只把標籤放在輸入框內作提示文字，因為輸入後提示會消失。電話欄須說明用途：回電、送貨或帳戶驗證涉及不同顧客決定。若電話可選填，中英文都要一致，驗證訊息不可突然要求必填。顧客填表後切換語言，已輸入的資料應保留，各欄位的語義亦須維持。應用已自動填入的表格測試切換，而非只測試空白頁。
讓顧客檢查自動填入的資料
自動填寫是瀏覽器提出的建議，不能保證資料仍然有效，也不能假設裝置只屬一人。W3C 說明，識別輸入目的的合規測試在於程式能否表達用途，並非瀏覽器是否真的自動填寫；但商店仍須測試真實使用流程。接受建議後，內容要清楚可見、可讀和可修改，不應立即提交或鎖死欄位。顧客須能刪除錯誤建議、改填另一電郵，並在送出前核對最後數值。共用辦公電腦或代公司查詢時尤其如此。
例如訪客查詢公司採購，瀏覽器卻建議私人電郵。「你的回覆電郵」仍可用 email 標記，因為填表者正在提供自己的收件地址，但畫面應請他最後核對回覆會寄往哪裏。若商店規定必須用公司電郵，應直接說明，不要靠瀏覽器猜測。若已登入帳戶的電郵因安全規則不可在此修改，也要清楚解釋並提供正確更改途徑；不可設計一個貌似可編輯、卻悄悄丟棄修改的欄位。目標是回覆寄對地方，而不是追求較高的自動填寫接受率。
獨立核對提交資料
語義標記有助瀏覽器理解欄位，卻不能證明電郵屬於填表者、能夠送達，或電話會接通指定人士。提交時仍須按必要的格式及業務規則檢查，並讓顧客修正而不失去其他答案。伺服器也要執行關鍵檢查，因為請求可以繞過網頁直接送出。格式錯誤與信箱無法收信是不同情況：前者或可即時發現，後者可能寄出後才知道。不可聲稱開啟自動填寫便已驗證身份。
收集資料應與查詢需要相稱。若商店可用電郵回覆，不應只因表格範本有電話欄便強制填寫。若職員需要回電，應說明原因和預期用途，並確保承諾可實現。附件或自由文字問題不應為了讓工具報告顯示完整，便硬套個人資料標記。W3C 的準則只涵蓋有既定用途的使用者資料，並非頁面上每個輸入欄。簡短欄位清單應記錄哪些欄位適用、哪些不適用及理由，方便無障礙覆核和日後修改。
同時測試標記與使用流程
驗收時應檢查實際輸出的 HTML，不只看設計稿。逐個個人聯絡欄位比較可見標籤、程式標籤、輸入類型及 autocomplete 標記，確認標記有效，亦與標籤所指的人及資料一致。之後用常見桌面及手機瀏覽器，分別以已存資料、無已存資料及刻意保留的舊資料測試。檢查鍵盤操作、焦點次序、建議清單、修改及出錯後的復原；英文和繁體中文都要做。某瀏覽器在特定狀態未提出建議，不代表語義標記一定錯誤，記錄時應把實際行為與標記評估分開。
實用的發佈情境是共用裝置查詢：瀏覽器建議前一位使用者的姓名與電郵，新訪客看出問題、改填兩欄、送出，確認訊息則列出已選的回覆地址。另一情境是已登入訪客填表途中切換語言。若系統仍把答案寄往舊建議，或切換語言後欄位對應錯亂，應先修正。測試須用虛構資料，不應把真實顧客資料輸入測試帳戶。最後的驗收問題是：顧客能否知道表格要誰的資料、接受或拒絕瀏覽器建議，並確認回覆會寄往何處？
進行前先確認
- 每個個人資料欄的用途標記，是否與可見及程式標籤一致？
- 顧客在提交前能否拒絕或修改自動填寫建議？
- 中英文是否都要求同一人的資料？
