選中態視覺是成對屬性：底色與文字色要一起指定、對比方向成對反轉（底色淺配深字、底色深配淺字）— 單獨覆寫選中底色會脫離主題的成對機制（如 Material 3 的 container / onContainer 配對），元件庫不會為自訂底色反推文字色，只設一半的選中態在特定主題下對比崩掉。

觀察

書庫管理 app 篩選列的 FilterChip 樣式（library_display_extensions.dart:240-253）：選中底色 primaryLight（淺藍）、勾號 primary（主色藍）、未選中底色 surfaceLight — label 的 Text 沒有指定 style，文字色走 FilterChip 主題預設、不隨選中狀態變化。結果是淺色調的預設文字疊在淺藍選中底上，驗收回報「文字本身顏色太淺、選中之後看不到文字內容」。

判讀

  1. 選中態是（底色, 文字色）的元組、不是單一顏色屬性。只設定 selectedColor 等於改了元組的一半 — 另一半停在主題預設，兩者的組合對比沒有人驗證過。元件庫的參數命名（selectedColor）誘導開發者以為「選中的樣式」設完了。

  2. 對比方向要成對反轉。底色從淺變深、文字就要從深變淺，反之亦然 — 這是驗收者直接指出的規則，對應 WCAG 的文字對比要求（AA 級：一般字級 4.5:1、大字 3:1）。選中態常見的失敗形態就是「淺底配淺字」：選中底色取主色的淺色變體、文字維持中性淺灰。

  3. 對比問題在設計稿上經常不出現。設計稿的選中態通常畫了完整的元組；實作時只搬了底色參數、文字色「看起來差不多」就過了 — 差距要到實機、不同亮度環境、或對比敏感度較低的使用者手上才現形。

策略

  1. 每個有選中態的元件列出兩個狀態的（底色, 文字色）元組，逐一驗證對比（WCAG AA：一般字級 4.5:1、大字 3:1；工具：任何 contrast checker）。

  2. 程式碼掃描訊號：設定了 selectedColor / 選中背景的元件，label 是否也有對應的選中文字色 — 只設一半的就是候選。

  3. 選中指示不只靠顏色 — 這條 chip 有勾號輔助（正面設計），色弱使用者仍能辨識選中；但勾號不能替代文字可讀性，兩者是不同層的要求。

下一步路由