網頁操作載入期間，顧客應看到甚麼？

先釐清正在等待甚麼

轉動圖案只表示畫面有動態，卻未說明系統是否接收要求、工作是否仍在進行，以及顧客何時可以繼續。先列出具體操作：開啟產品清單、套用篩選、載入帳戶資訊，或前往表格下一步。每項操作都要界定要求何時開始、甚麼結果才算完成。等待訊息應指向工作本身，例如「正在更新產品」，而非每個頁面都只寫「請稍候」。W3C 的狀態訊息指引說明，沒有轉換畫面情境而顯示的等待、進度、成功及錯誤資訊，都可能屬狀態訊息；因此文字內容及輔助科技能否取得資訊，都是顧客流程的一部分。

要分開處理整頁導覽與頁面內的小範圍更新。開啟新頁面時，瀏覽器通常已有載入及文件切換提示；但前端局部更新會讓舊內容留在原位，等待新資料回來。若沒有清楚說明，顧客可能誤以為舊產品清單已套用新篩選。團隊要決定等待時是否保留舊內容、降低其顯著程度，或暫時停止操作，並以文字交代。不能因舊卡片仍顯示，就讓顧客誤以為最新存貨已確認可訂。本文處理即時頁面操作；長時間的上載和匯出則需要另設工作追蹤及復原設計。

根據可量度資料顯示進度

只有系統真正掌握工作進度，才應顯示百分比。例如下載已知總位元組數的檔案，可以計算傳輸比例；但該數字仍只代表傳輸，未必包括其後處理。伺服器處理時間未知的產品清單要求，不能因計時器走了七秒，就宣稱完成七成。無法量度時，應用不確定進度的等待狀態，並標明正在做哪件事。MDN 的進度列說明指出，不確定進度不應提供 aria-valuenow，並建議在合適情況優先使用原生進度元素。若系統真的掌握進度，也要先定義分子及分母代表甚麼，再把數字交給顧客。

假設篩選流程可觀察到三段：送出選擇、收到符合條件的產品、完成卡片顯示。只有程式真的能確認各段狀態，才可用「三個步驟」描述；不能為了好看，讓進度條按固定時間自行前進。較實用的做法是要求開始時顯示一句簡短訊息，完成後改為更新後的結果數量，或可採取行動的錯誤訊息。訊息要維持足夠時間讓人讀懂，頻繁閃動只會增加干擾。若要估計時間，必須基於可靠的運作資料，並清楚標示只是估計；不能憑感覺編出數字。

讓狀態可知而不搶走焦點

頁面局部更新時，看得到畫面的人可能注意到轉動圖案或卡片變化，但讀屏器使用者可能完全收不到有用提示。W3C 的狀態訊息準則關注的是，不移走焦點，也能透過角色或屬性辨認的訊息。一般載入要求應有簡短而適當可宣讀的開始及完成文字，不必每次都把焦點搬到轉動圖案。日常等待亦不宜使用過分緊急的警示方式，否則會打斷顧客正在選擇其他選項。畫面可見文字與宣讀內容應一致。空白骨架卡片只是一種視覺佔位，不能獨自交代工作狀態。

若同一區域的多個部分先後更新，不應把每一塊未完成內容都當成最終答案讀給顧客。MDN 說明，可用 aria-busy 標記正在更新的區域，完成後取消標記，減少輔助科技過早宣讀局部變化。但這不能取代清楚的工作名稱及完成狀態。標記應放在真正更新的區域，不應無差別套在整頁。成功、失敗及取消三種路徑都要確認會清除忙碌狀態；若一直維持忙碌，之後的內容變化可能難以察覺。理想順序是顧客明白要求已接收、內容更新中，最後得到實際結果或清楚的失敗原因。

避免等待畫面誤導顧客

