網站導覽選單如何讓鍵盤及觸控使用者找到目的頁？

先定導覽結構，再定互動方式

顧客使用網站導覽是為了找到目的頁，不是操作桌面程式的選單。先列出真正的目的地，決定哪些連結應放在最上層。網站頁面不多時，直接顯示連結可能比摺疊選單更清楚。若需要分組，要決定父層名稱本身會連到總覽頁，還是只用來展開子連結。前者通常需要把父層連結與展開按鈕分開。W3C 的指引指出，一般網站導覽的展開模式，毋須採用代表複雜應用程式選單行為的 menu 或 menubar 角色。不能因設計稿稱它為「選單」，就隨意加入那些角色。

桌面與手機版應維持一致的目的地層級。窄畫面可以把部分群組放進有清楚名稱的控制元件，但連結用語、次序及目標頁面仍應容易辨認。W3C 的選單結構教學建議不同螢幕尺寸保持一致結構。若滑出選單對部分使用者難以操作，重要子頁也應有其他入口，例如實用的父層總覽頁。目標是讓手部操作不靈活、使用放大顯示、窄畫面或點按失準的人仍可到達目的地。內容負責人也要參與決定，因為控制元件即使技術上可操作，也無法補救難懂的分類名稱或缺失的目的頁。

用連結前往頁面，用按鈕展開內容

連結應負責前往頁面，按鈕應負責顯示或收起子連結。若父層本身有總覽頁，應保留它的連結，旁邊另設有明確名稱的展開按鈕；W3C 的滑出選單指引直接說明這種情況。按鈕要以 aria-expanded 告知受控群組是開啟還是收起，數值必須跟畫面同步。子連結放在相應父層下的普通清單，需要時把整組放進有名稱的導覽區域。視覺上已收起的連結，不應仍然可以按 Tab 聚焦。即使樣式有所變動，基本 HTML 結構也應合理；程式控制狀態時，畫面與輔助技術讀到的狀態要一致。

不能只靠滑鼠懸停才顯示子連結。這假設使用者有指標裝置，對觸控、鍵盤或移動不夠準確的人都可能失效。W3C 建議為滑出目的地提供其他到達方法，也說明鍵盤啟動方式。原生按鈕本來就能以 Enter 和空白鍵啟動。展開後，Tab 應可逐一走過可見連結；收起後，下一個 Tab 位置應是下一個有用控制，而不是隱藏的子項。W3C 的展開式導覽範例可用 Escape 關閉並把焦點返回控制按鈕，但仍須在實際網站測試，不能直接複製範例程式便當作完成。

讓焦點、狀態與目的地一致

可見焦點標示要與導覽背景有足夠分別，也不能被固定頁首或已展開面板遮住。從全新載入頁面開始，測試正向與反向 Tab 次序；展開群組後及點入子頁再返回時也要重測。若導覽顯示目前頁面，視覺提示應一致，並可採用合適的目前頁面標記；W3C 有說明 aria-current 的用途。展開按鈕的名稱要足夠具體，讓螢幕閱讀器使用者知道它控制哪一組連結。若每組都只叫「更多」，使用者便要自行猜測背景。

要先決定使用者打開第二組或離開導覽時，原有群組如何處理。關閉第一組可減少雜亂，但不要突然把焦點移到遠處。如果面板覆蓋頁面內容，在測試的放大比例及畫面寬度下，不能遮住目前聚焦的連結。手機版抽屜開啟後，與頁面的焦點關係和關閉方式也要另行設計，不能假設桌面下拉行為自然適用。W3C 範例只供說明，並提醒要在目標瀏覽器及輔助技術組合測試。因此設計審核須包括實際鍵盤及螢幕閱讀器試用，不能只依賴靜態掃描。

以尋找目的頁的任務測試

