加入搜尋建議前，如何確保人人都能使用

先決定建議清單要解決甚麼問題

當顧客需要輸入商戶已知的目的地、服務地點或產品類別時，自動建議可幫助確認拼寫和可接受名稱；但它亦會令簡單搜尋欄多出浮動清單、額外網絡請求及選取規則。先看任務：顧客必須選擇預設值，還是可以用自己的字詞搜尋？若容許自由輸入，就不應暗中以第一個建議取代原文。若只能選預設值，應在畫面清楚說明，並提供可靠的瀏覽選項方法。

W3C 的 ARIA Authoring Practices Guide 區分可接受任意文字的可編輯組合方塊，以及只容許預設值的版本，也列出手動及自動選取等建議行為。這些選擇會改變使用者離開欄位時的結果。商戶應先用簡單文字確認規則，例如「顧客輸入地點後按搜尋，除非明確選了建議，否則使用原本輸入的字」。有了共同預期，設計、開發及測試才不會各自猜測。

加入元件前，可先與有清楚標籤的普通搜尋欄比較。若目錄很小，顧客不用預測也能找到資料，較簡單的控制項或許更易維護和測試。若建議確有幫助，應列明字詞來源、更新方式、建議代表產品還是分類，以及缺貨項目會否出現。建議字詞不應被視為保證有貨或保證價格；顧客選取後，仍應到最新結果頁核對實際資料。

讓輸入欄有清楚名稱和穩定意思

畫面上的標籤應說明搜尋對象是目的地、產品還是協助主題。提示文字在輸入後會消失，不能可靠代替標籤。W3C 範例把 HTML 標籤連結至輸入欄；其 WCAG 指引亦說明，使用者需要可感知的標籤或指示。可存取名稱應與可見標籤一致，讓語音輸入和讀屏使用者面對同一任務。若只能從清單選城市，應在提交前說明，而非等到錯誤出現才揭露限制。

建議清單出現時，輸入欄與清單之間應有輔助技術能理解的關係。APG 的清單建議範例使用 combobox 輸入欄、listbox 清單、反映展開狀態的 aria-expanded、指向清單的 aria-controls，以及在輸入欄保留鍵盤焦點時指出目前選項的 aria-activedescendant。這些屬性需要與實際狀態同步，不能當作裝飾貼上。若團隊無法維護動態狀態，原生控制項或較簡單的搜尋可能更可靠。

驗收準則要涵蓋最後提交的值，而不只看清單外觀。顧客輸入後送出哪段文字？用方向鍵移到選項再按 Escape，原文會否保留？選定建議後，所選值是否可見並可修改？清空欄位時，舊建議會否消失？這些問題可找出截圖無法顯示的錯誤，也可避免後端收到與顧客眼前文字不一致的內部選項編號。

不用滑鼠也能預測選取結果

APG 的組合方塊模式把輸入欄放在正常 Tab 順序，說明可用向下鍵進入建議、Escape 關閉清單，以及在可編輯組合方塊中用 Enter 接受已選建議。部分按鍵屬可選行為，須按採用的模式記錄，不應聲稱所有組合方塊完全相同。基本要求是顧客不用滑鼠，也能輸入、發現及瀏覽建議、選定或關閉清單；若容許自由文字，也能直接提交原文。

不要讓 Tab 鍵逐項困在每個建議之內。APG 範例讓 DOM 焦點留在文字欄，透過活動後代指出反白選項，使一般文字編輯按鍵仍可使用，Tab 亦能前往下一個控制項。清單展開時離開欄位，要檢查結果：若採手動選取，就不應把顧客未確認的反白選項偷偷提交。畫面反白、最後選值及讀屏播報必須一致。

可由空白欄位開始測試：用 Tab 移至搜尋欄，輸入部分字詞，以向下鍵瀏覽結果，按 Escape 後提交；再重試一次，用 Enter 選項。之後以觸控及讀屏工具重做，記錄欄內文字、讀出的選項及最後送出的請求。沒有相符建議時也要測，避免殘留幽靈選項，或阻止原本可以進行的搜尋。

