固定頁首或橫幅遮住鍵盤焦點：如何檢查與修正

先分清甚麼情況出問題

顧客用 Tab 鍵逐項瀏覽預約頁時，焦點可能落在固定頁首後方的連結。按下 Enter 仍會啟動連結，但顧客看不到將要開啟甚麼。WCAG 2.2 的 2.4.11「焦點未被遮擋（最低要求）」是 AA 準則，檢查網站自行加入的內容有否把取得焦點的介面元件完全蓋住。判斷對象是元件本身，不是外圍焦點框的每一像素。只露出一小部分或許符合這項最低要求，實際上仍會令操作困難。

這項判斷須與「有沒有焦點指示」分開。WCAG 2.4.7 亦要求介面在某種操作模式下顯示鍵盤焦點。連結雖露出部分，唯一的焦點框卻可能藏在遮蓋層後面，構成另一問題；反過來，醒目的外框亦不能令完全被固定頁尾蓋住的元件變得可見。記錄實際取得焦點的元件、所在位置、遮擋層，以及元件和指示是否看得見，會比拍攝沒有焦點的正常頁面更有用。

找出會遮擋控制項的介面層

先列出頁面中的遮擋層，再改樣式。固定導覽列、推廣橫幅、Cookie 通知、聊天視窗、底部操作列，以及保持開啟的非模態對話框，都可能造成問題。記下哪些層只在捲動後、窄螢幕、作出同意選擇後或表單未完成時出現。亦要分辨它固定於整個視窗，還是位於另一個可捲動容器；文件的捲動偏移不一定能修正內層容器的焦點位置。

每個遮擋層都要挑選重疊區之前、之內及之後的控制項。頁首可能在向前按 Tab 時正常，反向用 Shift 加 Tab 卻把連結藏起來。底部同意橫幅則可能覆蓋最後一個欄位、提交按鈕或頁尾附近的驗證連結。按顧客真正可能形成的介面狀態測試。若聊天視窗由顧客自行開啟，還要檢查如何關閉，以及能否不移動焦點就顯示原本取得焦點的元件；W3C 對此有特定例外說明。

沿實際鍵盤路徑測試

從頁面正常起點開始，只用鍵盤前往第一項實際任務。依次用 Tab 經過導覽、主要內容、表單操作及頁尾，再沿相同路徑反向移動。焦點接近遮擋層時，在按下一鍵之前先看元件本身是否可見。捲動至頁面中段及底部再測，因固定效果往往在超過某位置後才出現。首屏通過測試，不能代表長篇產品頁或申請頁在捲動後亦正常。

再以窄視窗和矮視窗測試，包括橫向手機比例及放大後的桌面視窗。關鍵是可用空間，不是裝置名稱。切換英文與繁體中文，因為標籤長度不同，頁首高度可能改變，橫幅亦可能換行。打開正常使用時會出現的持續通知。每項缺陷都記下視窗大小、語言、遮擋層狀態、按鍵方向和被蓋住的控制項，讓開發人員可重現，而非只針對單一截圖寬度修補。

按版面選擇修正方法

W3C 的 C43 技術示範以留白及 CSS scroll-padding，讓內容避開固定橫幅。偏移應加在真正會捲動的容器，並依目前頁首或頁尾高度預留少量空隙。只按桌面寬度寫死數值，遇上翻譯後導覽列換成兩行便可能失效。測試瀏覽器自動捲動、頁內連結和程式移動焦點三種情況；它們的路徑可能不同。最後應以畫面位置驗證，不能因樣式表有 scroll-padding 宣告便視為完成。

在空間受限時，較可靠的修正可能是取消固定位置、縮小遮擋層，或讓打開的內容推開頁面，而非覆蓋原有控制項。若同意橫幅佔去矮視窗大部分高度，單靠捲動偏移仍可能沒有足夠操作空間。若任務確實適合模態對話框，就要在開啟時把焦點移進對話框，並在關閉前把鍵盤路徑限制在其中；把遮蓋層畫成對話框並不足夠。選擇方案時要兼顧實際顧客流程，並以滑鼠及鍵盤操作檢查。

