顧客在確認結帳前，能否發現代價高的錯誤？

先找出有重大後果的提交

結帳流程可能由瀏覽商品，在一次按鍵後變成有金錢後果的承諾。顧客可能選對產品，卻填錯數量、送貨地址、日期或付款方法。最後覆核的目的，是讓顧客在有後果的提交前發現代價高的錯誤。WCAG 2.2 成功準則 3.3.4 適用於引致法律承諾或金融交易、修改或刪除用戶可控制的已儲存資料，或提交測驗答案的網頁。相關頁面至少要具備三種方法之一：可撤回提交、檢查輸入錯誤並容許修正，或在最終提交前提供覆核、確認及修正機制。應按交易性質選擇；這不表示每次普通儲存都要加一頁確認。

先畫出實際流程在哪一步形成承諾。修改購物籃可能只更改暫存選擇；按「提交訂單」可能代表接受價格和送貨條件；其後付款又可能產生另一後果。服務預約即使稍後才收款，也可能先佔用有限名額或觸發取消條款。須寫下每一步之後有哪些事項難以更改、顧客當時獲告知甚麼。覆核應放在相關承諾之前，而非放在數頁前、之後資料仍可改動的位置。若最後付款由第三方頁面處理，仍要查清自家訂單何時建立，以及付款結果未明時會返回甚麼狀態。

最後確認步驟只有展示顧客能據此作決定的資料才有用。按交易性質，應列出商品及重要款式、數量、單價與總額、幣別、送貨或服務地址及時間、額外收費、付款方法描述，以及會實質影響決定的條件。W3C 的訂單例子特別提到商品、數量、收貨地址及付款方法。重要變動不宜藏在預設摺疊的區塊內，也不能只用「資料無誤」一句代替實際內容。覆核頁不是第二個推銷頁面，而是讓顧客把原意與系統即將記錄的交易比較；標籤和金額計算基準應與前面步驟一致。

讓重要資料真正可以修改

W3C 的 G98 技術文件提出多頁流程的兩種實務方法：讓顧客返回先前步驟，同時保留已填資料；或在最後顯示完整摘要並提供修改方法。這是達標例子，而非規定必須採用某種頁面設計。「修改地址」應帶顧客到地址欄位，改妥後返回更新的摘要；「修改數量」應重新計算總額，並顯示存貨或送貨安排的影響。若修改令價格、優惠或供應情況改變，須突出新結果，讓顧客確認。只有覆核畫面、卻要求顧客全部重填或令原有選擇遺失，並不能提供實際可用的修正途徑。

應在適當時候檢查輸入錯誤，但不能把技術上有效的數值當成顧客真正想要的決定。地址格式合格，仍可能送錯地方；系統容許數量十，顧客卻只想買一件；送貨日期在可選範圍內，也可能不適合收件人。覆核頁透過易讀的完整交易內容，幫助顧客發現這類語意上的錯誤。反過來，最後覆核亦不能彌補前面欄位名稱不清或錯誤訊息含糊。系統若知道某值不合規，應在最終承諾前指出相關欄位，並說明顧客如何修正。

按鈕文字應清楚說明真正動作：「覆核訂單」是前往覆核；「確認並提交訂單」才是有後果的提交。若付款在下一步進行，亦應如實描述流程。按鈕、旁邊顯示的金額及完成訊息，對訂單只是已儲存、已接受或已付款，必須一致。可防止意外連按，但不能只靠停用按鈕作唯一保護。提交後顯示收據或附穩定參照的待處理狀態。若網絡回覆遺失，頁面應提供查詢結果的方法，而非不加說明就要求顧客重新落單。這屬另一項系統可靠性問題，亦有助保持覆核流程資訊真確。

提交後能否更改，須如實說明

有些商戶可提供明確時限內的撤回途徑，作為提交前覆核以外的保障。W3C 的 G164 技術文件指出，頁面應說明網上要求可在多長時間內更改或取消，以及具體程序。文件內的時間只是例子，並非通用取消期限；不可直接搬進自家公司條款。應用真正政策，說明期限何時開始、哪些訂單不適用，以及可否網上處理或須使用另一個同樣可達的渠道。若某一步後已無法可靠地停止出貨，便不可承諾每張已確認訂單都能撤回。只寫「請聯絡我們」亦不足以讓顧客判斷實際選擇。

若提交後難以取消，商戶可以選擇在提交前提供覆核及修正。訂製產品、限額時段或某些難以退回的服務尤其需要清楚設計。重要限制應在最後按鈕前交代，摘要內容亦須與限制一致。不可把顧客勾選方格當成他已理解隱藏條款的證明。若使用方格，文字要具體，並在旁保留相關決定資料。W3C 在部分情況列出方格作為可用技術之一，但正式成功準則容許其他方法；應選擇真正幫助顧客避免這筆交易重要錯誤的方式。

提交後狀態也要讓客服看得清楚。顧客付款後立即發現地址錯誤，需要知道訂單是待出貨、已交承運商，還是付款仍待確認。員工未核實下游系統能否接受修改前，不應承諾可以改。須記錄顧客要求、當時訂單狀態及採取的動作，再清楚回覆結果。覆核頁可減少可避免的錯誤，卻無法消除所有修改要求。因此，負責人應同時測試提交前路線及提交後客服路線；涉及多個銷售渠道或物流伙伴時尤其需要。

用真實任務驗收最後確認

可用一個假設結帳任務驗收：顧客選一件產品、填送貨地址，進入最後覆核。確認前把數量由一改為二，檢查金額、預計送貨安排及受門檻影響的優惠是否一同更新。再修改地址，核實摘要顯示新地址而非舊資料。亦要用鍵盤及屏幕閱讀器測試，確保標題、修改控制項、更新後總額和最終操作不靠視覺掃描也可理解。例子中的數字只是測試輸入，並非轉換率量度結果。保存顧客當時所見內容與完成訂單紀錄，兩者應能講出一致的交易過程。

最後須測試例外情況：顧客按確認時，產品剛好缺貨或價格規則更新。公司要預先決定會否履行顧客剛覆核的報價、要求顧客重新確認變動後報價，還是清楚說明不能完成訂單；不可在顧客覆核舊總額後，暗中改用新總額。亦要檢查手機畫面、不同語言內容及連線中斷時的處理。負責人可先選一類有重大後果的訂單，請團隊示範三件事：完整決定看得見、每項重要資料可修改、完成訂單與確認摘要一致。這是按 W3C 準則制定的實際驗收，而非徒增一個裝飾性的頁面。