新結果尚未回來時，要決定顧客仍可做甚麼。產品篩選欄可以繼續編輯，讓顧客改變選擇；但第二個要求發出後，較舊的回應不能覆蓋最新選項。結帳價錢核對則可能需要暫停最終付款操作，直到已核實總額返回。這些都是系統狀態決策，不是轉動圖案本身能解決的。畫面應顯示目前正在套用哪個選擇，避免把舊資料當成新資料。要求失敗時，要結束等待狀態，保留顧客的選擇並提供重試；同時說明畫面是否仍保留舊結果，免得顧客誤以為它是失敗要求產生的內容。

可用一個示例說明差別。顧客在產品目錄選擇「有貨」及「符合預算」，要求處理期間，舊的未篩選卡片仍短暫顯示。介面寫明「正按你的條件更新產品」，並把結果區標示為更新中。收到回應後，才替換卡片、宣讀實際結果數量，並解除忙碌狀態。若要求逾時，就要說明篩選未成功套用，保留已選條件並提供重試。團隊沒有虛構完成百分比，也沒有根據舊卡片聲稱產品仍可購買。這只是測試情境，不是觀察所得的顧客成果，也不代表任何特定零售商。

測試等待狀態的每個出口

驗收至少包括快速成功、緩慢成功、沒有結果、網絡失敗及取消。每一種情況都記錄可見文字、讀屏器宣讀內容、焦點位置、仍可使用的控制項，以及最後呈現的資料。快速回應不應讓指示器一閃即逝，變成無意義的干擾；較慢回應則需要足夠背景，讓顧客知道操作沒有消失。「沒有結果」是要求已完成而沒有符合項目，不是無止境載入。失敗時必須結束等待畫面並指出下一步。若顧客連續更改兩次篩選，也要確認最後顯示只由最新要求決定。

同一套測試要在窄螢幕、鍵盤操作及讀屏器環境重做。檢查顧客捲動時能否找到等待文字、控制項是否無說明地變灰，以及焦點保持不動而內容更新時會否有適當宣讀。進度列要有清楚的可及名稱；任何數值都須對應實際可量度工作。若原生進度元素已能滿足需要，應先測試它，才考慮自行加入 ARIA。英語及繁體中文訊息要分開審閱：「載入」、「更新」與「完成」是不同狀態，含糊翻譯會令三者混成一句。狀態數目保持精簡，往往比複雜動畫更容易維護。

交付真實的狀態模型

驗收紀錄可寫成狀態圖：閒置、已接收要求、等待、成功取得結果、成功但沒有結果、失敗，以及系統支援時的取消。每次轉換都列明顧客看到甚麼、輔助科技可辨認甚麼，以及哪份資料才是權威結果。完成訊息必須連到真實工作完成，而非動畫計時器。團隊應能在測試環境重現緩慢與失敗路徑，確認兩種語言都有相同而誠實的行為。若系統無法量度進度，準確而具體的等待訊息已是一個完整設計選擇。顧客需要的資訊，是足以決定繼續等待、重試、更改要求或使用已返回結果。

還要規劃顧客未等完成便離開的情況。若他切到另一個分頁再返回，畫面應反映最新實際狀態，而非重新開始轉動，令人誤以為工作又做了一次。離開頁面再回來時，系統要麼還原有效的已完成結果，要麼重新發出要求並誠實標示新一次等待。已取消的要求，之後不應替從未顯示的內容宣讀成功。程式可能需要要求識別碼或只接受最新回應的檢查，以免舊回應在競逐中勝出；對編輯驗收而言，原則是文字、控制項與顯示結果都必須對應同一個顧客選擇。

客服要能重現「篩選一直轉」的投訴，卻不能把轉動圖案當成工作已完成或仍在進行的證據。底層要求可能失敗、已完成但沒有渲染，或已被較新的選擇取代。內部診斷應分辨這些路徑，同時避免把不必要的顧客資料寫入紀錄。公開介面中的重試，也不能在控制項仍顯示舊選擇時，暗中提交另一組條件。審閱時應把工作名稱、所選參數與最終結果一起核對。這亦可避免新內容尚未可用，畫面卻先樂觀地顯示「完成」。可靠的結果，是顧客能據此作決定的畫面，而不只是動畫終於停下來。