訂明真實狀態
背景工作即使正常運作，也可能令顧客不知所措。檔案上載、報表匯出或設定儲存開始後，按鈕仍在原位，結果卻可能稍後才在另一處出現。看得到畫面的顧客或會注意到轉圈圖示或顏色改變；使用螢幕閱讀器的人，則可能完全不知道工作已開始或完成。第一個設計問題是：顧客要知道甚麼才能繼續？是系統已接收、仍在處理、已完成、失敗，還是需要下一步操作？把這些狀態以普通文字顯示在工作附近，並讓輔助技術取得有意義的變更。W3C 的 WCAG 2.2 指引把成功、警告及進度訊息列為可在不轉移焦點下傳達的狀態資訊。這裏處理的是非同步工作的溝通，不能取代另一項責任：指出並解釋表格欄位的輸入錯誤。
先把工作生命週期列出，再決定使用哪種 ARIA 屬性。寫下每次狀態轉換，以及系統是否真的知道當前進度。上載可能先等候連線、傳送位元組、接受伺服器驗證、進行掃描，最後才獲接納或被拒。若位元組剛送達就顯示「完成」，但伺服器之後拒絕檔案，訊息便失實。報表匯出要求可能即時獲接收，但檔案仍在佇列準備。要區分「已收到要求」與「可下載」，若處理需時，還要讓顧客稍後找回結果。處理時間未知時，用真實的「仍在處理」訊息，不要虛構百分比。進度列只有在數值代表可量度的進度，而且終點與真正工作結果一致時，才有幫助。
一般更新可用較溫和的狀態通道，讓螢幕閱讀器在目前語音結束後宣讀。W3C 的文件列出 role=status 可用於成功訊息或應用程式狀態，也列出以即時區域傳達進度的做法。可在用戶操作前就在頁面建立持續存在的狀態容器，狀態改變時更新其中的文字；但仍須用顧客實際使用的瀏覽器和螢幕閱讀器組合測試。可見文字應是共同事實來源，讓看畫面和聽語音的顧客得到相同結果。不要只因「上載中」變成「已上載」便移走鍵盤焦點。除非介面真的轉換情境，例如開啟須即時處理的對話框，否則焦點應留在顧客正在使用的控制項。只有無聲轉圈圖示不足夠；不停宣讀秒數亦會分散注意力。
在不干擾下通知
重要而且有時效的中斷才使用警示。W3C 的 alert 模式描述一種吸引注意而不奪走鍵盤焦點的簡短訊息，同時提醒開發者避免過密中斷及太快消失的警示。上載失敗而需要即時重試，可能適合精簡警示；「百分之二十、二十一」之類的一般進度則不適合。若問題需要顧客作決定，應保留訊息並提供可操作控制，而非一閃即逝的提示。說明甚麼失敗，以及哪些資料仍已保存：「檔案未附上，表格資料仍在」比單說「錯誤」有用。元件重新顯示時，不要重複宣讀同一失敗。若用戶必須查看新面板，應按該互動刻意管理焦點，而非把每次狀態變更都當成警示。
以診所預約前上載文件為例。介面先顯示「正在上載」，傳送後改為「正在檢查」，只有伺服器真正接受後才顯示「檔案已附上」。若驗證拒絕檔案，應說明系統實際能確認的原因，提供重試控制，同時保留預約草稿其他內容。若網絡在伺服器確認前中斷，即使本機進度列走到盡頭，也不可宣稱成功。顧客應能查看附件清單，作為結果的持續紀錄。員工匯出報表亦類似：可依次顯示「要求已排隊」、「正在準備」及「可以下載」，並提供稍後可找回的連結或通知紀錄。這些文字應跟隨系統實際狀態，而非動畫狀態。
兩種網站語言的狀態文字都要具體。英文只寫 Done、中文只寫「完成」，顧客未必知道是上載、掃描、提交還是預約完成。應講明對象與動作，例如「收據已上載；預約尚未提交」，並寫出自然的繁體中文版本。於狹窄手機畫面測試較長的中文句子，確保訊息末尾不被遮住。若頁面可同時上載多個檔案，每個狀態要與相應工作關聯，避免顧客把某份文件的完成誤認為另一份。不要單靠顏色；文字和圖示可互相補充。若畫面顯示進度值，供輔助技術讀取的名稱和數值也應指向同一工作。只在有意義的狀態改變時更新，免得輔助技術不停朗讀實作細節。
測試完整流程
驗收要走完整段旅程，而非只截取一個畫面。先把鍵盤焦點放在操作控制上，啟動工作並等到完成；再以延遲回應、驗證失敗及斷線情況重試。每次狀態轉換，都要確認可見與朗讀訊息一致、焦點沒有意外跳走，而且顧客可在不失去其他工作的情況下恢復。英文與繁體中文都要重做。要用真實螢幕閱讀器和瀏覽器組合測試，單看標記無法證明實際會朗讀甚麼。亦要檢查遲到的伺服器回應會否覆蓋新一次嘗試的狀態；顧客重試後，介面必須把結果對回正確請求。紀錄應描述顧客完成了甚麼、遇到甚麼缺陷，而非只勾選 DOM 中有某個 ARIA 屬性。
可以先選一項重要操作，例如文件上載或發票匯出。請同事列出伺服器真正會出現的狀態，以及顧客在各狀態需要作甚麼決定；為每個狀態寫可見訊息，然後選擇適當的無障礙宣讀機制。還要提供可持續查看的結果位置及失敗後的恢復路徑。上線後可留意客服工單中重複按掣、放棄工作或詢問「有沒有儲存」的情況；這些線索或能指出訊息不清，但本身不能證明無障礙成效。W3C 的狀態訊息準則要求程式能辨識狀態，而毋須移動焦點；其 alert 模式亦提醒避免不必要的中斷。實際目標很簡單：每個人都知道商戶是否已收到操作、甚麼仍待處理，以及下一步應怎樣做，不用靠猜測轉圈圖示。
介面亦要說明離開頁面後會怎樣。若報表在關閉分頁後仍由伺服器繼續處理，要告訴用戶結果會在哪裏出現，以及是否必須重新開頁。若關閉分頁會取消只在瀏覽器進行的傳送，離開前便要說清楚。不可只靠短暫提示，作為提交要求等重要操作成功的唯一證明；若系統支援，應提供固定參考編號或可見歷史紀錄。系統故障時，要區分「暫時無法確認已收到」與「確定沒有收到」；前者在重試前應先查核，以免重複建立工作。業務團隊亦須覆核這種區分，因為只有他們知道重複要求的後果。因此清楚的狀態文字依賴準確的後端狀態和恢復設計，不只是前端標記。
更改正式系統前
- 每項訊息是否反映伺服器真實狀態？
- 螢幕閱讀器用戶可否在不失去焦點下得知重要變更？
- 失敗後用戶能否找回結果或重新處理？
