目錄搜尋完成了，使用屏幕閱讀器的顧客知道嗎？

先定義顧客怎樣才算完成搜尋

以一間售賣相機配件的香港專門店為例：顧客輸入濾鏡尺寸後，商品格已更新，耳機卻沒有結果提示。他可能以為仍在載入，亦可能再輸入一次。這是建議用來驗收的情境，並非客戶個案。店主可以把要求收窄為一個可觀察的結果：最新搜尋完成後，顧客能知道有沒有合適商品，並自行前往結果，毋須重新找回輸入位置。

若顧客常靠逐步收窄條件尋找配件，而且團隊有能力維護背景請求，保留即時搜尋有其價值。相反，未輸入完整型號便出現大量無關結果，或現有網站主題難以修改，加入「搜尋」按鈕可能更切合預算。按鈕只是讓觸發時機清楚；若結果仍在同一頁更新，完成提示仍須處理。跳轉到另一個結果頁則要另測顧客能否掌握新頁內容。先比較這些做法，再決定是否更換搜尋元件。

提示狀態，讓顧客自行閱讀商品

W3C 對 WCAG 2.2 第 4.1.3 項的說明，重點是讓輔助技術毋須取得焦點，也能呈現狀態訊息。結果數量屬於這類提示，整份商品清單則是另一回事。指引要求程式能辨識已有的狀態訊息，並非每處更新都要新增廣播；過多提示亦會造成干擾。以下驗收只針對搜尋流程，不能據此宣稱整個商店符合 WCAG。

交給開發者時，可參考 W3C 的 ARIA22 技術文件：在訊息更新前已存在的容器設定 role=status，透過 polite 的即時區域行為提示狀態，毋須移動焦點。明確設定 aria-atomic=true，有助不同環境讀出完整意思。商品卡片應放在狀態容器之外。驗收時請開發者實際示範讀出效果，不能只看程式內有沒有某個屬性。

把不同結果的提示先寫清楚

先準備內容固定的測試目錄，讓店員與開發者都知道應有多少結果。下表的數量及字句只是驗收範例，不代表商店的實際數據。提示須對應最新已完成的搜尋，並與畫面商品一致。若有分頁，要分清全部符合條件的商品數量與本頁顯示數量。連線失敗亦不能當作「找不到商品」，否則顧客會白白修改原本有效的關鍵字。

英文、繁體中文各自完成一次任務

預留一次短測試，邀請平日使用屏幕閱讀器的人參與，並記下裝置、瀏覽器、閱讀器版本及語音語言設定。某個組合通過，不等於其他組合都有相同表現。英文版與繁體中文版應分開走完整流程；中文尤其要測實際選字輸入，不能只貼上寫好的詞句。讓參與者自行說明何時認為搜尋已完成、下一步想做甚麼，主持人不要先提示答案。

1. 搜尋後瀏覽

   輸入測試字詞後停下，聆聽等候及完成提示，再用鍵盤前往商品。更新本身不應把焦點拉到結果區。

2. 更改及清除條件

   套用篩選、搜尋沒有結果的詞，再清除條件。核對提示與畫面數量，確認能操作修正條件的控制項。

3. 測試回應先後顛倒

   請開發者延遲較早的請求，再輸入新字詞。舊回應較遲抵達時，不應覆蓋新商品或讀出過時數量。另模擬請求失敗，再測重試。

4. 按平常速度輸入

   中文須包括選字過程。記錄重複、打斷操作或語言錯誤的提示，修正後再分別重測兩個版本。

問題紀錄應列出可重現的字詞、畫面結果、實際讀出的內容，以及當時焦點位置。開發者需要排除過時回應，並合併密集更新。稍等顧客停止輸入才搜尋，是可測試的做法；等待時間要配合真實打字及中文組字過程調整。不要為了確保聽到，就把一般數量提示一律設成緊急警報。驗收的重點是顧客得到有用提示後，仍能順利繼續原本的操作。

把結果整理成可交付的修改要求

下一步，把測試字詞、雙語提示表及問題紀錄交給供應商。要求分別估算修正即時搜尋，以及改成按鈕提交的工作，兩者都要包括約定環境的重測。交付條件應寫清楚：顧客聽懂最新結果、舊回應不再干擾，而焦點由顧客控制。其他雙語流程問題可另列工作，讓這次修改有明確負責人及完成標準。下方指南可協助安排較全面的檢視；若需要外部設計支援，服務頁可作整理需求的參考。