以預約頁逐步判斷

假設一間小型診所的預約頁有固定頁首和底部協助橫幅。顧客選好服務後，從確認按鈕反向移動，準備修改日期。在矮視窗中，日期欄位取得焦點，卻完全位於頁首後面。先重現狀態，透過瀏覽器檢查工具確認哪個欄位真正取得焦點；不要以滑鼠游標位置推斷。然後量度當時頁首顯示高度，為頁面捲動容器加入避讓空間，再用 Shift 加 Tab 重試。若底部橫幅亦遮住確認按鈕，須另行處理下方重疊。

接着把預約頁切換為繁體中文，並放大瀏覽器。頁首若變高，原有避讓值便未必足夠；橫幅若變高，確認按鈕又可能進入被覆蓋區域。合格的驗收結果應是顧客能從服務選擇移到日期及確認操作，再反向移動，每一步都看得見取得焦點的元件及其指示，毋須猜測即可完成任務。把這條路徑記成可重複的測試，不要以單頁結果聲稱整站已符合要求。

理解例外而不放寬實際體驗

最低準則容許取得焦點的元件部分可見。對於使用者可移動的介面，它只評估初始位置；某些由使用者開啟的內容若可在不前移焦點的情況下顯示被遮住元件，亦有例外。這些是精確界線，不應當作把重要控制項藏得難找的理由。若顧客必須猜出未有說明的快捷鍵，或移開焦點再返回才知道原本位置，體驗仍須改善。在設計容許下，應讓整個元件及焦點指示清楚可見。

常見錯誤是為了讓重疊畫面看起來乾淨，直接隱藏焦點外框；這只會移除提示，元件仍在原位。另一錯誤是為全站加入過大的捲動偏移，令其他頁內連結位置失準。每項修正都應視為版面決策：找出受影響的捲動容器，檢查所有進入路徑，並在頁首設計改動後重測。若浮動視窗會持續開啟，要在介面提供清楚的關閉操作，並依 W3C 所述檢查原本取得焦點的元件可否再次顯示。

建立可用的驗收紀錄

在修改要求中附上簡短操作路徑：頁面及語言、視窗狀態、當時開啟的遮擋層、起始控制項、按鍵順序和預期終點。結帳或預約流程至少包括正常路徑及一條修正錯誤後返回欄位的路徑，同時觀察元件及焦點指示。即使開發人員表示自動檢查沒有報錯，仍要手動執行路徑；檢查工具未必知道所有臨時橫幅狀態，也不能判斷某項顧客任務是否仍然容易理解。

原本出問題的受限版面及兩種語言都通過操作路徑後，才可結束問題。記錄已檢查哪些固定介面層，以及哪些範圍尚未處理，例如由第三方獨立管理的工具。若該工具仍會蓋住必要控制項，應重新處理整合方式，不可寫成全數通過。往後只要導覽列高度、同意橫幅或浮動客戶支援工具改動，就把這條路徑重新納入回歸檢查。

交接發布前，可用簡短錄影或前後截圖呈現取得焦點的控制項及遮擋層，並註明控制項是經 Tab、Shift 加 Tab、頁內連結，還是程式移動焦點到達。不同路徑可能產生不同捲動位置。若修正使用捲動避讓，請沒有參與實作的人在另一種視窗高度及另一種語言重複操作。假如測試者每次轉移焦點後都必須自行捲動畫面，版面仍把負擔交給顧客。結果應限於已測頁面及狀態，不能以此換取宣稱整個網站全面無障礙的標章。 若同一固定元件在其他頁面共用，還要抽查那些頁面的不同內容長度；共用程式碼相同，不代表每頁的遮擋位置相同。 並應在修正紀錄中寫明哪一種視窗高度已完成驗收。