先找出重複要求
先拿一條真實顧客流程來看，不能只點算畫面上有多少欄位。例如顧客在預約服務時已填聯絡電話，到選擇到訪時間又要再填一次；網店在選送貨方式時收了地址，到付款頁卻再顯示空白地址欄。逐步記錄資料由誰提供、後一欄是否要求同一資料，以及公司究竟要用它作甚麼決定。關鍵是顧客在同一次流程已提供資料，卻必須重新輸入才能完成。W3C 的「避免重複輸入」準則涵蓋顧客先前輸入或網站先前提供、在同一流程又要求輸入的資料；一般應自動填入或讓顧客選用，但有明確例外。即使小企沒有宣稱符合某級無障礙標準，這也是可操作的設計檢查。要界定流程邊界：下個月重新預約不一定屬於上次流程。顯示電話讓顧客覆核，與清空欄位逼他再打一次，是兩回事。亦要問前線同事重複欄位是否真的有營運用途，不要一見相同資料就武斷刪除。
決定如何帶入舊答案
實作大致有三種。第一，後續步驟確實要用同一資料，就保留先前數值並讓顧客修改。第二，顯示簡短摘要及清楚的「修改」操作，返回正確步驟時不要抹去其他已填內容。第三，兩種用途有可能共用資料時，提供明確選項，例如「帳單地址與已填的送貨地址相同」。W3C 的 G221 技術例子包括以核取方塊把早前帳單地址帶到送貨地址，以及在後一步讓使用者選取先前提供的商業資料。這是可用方法的例子，並非強制使用某一種元件。不能暗中把一人的地址放進另一收件人的欄位。如果後一欄的含義不同，應另行詢問，並在介面講清楚。預約表格中的顧客聯絡電話與師傅到場時要找的聯絡人電話，經常相同卻不一定相同。寫明「現場聯絡電話沿用我的電話」比放一個看似重複卻含義不明的欄位清晰。提交前讓顧客看到最後會用哪個數值。
以服務預約逐步驗證
假設一家維修公司把預約分成四步：描述故障、填聯絡資料、選到訪時間、覆核。美怡在第二步填了姓名和電話。第三步要問誰可開門、師傅應致電甚麼號碼。介面可提供「使用美怡的聯絡資料」選項，另設「現場聯絡人不同」的路線。選本人時，現場電話取自早前答案；選另一人時，才要求填那人的姓名和電話。覆核頁把顧客聯絡與現場聯絡分開標示，兩者各有修改入口。若美怡修改自己的電話，系統必須決定並交代已選用的現場電話會否同步更新；不能悄悄保留過期號碼，也不能覆蓋她刻意另填的聯絡人。提交失敗時，仍然有效的答案應保留，受影響的欄位要指出問題並提供改正方法。這只是一個說明用流程，不代表實測顧客成果。驗收重點是兩種合理路線都可完成，未變資料毋須重打，而且顧客能在確認前察覺及修改被帶入的數值。
審慎使用例外
W3C 準則有三個例外：重新輸入對活動本身不可或缺、為保障內容安全而必需，或先前資料已不再有效。每次援引都應記下具體原因，不能把所有「再確認一次」都說成安全要求。例如新密碼被遮蓋，網站可能需要重輸以核對使用者真正設定的字串；普通電話欄位不會因為員工喜歡有兩份就變成安全措施。預約時段已被別人選走，先前選擇便失效，可以要求再選；顧客主動改了地址，舊地址也不應照搬。這時要說明變動，保留其他不受影響的答案。別為了讓員工安心而反覆收集敏感資料，重填本身可能增加暴露與出錯機會。W3C 的說明亦提醒，自動帶入若設計粗疏，可能洩露個人資料。共用電腦、複製連結、瀏覽器歷史及伺服器上暫存草稿的擁有權，都會影響資料放在哪裏。資料須綁定正確顧客和流程，適時清除，並請負責私隱的人員一起審視。
先定資料規則再做畫面
畫面要清楚，資料模型也要先清楚。每項資料都列明用途、來源與更新規則，例如「顧客聯絡電話」、「現場聯絡電話」及「現場電話是否沿用顧客電話」。顧客選擇沿用時，應記錄這個選擇，而不是只存兩串碰巧相同的數字。之後來源電話被修改，系統要預先決定自動同步、提示確認，還是取消兩者的連動；結果須符合顧客理解，並在覆核頁看得見。多步驟網頁表格需要在返回上一頁和一般驗證錯誤後保留草稿，同時防止其他使用者取得。若每步從伺服器重新載入，要核實取回的是當前、已授權的草稿，而非過時的瀏覽器副本。若容許跨次登入恢復流程，這是額外功能；W3C 所談的是同一流程，跨次保存還涉及其他私隱及帳戶控制決定。產品、技術和客服應共用準確欄位名稱。內部只叫 phone 的欄位，無法說清楚是付款人、收件人還是現場聯絡人的電話。
測試修改、錯誤及裝置
測試不應只按一次預設路線就算完成。先用帳單與送貨資料相同的新顧客，再試收件人不同的訂單；預約流程則試現場聯絡人先相同、後來改為別人。用鍵盤及屏幕閱讀器核對「沿用資料」選項有可理解名稱，選取狀態可被讀出；用觸控檢查選項毋須靠滑鼠停留提示才能找到。返回上一頁修改原值，再前進，觀察下游資料如何更新。刻意讓一個無關欄位驗證失敗，核對其他有效答案沒有消失。同一流程開兩個分頁時，要決定以哪個草稿版本為準，或如何提示衝突。在共用裝置上登出或開始另一顧客流程，核實前一人的資料不會外露。每項測試簡短記下起始值、操作、預期帶入值、實際顯示值，以及資料失效時是否有通知顧客。如此修正才有明確對象，也可在改版後重做。
作出上線決定
上線判準可以寫得具體：顧客能完成流程而毋須無故重打、能看見並修改帶入的資料，而且不會接觸另一顧客的資料。若公司說不出重複欄位存在的理由，上線前就應取消要求或提供先前答案。兩個欄位若有不同營運含義，應分別寫明用途，只在確實可共用時提供沿用選項。安全或資料失效真的需要重輸，就在當下說明原因，並保留流程其餘部分。除了畫面標籤，也要指定資料規則的負責人；頁面看來修好，伺服器仍用舊電話，問題一樣存在。顧客確認頁與員工工單要一起核對，因為顧客看到已改的新聯絡人，工單卻可能仍留舊號碼。這種決定比空泛宣稱表格「無障礙」有用：它指出減少了哪種顧客負擔、哪些例外仍存在，以及用甚麼證據證明流程可行。
進行前先確認
- 顧客在後一步可否沿用或選用同一項有效資料？
- 顧客在最後提交前可否查看和修改帶入資料？
- 每項安全或失效例外是否有具體記錄？
- 員工紀錄取得的是否正是顧客覆核頁顯示的數值？