設想一間香港維修店，頂層導覽有「服務」、「收費」和「聯絡」。服務本身有總覽頁，下面另有家居維修及商業保養連結。桌面鍵盤使用者先到達「服務」連結，再到有清楚名稱的「顯示服務連結」按鈕。啟動連結會進入總覽；啟動按鈕才顯示兩個子連結。使用者可按 Tab 進入子項、前往頁面，或收起群組再走到收費。窄畫面的手機版亦應以清楚名稱的導覽控制顯示相同目的地及次序。這是定義預期行為的假設案例，並非已觀察到的顧客數據。

測試時不要只說「試選單」，應給具體任務：不用滑鼠找到商業保養頁、返回後只用觸控找到收費頁，以及在窄畫面放大狀態下用螢幕閱讀器找到聯絡頁。觀察測試者預期父層連結會去哪裏、展開狀態有否讀出、可見焦點是否跟隨鍵盤，以及能否關閉面板而不失去位置。任務失敗可能是名稱或層級不清楚，未必是 JavaScript 壞了。把問題記成「哪個目的頁無法到達」，再決定修改結構、用語、互動，或三者一起修改。

用不同操作方式核對同一組目的地

發佈驗收應在寬窄版面逐一走過所有頂層項目，以及每組至少一個子連結。核對連結是否到達正確網址、按鈕是否只負責展開、讀出的狀態是否與畫面一致、隱藏項目是否退出 Tab 次序，以及焦點有否消失或被遮住。按實際設計測試 Enter、空白鍵、Tab、Shift+Tab、Escape、滑鼠點擊及觸控。W3C 範例的方向鍵操作屬附加功能，不能變成到達連結的唯一方法。還要把正式頁面的目的地與核准網站地圖核對，避免控制元件雖然易用，卻悄悄漏掉重要服務頁。

為日後內容變動保留簡短決策紀錄：頂層名稱是甚麼、各父層是目的頁還是展開控制，以及新增子連結由誰核准。新增服務時，不必自動再加一層巢狀選單；應先考慮父層總覽、頁面內容或搜尋是否提供更簡單的路。翻譯改動後也要重看導覽，中文標籤可能以不同方式換行，或需要更具體的輔助名稱。業務負責人的下一步是選定三項高價值的目的地任務，觀察真實鍵盤與觸控測試，修復任何令訪客迷失路徑的位置。

一個實用的設計檢查，是在修飾動畫之前，先用真實訪客問題對照導覽。顧客想知道維修店會否處理辦公室設備時，能否預測答案在哪個頂層名稱之下？名稱含糊，即使按鈕完全正常，仍會迫使人反覆開關。請內容負責人從訪客角度命名每一組，減少目的地重疊。若沒有充分原因，同一目的頁不應在頁面標題、父層總覽及導覽連結中使用互不相同的名稱。雙語網站應分別檢視兩種語言的字數及閱讀習慣，而非機械翻譯其中一版。短標籤雖方便排版，離開上下文由螢幕閱讀器讀出時卻可能不知所指。名稱或層級一改，就重新執行三項目的地任務，在新路線核實之前保留原有可達入口。

測試控制元件時要使用接近正式網站的內容。長度相近的假文字，可能掩蓋中文服務名稱換行或英文分類較長時才出現的問題。在測試的放大比例下，檢查展開群組仍與控制按鈕在視覺上相連，連結不被容器裁走，而且收起方法容易找到。若設計由橫向連結切換為手機抽屜，應記錄切換寬度，並在邊界附近測試，不要只測極寬螢幕與小手機。訪客亦可能在選單開啟後旋轉裝置或放大文字；要確認狀態仍清楚，目的頁仍可到達。這些測試把介面操作與訪客真正要作的決定連起來。

推出後若收到導覽投訴，應把它當作任務證據。詢問訪客原本要到哪頁、選了甚麼名稱，以及在哪一步迷失。不能只靠點擊次數判斷成功；反覆打開多組連結，可能正好說明分類名稱不清楚。按這些觀察修改結構後，重新執行相同任務，核實使用者能否更直接到達目的頁。若中文與英文使用者遇到不同困難，亦應分別修正，而非只調整其中一版。