Accessibility開發與實踐系列
焦點無障礙 — 管理焦點的行為與轉移
哪些情境需要控制焦點的轉移？有哪些不良焦點轉移的常見案例？
本篇重點
- 焦點對鍵盤使用者有多重要？
- 哪些情境需要控制焦點的轉移？
- 有哪些不良焦點轉移的常見案例？
你是否曾經在閱讀一本書的過程中，不甚將書籤弄掉而需要回想正在閱讀的內容與重新尋找開始閱讀段落的不便經驗呢？對於依賴鍵盤或螢幕閱讀器導航網站的使用者來說，不恰當的焦點轉移就會導致像是遺失書籤那樣的不便，迫使讀者需要重新尋找原來閱讀的位置，這不僅耗時更影響了閱讀的體驗。而好的焦點轉移可以幫助使用者快速導航頁面與提供操作指引，同時減少鍵盤使用者的操作步驟，提升使用效率。
在控制焦點轉移時，我們會考量何時或在什麼條件下應該進行焦點轉移，以及應該將焦點轉移到哪一個元素上。
這篇文章中介紹了有哪些情境需要控制焦點的轉移？有哪些不良焦點轉移的常見案例？閱讀完後你將對焦點轉移的技巧有更深入的理解，讓你在製作互動性的頁面或元件時，能更全面的考量可訪問性。
鍵盤焦點與 focus
鍵盤焦點的作用就如同滑鼠指標那樣用來指向當前互動的元素。我們透過拖移滑鼠來控制滑鼠指標指向的元素，而鍵盤焦點則是透過按鍵，如 Tab 鍵或方向鍵來移動。除了使用者自行移動焦點外，開發者也可以透過 JavaScript 執行元素的 focus 方法來控制焦點的轉移。
儘管 focus 方法可以將焦點轉移到指定元素上，但如果該元素無法聚焦的話，則執行這個方法是不會起作用的。因此，如果想要使用 focus 方法將焦點移動到預設不可聚焦的元素（如文字、圖片或標題）上時，我們需要先設定 tabindex 為 -1 來使該元素變得可聚焦，然後再利用 focus 方法將焦點移過去。(關於 tabindex 的使用，歡迎參考 巧用 tabindex 讓你的 UI 更鍵盤友善 這篇文章)
此外預設 focus 方法會將聚焦的元素滾動至瀏覽器畫面的可視範圍中，並在聚焦元素外圍顯示一圈明顯的框線，通常也稱這圈框線為「焦點環」( Focus Ring )或焦點指示器( Focus Indicators )。開發者可以透過 focus 方法的參數選項來變更預設的行為，例如元素是否滾動到瀏覽器畫面的可視範圍或是否在元素周圍顯示焦點指示器。
對於一般使用滑鼠的人來說，焦點的轉移可能不會造成太大影響，甚至在沒有明顯的焦點指示器時，可能根本不會察覺到焦點的改變。然而，對於僅能透過鍵盤操作的使用者而言，焦點的轉移卻會導致巨大的情境變化與顯著的使用者體驗差異。在 WCAG 中將這類巨大的情境變化稱為「脈絡變更」( change of context )。由於脈絡變更對使用者體驗的影響甚鉅，因此在觸發焦點轉移時，我們必須格外謹慎。
哪些情境需要控制焦點的轉移？
減少使用者移動焦點次數，跳過重複選單
我們可以透過控制鍵盤焦點來製作出捷徑功能，協助使用者跳過選單項目，減少按 tab 鍵的次數。像是「skip to content」連結就是這類捷徑功能的例子，它讓使用者可以直接跳到頁面的主要內容區域。這邊值得一提的是，雖然「skip to content」可以簡單的透過「錨點」(Anchor) 來製作，但由於錨點是直接改變瀏覽器的可視範圍到對應的區塊上，而非平滑的滾動。如果想提供更好的使用者體驗，則需要結合使用元素的 focus 方法與 scrollIntoView 方法來實作焦點轉移。
給予使用者操作動作後的回饋提示
我們以點擊連結為例，在傳統的多頁式應用 (MPA) 中，當點擊了連結後的換頁行為是瀏覽器重新向伺服器請求完整的網頁內容並重新載入整個頁面，此時焦點會自動回到頁面的開頭處。這使得螢幕閱讀器使用者能容易察覺到頁面路由已經改變，確認成功點擊了連結。
然而，在單頁式應用(SPA)中，當點擊了連結後的換頁行為是透過 API 進行請求並將結果 render 到頁面上。這種作法焦點並不會發生任何的改變，此時如果我們沒有刻意設計焦點的轉移，使用者將難以察覺發生了頁面路由的改變，難以得知點擊連結的動作是否已經完成。因此我們必需在路由改變後控制焦點停駐在適當的元素上。
常見的做法是會在路由改變後隨之更新的區塊開頭處放置一個 header ，並將焦點移至此 header 上，來讓使用者能察覺路由已改變，同時使用者也能在路由改變後，接續瀏覽新區塊的內容。
引起使用者的關注確保內容可察覺
當出現新訊息或警告時，我們可以將焦點移動到訊息或警告內容區塊的開頭處，讓使用者輕易地發現有新內容並閱讀。這種焦點移動方式不僅讓螢幕閱讀器的使用者容易察覺到新內容的出現，由於焦點移動到新的元素上時，也會同時將訊息區塊滾動到瀏覽器的可視範圍內，因此縮放螢幕的使用者也能輕鬆發現它們。例如，在對話框（dialog）設計模式中，打開對話框時會將焦點移至其上，來讓使用者察覺，這使得對話框非常適合用於作為系統訊息或警告提示的呈現方式。
指引瀏覽內容或流程操作
在網路上的各種服務中經常會有需要執行一系列操作來完成任務的情況。例如在一個註冊會員的任務中，可能需要填寫個人基本資料、確認條款與進行身份驗證，當每完成一步後，透過將焦點設置於下一步的開頭來引導使用者，這樣可以減少尋找下一步元素的時間。
在填寫表單時，如果使用者填寫的資料格式不正確，如在線上捐款時需填寫姓名、聯絡電話與身份證字號等資料，但這些資料檢核後發現有錯誤的欄位時，我們可以將焦點移動到第一個錯誤的輸入元素上，指引使用者重新填寫。
在逐步載入新內容的區塊，例如社群平台貼文區，通常會透過無限滾動方式載入，當達到現有資料底部後再請求新貼文。此時，應在最後一則貼文後提供“載入更多”的按鈕，點擊後載入新內容並將焦點移至載入內容的第一則貼文的開頭處。
聚焦元素的消失導致焦點遺失
當聚焦元素消失導致焦點遺失時，需要主動控制焦點移動到一個符合邏輯的元素上，以方便使用者繼續瀏覽和操作。如果焦點元素消失時我們沒有主動將焦點移到其他元素上的話，則焦點會回到 body 元素上，這樣使用者就需要再次從頭走過整個頁面，才能夠回到原先的位置接續往下瀏覽與操作。
例如，在電子商城常見的購物車功能中，通常每個商品條目旁會有移除品項的功能按鈕，當按下移除按鈕後，會導致聚焦的元素消失。因此，當我們在移除一個購物車內的商品品項後，建議可以將焦點移動到下一個品項元素上，如果沒有下一個品項的話，則可以移到上一個品項元素上。而當移除後已無品項的話，建議可以移到這個購物車區塊的開頭處。
有哪些不良焦點轉移的常見案例？
在非使用者觸發的事件後改變焦點：
除非使用者能夠輕鬆地將焦點返回到原先轉移前的元素上，否則應該避免在使用者沒有任何操作的情況下自動移動焦點。就如前面所提到的，鍵盤焦點類似滑鼠指標，若在非使用者觸發的事件後改變焦點，不但會打斷使用者當下的瀏覽與互動，更會造成心理地圖的迷失。
不過有個例外是當使用對話框（dialog）來顯示即時的系統訊息時，使用者能透過按下 Escape 鍵快速關閉對話框並回到先前的元素上。此時，自動移動焦點則不會造成使用上的困擾。也就是我們應僅在使用者能夠輕易回復至焦點轉移前的脈絡並接續閱讀與互動時，才可以考慮運用自動轉移焦點的行為。
當元素獲得焦點時改變焦點
在使用鍵盤操作時，焦點移動到某個元素上（on focus）會有三種可能的目的：
- 單純使用 tab 焦點移動而路過該元素
- 想查看該元素的內容但並沒有想與其互動
- 希望與該元素進行互動
無論是哪一種目的，若在焦點移到該元素時就自動改變焦點，都會導致操作上的困難。
例如在線上購物結帳時，選擇使用信用卡付款時常見會提供四個 4 位數的輸入欄位要求顧客填寫。而為了引導顧客便利的填寫卡號，開發者設計了當每個輸入框填滿 4 位數後，自動移動到下一個輸入框上的功能，但如果其觸發檢查填滿 4 位數的時間點設定在 on focus 時，這便會導致當使用者一旦填滿了一組 4 位數輸入框而移動到下一組輸入框後，想再次修改前一組的填寫內容而將焦點返回上一個輸入框時，就又自動被移往下一個輸入框上，導致無法修改內容的窘境，因此，正確的檢查填滿 4 位數的時間點應在觸發輸入事件時較為合適。
當表單元件的值變更時改變焦點：
當表單元件，如下拉式方塊或選擇鈕的值變更時，我們不應該自動移動焦點。這是因為使用鍵盤操作表單時，元件值的變化往往只是選取最終選項過程中的必經步驟，也就是該值僅為暫時狀態。
我們以下拉式方塊為例，使用者通常會用上下方向鍵來探索有哪些選項可供選擇。而在這個以上下鍵探索的操作過程中，下拉式方塊的值會不斷的改變。雖然可以使用 alt+向下鍵來先展開選單再進行選擇以避免值不斷的變更，但大多數使用者不會這麼做。如果在值變更的同時就觸發焦點轉移，這將大大增加選擇過程的難度。因此，在表單元件值變更時保持焦點不變，對於使用者選取項目操作過程是非常重要的。
另一個常見的例子是，列表頁面提供了分頁功能，而它切換頁數的功能是使用下拉式方塊來選擇頁數，此時，我們應該在下拉式方塊旁給予一個執行動作的按鈕，當使用者明確按下此按鈕後才執行切換分頁的行為，而不是在其值改變時就立即切換。
本文作者：Woody
熱愛學習與開發程式的軟體工程師，對知識充滿好奇心，喜歡與人的互相分享。歡迎來一起協作開發各種 accessibility 專案。
