Base UI 可篩選選單：真正的設計細節在語意、焦點與鍵盤情境

來源與查核範圍

Threads來源為@maylogger_designer／DefFsNikiyh，機器時間2026-10-14T19:02:42Z；連至Base UI團隊Jenna Smith與James Nelson於2026-10-14發布的Building a filterable menu that works for everyone。本次已讀官方全文、目前Menu文件，以及W3C APG的Menu與Combobox說明。

公開頁可見usecubic的DegEu6EmZ-B留言稱讚hover自動focus；這是使用感受，不是測試報告。留言coverage為partial，未看到作者續文；頁面推薦的其他設計貼文沒有混入本篇。Threads附件為官網文章預覽，本篇沒有把它當成獨立實測影片。

三個關鍵設計決策

先問是選值，還是執行命令

W3C APG描述的combobox是取得欄位值的控制元件；menu則提供動作與相關選項。兩者可能都能輸入、按方向鍵，但不能只因外觀相似就互換語意。Base UI在這個案例選擇dialog包含searchbox與menu，讓Rename／Duplicate等仍作為命令，而不是假裝選取一個搜尋欄位值。

DOM焦點、視覺高亮與閱讀位置不能混為一談

官方案例讓DOM焦點留在輸入框，以aria-activedescendant標示目前項目。Home／End則依高亮情境處理：瀏覽項目時跳到邊界，回到輸入情境才移動文字游標。這是該元件的互動設計，不是所有選單或dialog都應照抄的通則。

Hover不是立刻把焦點搬走

滑過父層的子選單入口，只預覽，不立即搶走輸入焦點；指標真正進入子選單才聚焦其輸入框。鍵盤明確要求進入時則可立即聚焦。原留言的舒服，對應的是意圖判斷，而不是所有hover都自動focus。

從文件到規範：不要把API存在當成驗收通過

目前官方Menu文件可讀到Menu.FilterProvider、Menu.Input、Menu.List等分工，顯示這是整組互動模式的opt-in，而不是單一input自行改變整個選單。文件存在不等於專案已安裝相同版本；本次也沒有安裝套件或確認任何既有產品的實作。

W3C APG的Menu模式用方向鍵處理項目導覽，Tab／Shift+Tab通常是離開menu而非逐項走訪。這可當檢查方向，但仍須按具體元件結構、輸入欄位與輔助科技測試；不能把Base UI的dialog理解成必須套用一般模態對話框的焦點陷阱。

可重用的設計與測試清單

以下是本篇建議的驗收方法，不是本次已跑過的結果。先做狀態表，逐一標出目前意圖、DOM焦點、高亮項目、螢幕閱讀器可理解的控制元件、下一個按鍵效果及離開路徑，再用測試驗證：

• 不要只檢查畫面：同時記錄實際activeElement、可及性角色、名稱、狀態與觸發的動作。
• 測情境切換：輸入一半再瀏覽項目、回來修改、快速切換子選單，確認下一個按鍵沒有落到錯誤目標。
• 測中文輸入法：組字、選字與確認期間，不應誤執行選單命令；另測貼上、選取文字與游標編輯。這是建議測項，沒有宣稱已在各IME通過。
• 測資料變動：篩選後原項目消失、沒有結果、停用項目與長列表，檢查高亮及命令是否仍指向正確對象。
• 測不同操作方式：滑鼠、純鍵盤、觸控與實際螢幕閱讀器分開測，包含進入、返回與退出，而不只測搜尋能否找到項目。
• 保留重現條件：記錄瀏覽器、OS、輔助科技與套件版本；發現問題後以同一組案例回歸，不把單一demo順暢當成跨平台保證。

閱讀這篇的方式

把它當作設計推理案例：每個細節都要能回答使用者此刻想做什麼、系統怎麼辨識、結果怎麼被感知。審查介面時，除了問好不好看，也要問情境是否可見、動作是否可預期、錯誤是否可恢復，以及不同操作方式能否完成同一任務。

本次只有來源與規範閱讀，沒有執行Base UI範例、建立測試專案或完成VoiceOver／NVDA／JAWS／TalkBack實測，也不是WCAG符合性認證。官方文章中的互動展示、團隊回報與本篇建議測項需分開看。