先看清楚地址輸入任務
顧客用手機輸入送貨地址時，可能同時拿着包裹，只能在小鍵盤逐格打字。要求姓名或街道重複輸入，既費力，也容易令兩處內容不一致。先畫出完整任務：聯絡資料、送貨地址、如有需要的帳單地址，以及最後核對畫面。分清哪些資料屬於顧客本人，哪些屬於收件人或公司。W3C 的「識別輸入用途」指引主要針對收集用戶資料的欄位，並非每個自訂商業欄位都有標準自動填寫代碼。設計重點是找出有公認用途的欄位，並讓顧客檢查和更正建議值。
應在真正的窄屏幕上觀察兩種網站語言的欄位名稱和次序。香港地址常有大廈、樓層和室號，未必適合硬套外國的固定模板。不要只因全球網店模板有地區或郵政編碼欄，就強迫本地顧客填寫不相關資料。HTML 標準提醒，不同地方的地址欄位次序各異，表格宜符合當地習慣。先問清承運人真正需要甚麼，把非必需項目設為選填；含意不明的欄位可附簡短例子。即使瀏覽器沒有儲存地址，顧客亦必須能自行輸入。
讓代碼與欄位意思一致
HTML 的 autocomplete 屬性可告訴瀏覽器欄位預期的是姓名、街道地址、地址分行或電話。標準亦提供 shipping 和 billing 標記，讓瀏覽器分辨送貨與帳單兩組地址。只有欄位含義吻合時才使用相應代碼。可見標籤仍然重要：一個代碼不能替人解釋「地址第二行」究竟應填樓層、室號還是大廈。W3C 指出，瀏覽器即使沒有正確標記，也可能靠猜測自動填寫；這不等同 WCAG 1.3.5 所要求的程式可識別用途。應測試實際顯示的表格，而非只看程式碼。
不要讓同一欄位承擔互相矛盾的用途。若電話號碼是收件人電話，標籤要清楚說明，不應當作買家本人的電話。企業查詢表和消費者結帳可能需要不同設計。若一格可同時輸入電郵或用戶名稱，W3C 亦承認單一欄位未必有一個完美對應的用途值。應記錄這些邊界情況，並用輔助技術測試，而非強行加上誤導代碼。瀏覽器填入儲存值後，網站必須容許用戶修改。自動填寫只是輸入輔助，不代表地址仍然有效或可送達。
讓顧客有選擇地重用資料
在多步驟流程中，可讓顧客選擇帳單地址是否與送貨地址相同，而不是強迫重新輸入。W3C 的「避免重複輸入」準則指出，同一流程中已輸入的資料再次被要求時，應自動帶入或供用戶選取；若重新輸入屬必要、涉及內容安全，或舊資料已失效，則有例外。W3C 亦以「帳單地址與送貨地址相同」作例子。選項應清楚顯示會複製甚麼，並讓顧客容易改成另一個帳單地址。不能因顧客對其中一組地址使用自動填寫，就假定兩組地址一樣。
顧客在某一步作出的修改，換頁後要保留。若瀏覽器建議舊室號，顧客已更正，之後的摘要應顯示新值，不能又還原成儲存建議。收件人姓名和聯絡方法要有清楚標籤，並以將交予送貨商的形式顯示地址。若承運人需要特定地區資料，應在輸入處說明。不要把方便的重用功能變成隱藏同步規則，意外改動已編輯的地址。企業應先訂明修改送貨資料後會否同時改動帳單資料，介面亦要讓用戶理解。
用真實手機流程驗收
假設顧客為朋友購買禮物。瀏覽器提出顧客住址，但送貨應到朋友辦公室。顧客自行輸入辦公室地址，帳單則保留自己的地址。好的表格不會悄悄把住址同時填進兩組欄位，也不會覆蓋收件人資料的修改。確認頁應分開呈現兩個地址，並提供返回修改任一地址的路徑。這是設計演練情境，並非已發生的顧客事故；它檢查的正是便利功能可能造成錯誤派送或混亂帳單的時刻。
至少在窄屏幕測試三種狀態：沒有儲存資料、只有一個地址，以及有兩個地址而送貨與帳單資料不同。除觸控外，也要用鍵盤和屏幕閱讀器操作。檢查輸入後標籤仍看得見、必填與選填清楚，以及無效資料會收到可操作提示而不會抹掉先前內容。繁體中文和英文版本要分別測試；即使底層代碼相同，翻譯後的標籤仍可能變得含糊。記錄所用瀏覽器和裝置，因自動填寫建議屬使用者代理的行為，不同環境可能有差異。
訂立可驗收的規則
驗收規則應着眼於顧客是否掌握控制權，而非數了多少個 autocomplete 屬性。要問瀏覽器是否把資料放進正確的送貨或帳單組別、用戶能否看出正在使用哪個地址，以及修改能否一直保留至提交。W3C 的準則關心的是公認用戶欄位用途能否由程式識別，瀏覽器實際有否自動填寫並非判斷條件。因此，只看見某瀏覽器成功填入一格仍不足夠。團隊要一起檢查標記、可見標籤和操作結果。香港地址習慣與全球模板若有衝突，應透過使用者測試解決，不要自創標準代碼。
可先選一個最費時的表格改進，而非一次改遍所有頁面。逐欄列出地址及聯絡資料的業務用途、可見標籤、適用的標準代碼，以及是否可以不填。然後以送禮和送貨到本人地址兩種情境，在兩種語言中完成流程。請測試人員記錄每次錯誤建議，以及每次未能保留的修改。先修正欄位模型，再處理外觀。Astera 可協助實作和測試標記及流程；送貨資料真正需要甚麼，應由企業定義。理想結果是表格減少輸入負擔，同時清楚呈現顧客實際選擇。
處理共用裝置及意外資料
自動填寫值可能來自家庭或工作場所共用裝置的瀏覽器資料。網站不應把建議姓名或地址當成已核實身份。訪客流程中，顧客應能選擇另一位收件人並修改聯絡資料，而不必先建立帳戶。不要太早預選儲存地址，令顧客錯過檢查。最後畫面要顯示足夠目的地資料，供顧客有意識地確認，同時避免在旁人可見的屏幕上暴露不必要的個人細節。這些是設計上的預防措施，不是聲稱瀏覽器總會提供錯誤資料；當裝置持有人與買家不同時，表格仍應可靠。
測試時請參與者先接受自動填寫，再修改一行地址、返回上一頁、重新前進，最後核對畫面後才提交。這可抓出一種常見實作問題：表面欄位已改，但隱藏表格狀態仍保留舊值。應在安全的測試環境檢查實際提交紀錄，而不只看最後一頁。也要確認地址建議服務不會阻止用戶輸入它不認識的地點。若送貨範圍有限，應另行說明限制並提供易明的錯誤訊息。建議服務可加快輸入，但不能成為沒有解釋的地址把關者。
測試地址流程
- 讓每個有公認用途的欄位對應真實意思及清楚標籤。
- 送貨及帳單資料須分開顯示並可修改。
- 以兩種網站語言測試空白、已儲存及已修改狀態。