讓不斷改變的結果仍可理解

建議可能在每次輸入後更新；較舊的網絡回應有時會在顧客輸入更多字後才到達。若舊結果覆蓋新結果，反白選項可能突然指向另一個字詞。應把結果與當前輸入配對，捨棄過期回應；延遲資料不能暗中改變已選值。載入提示可以幫忙，但不應把焦點從輸入欄奪走。建議數量亦宜易於瀏覽，免得鍵盤使用者花很久才到達頁面其他部分。

清單要有清楚的「沒有相符項目」及服務失敗處理。若仍容許自由搜尋，沒有建議不等於顧客拼錯，不應當作輸入錯誤。建議服務暫停時，搜尋欄與提交操作仍應可用。若必須選預設值，則要提供另一個清單或清楚的修正途徑。這樣便利功能不會阻斷主要任務，也不必為了避免空清單而顯示過期建議。

以旅遊查詢作示例：顧客輸入建議清單沒有的地區名稱。若網站支援一般搜尋，按搜尋應使用原本字詞，再顯示結果或有用的無結果處理。若欄位實際用途是選出發機場，畫面便應說明只能選清單內機場，並提供可瀏覽選項。這是兩種不同業務規則；清單設計再漂亮，也不能彌補提交規則不清。

以範例起步，再用真實操作驗收

W3C 明確指出其範例只供示意，瀏覽器與輔助技術的組合可能有差異，尤其是手機與觸控環境。因此複製範例標記不等於完成正式驗收。應在顧客實際使用的瀏覽器和輸入方式測試，涵蓋純鍵盤、讀屏、觸控、放大畫面，以及英文和繁體中文的標籤與建議。較長地名也要檢查，避免關鍵區分字眼被截斷。

發布清單應具體可觀察：欄位有可見及可存取名稱；建議對應目前字詞；展開狀態及目前選項準確；鍵盤可開啟、移動、選擇和關閉；容許自由文字時原文獲保留；建議服務故障時仍有可用路徑。每項都配一個實際測試，不要只寫「元件無障礙」。截圖或短片可協助重現問題，但測試資料不應包含真實顧客資料。

最後由負責人回答兩個問題：建議清單是否確實協助顧客辨認有效字詞或路線？顧客是否不用猜測清單行為便能完成搜尋？若答案未明，應與普通搜尋欄再比較並實際測試。選定的互動模式要記錄下來，免得日後調整排序、資料來源或外觀時，悄悄改變 Enter、Escape 或離開欄位的意思。

雙語搜尋除了翻譯標籤，還涉及資料管理。香港顧客可能用繁體中文、英文或常用簡稱輸入地點；不同寫法可以指向同一目的地，但畫面應顯示足夠資料讓人辨別。應測試各種別名是否到達預期結果、相近名稱有否清楚區分，以及讀屏工具能否讀出選擇所需的資訊。不能要求顧客記住中文介面從未介紹的英文拼寫。產品或服務區域更新時，也要同步維護別名；驗收時同時核對顧客看到的名稱與實際送到後端的識別碼。若建議清單按人氣排序，應檢查排序變動後鍵盤反白位置與讀屏播報仍然一致，並確保沒有建議時，原本容許的自由搜尋仍可完成。

建議字詞的資料來源亦需要負責人。地點關閉、服務範圍改變，或兩個名稱合併成別名時，應更新清單，並檢查舊連結仍能到達有用結果。只有取得真實數據時才分析搜尋紀錄；某字詞被反覆搜尋可以提示測試方向，卻不能證明自動建議就是解法。可請顧客或職員測試者說明輸入、反白及提交後各自預期發生甚麼，再與實際結果對照。這種觀察比單純計算畫面顯示了多少建議更能找出誤解。