自訂購物車數量控制項，怎樣讓顧客選得準確？

先決定是否需要自訂控制項

數量欄位看似簡單，直到顧客要一次購買較多件、改正多按的一件，或發現存貨不足。只有加減圖示的介面，可能令輔助技術不知道現時數值，也會令直接輸入很慢。第一個決定，是能否使用有清楚標籤、合適最小值、最大值及步幅的原生數字輸入欄。MDN 說明數字輸入欄可驗證數值，而且瀏覽器通常提供增減控制，但不同瀏覽器的畫面及輸入體驗會不同。若設計上確需自訂組合，W3C 的 spinbutton 模式可作參考；它同時帶來鍵盤、名稱及狀態要求，必須實測，不能假定放上圖示便已完成。

選擇元件前要先定義銷售單位。逐件出售的貨品可由一件開始並以整數遞增；按包出售則可能需要不同步幅及顯示方式。本文例子假設逐件出售，示例存貨上限只供演練，並非任何商戶的真實庫存。數量零在有些店代表從購物車移除，在另一些店則屬無效值；應先公開決定。真正存貨限制與商戶設定的每客購買上限，也要分開並如實標示。如果結帳期間可用存貨改變，提交的數量應與最新供應情況核對，不能暗中調低而不告知顧客。

W3C 的 spinbutton 模式描述一個只接受特定範圍或離散數值的欄位，通常旁邊有增加及減少按鈕。上、下方向鍵可改變數值；有已知上下限時可考慮 Home 和 End。若容許直接輸入，正常的文字編輯按鍵也要保留。該模式提醒開發者，不可讓 JavaScript 攔截按鍵而破壞瀏覽器原有的編輯功能。這是一種設計模式，並不表示每個數字欄都要改寫成 ARIA 元件。W3C 示例亦明言程式碼只作示範，上線前須在不同瀏覽器與輔助技術組合測試，手機觸控尤其需要留意。

讓畫面與程式狀態一致

數量欄標籤應同時指出是哪件貨品，尤其購物車有多行相同控制項時。使用屏幕閱讀器的顧客不應只聽到三個都叫「數量」的匿名欄位。若採用自訂 ARIA spinbutton，要讓輔助技術知道現時數值及相關上下限；W3C 示例會更新 aria-valuenow，並使用 aria-valuemin 與 aria-valuemax。這些程式屬性須與畫面輸入及已接受的購物車資料同步。即使畫面提示正確，程式中的上限過時仍會誤導使用者。數值無效時，應把具體訊息連到該欄，讓顧客直接修正，而不用清空其他購物車項目。

加減按鈕需要包含貨品身分的清楚可存取名稱，不能只讓人聽到「加號」或「減號」。按鈕是否列入 Tab 順序，要按實際讀者及裝置測試。APG 示例以輸入欄作主要鍵盤停留點，同時讓旁邊按鈕可供觸控及語音操作；這個 Tab 設計是示例，不是所有商店必須照搬的規則。不論選哪種次序，按 Tab 時應能預測下一個焦點，焦點要可見，欄位亦要容許直接編輯。使用語音輸入的顧客，應能指明要增加或減少哪件貨品，而不用猜測重複圖示的意思。

還要決定顧客編輯的數字何時成為正式購物車數量。如果每按一個鍵便重新計算，顧客把 2 改成 12 時，途中暫時清空欄位可能被誤當成移除貨品或輸入錯誤。在離開欄位、按 Enter，或按明確的「更新」按鈕後才提交，往往較易理解，但必須清楚顯示尚未提交的數值與更新後總額。若加減按鈕即時更新，就要讓變更可見，並處理連續點按而不漏加或重複。伺服器反應慢時，不能讓控制項顯示一個數，訂單摘要卻用另一個數。團隊要訂明待處理變更能否繼續結帳，以及被拒絕時怎樣解釋。

一個購物車示例

假設商店逐本出售筆記簿。以下只是測試情境：顧客購物車已有兩本，當時可選範圍是一至八本；顧客因開會需要而輸入十二。欄位應保留這次輸入，讓顧客看到目前上限是八本，並清楚選擇改為八本或另作安排；不能暗中把十二改成八，卻令人以為訂到了十二本。如果最終提交前存貨再減至五本，伺服器必須重新驗證，說明只可接受五本，並在落單前讓顧客決定。這些數字只是示例條件，並非任何商戶的實際存貨，也不是統一的限購建議。

同一情境要換不同輸入方式重做。只用鍵盤時，移到欄位、修改內容、在選用模式承諾支援的情況下使用方向鍵，再提交。用屏幕閱讀器時，確認能聽到貨品名稱、現時數量與上下限，而且錯誤訊息能指出哪件貨品。觸控時，在窄屏幕試旁邊的按鈕與直接輸入。語音操作時，要能在多行購物車中指明正確的加減按鈕。最後重新載入，對照欄位、該行小計及伺服器購物車紀錄。這一步可找出畫面似乎已改，但真正結帳資料沒有改的問題。

數量控制項也不能遮蓋其他購買決定。若增加件數會改變送貨資格、優惠條件或總價，應按權威業務規則重新計算，並在提交訂單前顯示結果。若限制來自欄位以外的規則，要用平實語句說明原因；顧客合理地會區分暫時缺貨與每客限購。控制項不能保證將來存貨，它的職責是表達目前被接受的選擇，並誠實處理其後變動。即使供應情況在不同時間重新檢查，產品頁、購物車和最後訂單覆核仍應就銷售單位及提交數量保持一致。

用可觀察結果驗收

建立簡短驗收表：最小值、最大值、各界線內外的數值、空白輸入、只售整件時的小數輸入、直接打字、每個加減按鈕，以及編輯後提交前存貨改變。至少放兩行貨品，才能找出標籤含糊的問題。每個情況都記錄顧客輸入值、系統接受值、顯示訊息、該行價格及最終訂單資料。這些觀察能揭示畫面控制項與業務紀錄是否一致，也讓團隊處理數量出錯的顧客報告時，不必先假定是顧客自己按錯。

合格結果不只是開發人員電腦上的加號能加一。顧客要知道可選範圍、有效率地輸入或調整、能修正無效數值，並明白訂單會採用哪個數。承擔自訂 spinbutton 的維護成本前，先測試原生選項。確有需要自訂時，可從 W3C 模式起步，再以顧客實際使用的瀏覽器與輔助技術驗證。這項驗收專注數量選擇；購物車變動公告及最後結帳確認各有獨立的測試與失敗情況。