鍵盤用戶被忽視的痛點：谷歌工程師如何重做焦點指示器

去年夏天，一位谷歌工程師寫了一篇關于焦點管理的博客，卻花了整整一年才完成這篇續作。他在草稿箱里反復打磨的，是一個被大多數開發者忽略的問題：鍵盤用戶怎么知道自己在哪？

答案藏在「焦點指示器」里——那個顯示當前鍵盤焦點位置的視覺標記。Android 默認的漣漪效果（ripple）技術上能通過無障礙標準，但肉眼幾乎看不清。這篇技術博客的價值，在于它提供了一套可復用的工程方案，而非簡單的代碼片段。

為什么默認方案不夠用

網頁內容無障礙指南（WCAG）對焦點指示器有明確要求：必須足夠可見。Android 的漣漪效果在深色背景上尤其容易消失，鍵盤用戶——包括運動障礙者、高級用戶、以及任何不想抬手摸屏幕的人——會在導航中迷失。

更關鍵的是，這位工程師明確區分了兩個概念：鍵盤焦點指示器 vs 屏幕閱讀器焦點。后者由系統（如 TalkBack）處理，前者則需要開發者自己實現?；煜@兩者，是很多應用無障礙體驗糟糕的根源。

常見的修復思路是給聚焦元素加邊框。Appt.org 的代碼示例就是這么做的。但這位工程師想要更靈活的東西：一條簡單的下劃線，能用在按鈕上，也能用在開關行上，最好能通過 Modifier 一鍵接入任何交互組件。

這需要用到 Compose 的 Indication API，配合 DrawModifierNode 來自定義繪制邏輯。

三層封裝的設計思路

工程師的目標很明確：把復雜度埋進 Modifier 里，讓業務代碼保持簡潔。為此他拆解了三個必要組件：

最底層是 FocusNode 類。它繼承 Modifier.Node 和 DrawModifierNode，接收兩個參數：InteractionSource（感知交互狀態）和 Color（指示器顏色）。核心邏輯落在兩個重寫方法里：onAttach 處理焦點狀態的訂閱，draw() 負責實際繪制。

onAttach 里用了一個 mutableStateOf(false) 存儲聚焦狀態，通過協程監聽 interactionSource 的變化。這是 Compose 的響應式范式——狀態驅動重繪，而非命令式地調用 invalidate()。

中間層需要把 FocusNode 包裝成可用的 Modifier。這里用到 Compose 的 ModifierNodeElement 模式：定義一個數據類持有配置參數，create() 方法實例化 Node，update() 方法處理參數變化時的復用。這種設計讓 Modifier 在重組時盡可能復用底層節點，避免不必要的對象創建。

最上層是面向開發者的 API。理想情況下，一行代碼就能啟用：.indication(interactionSource, FocusIndication(Color.Blue))。interactionSource 由組件自己提供，FocusIndication 是封裝好的指示器工廠。

從「能用」到「好用」的工程權衡

代碼實現中有幾個值得注意的選擇。

首先是繪制區域的處理。工程師在 draw() 方法里調用了 drawContent()，確保子組件先完成自身繪制，再在之上疊加指示器。這避免了遮擋問題，也符合「裝飾器」模式的設計直覺。

其次是動畫的取舍。博客示例中的下劃線是即時出現的，沒有淡入淡出。工程師提到可以用 Animatable 實現平滑過渡，但為了保持示例簡潔并未展開。這是技術寫作的典型策略：先跑通核心鏈路，再提示擴展方向。

最微妙的權衡在顏色參數。FocusNode 接收的是 Color 而非 Brush，這意味著漸變指示器需要額外改造。工程師沒有解釋這個限制，但結合 Android 無障礙最佳實踐來看，純色高對比度往往是更穩妥的選擇——漸變雖然好看，可能在某些背景上失去辨識度。

為什么這件事值得開發者關注

這位工程師的博客標題用了「More Accessible」，而非「Fully Accessible」。這個措辭本身就很誠實：它只是改進，不是終點。

但改進的價值被低估了。Android 生態中，鍵盤導航長期是「二等公民」。Chromebook 支持 Android 應用、折疊屏外接鍵盤、TV 遙控器交互——這些場景都在增長，卻很少有應用做好焦點管理。一個可復用的 Modifier 方案，降低了團隊的實施門檻。

更深層的意義在于 API 設計哲學。Compose 的 Indication 系統把「交互反饋」抽象為可插拔的模塊，開發者可以替換默認漣漪，也可以為不同場景配置不同指示器。這種擴展性，是命令式 UI 框架難以實現的。

這位工程師花一年時間打磨這篇博客，或許正是因為這個主題「不夠性感」——它解決的是邊緣場景，代碼卻涉及 Compose 較底層的 Modifier 機制。但正是這種「把臟活做干凈」的工程態度，讓無障礙改進從「應該做」變成「容易做」。

對于正在評估 Compose 遷移方案的團隊，這個案例提供了具體的檢查點：你們的焦點指示器策略是什么？能否在不污染業務代碼的前提下統一升級？答案可能決定大量鍵盤用戶的去留。