本身的 background-color 其實是白色； tint 色是靠 `.drink-hero::before` 這個裝飾用偽元素（搭配 mask 做出波浪形狀）疊出來的，只蓋住左側圖片那一塊，不是整個 section。 - section 裡唯一真正可聚焦的元素「View allergen info」按鈕，量出來的背景是白色（在 `.drink-hero__media`〈圖片容器〉右邊、波浪覆蓋不到的地方），不是疊在 tint 色上面。 - 照 brief 原始選擇器套用後實測：這顆按鈕的焦點外框會被強制設成白色，白底上疊白框—— 等於沒有焦點外框，這正是 2.4.7 要防的問題，等於因為這條規則本身把它做壞了。因此原版把範圍收窄到只有 `.drink-hero__media` 內的可聚焦元素才給白框；但那個容器裡從頭到尾只有一張，沒有真的可聚焦元素，這條規則從未套用到任何東西過——不是「預留給未來」，是死碼，2026-09-08 全站複驗時移除（見下方，跟頁首白框改成有條件是同一次編輯、同一個原因：兩條規則其實是同一份原始規則被拆開後留下的兩半）。 2026-09-08（收尾複驗，四個結案項之一）：這裡的 `header` 白框原本是全站無條件套用，前提是「頁首背景一律夠深」。這個前提在六個淺色 tint（leaf/arctic-water/dew/goldfish/ flamingo/peacock）的飲品頁上不成立——Task 5b 已經測過這六個 tint 底色不夠深，深到連 4.5:1 的文字都過不了，才把頁首文字/圖示改成 `#1A1A1A`；但同一次改動漏了這裡的焦點框，當時仍是白色，於是同一份樣式表對同一塊背景同時斷言「文字要深」跟「外框要白」兩件互斥的事。實測（用 Task 5b 已記錄的七色底色，套 WCAG 相對亮度公式反推，不是憑印象）： tint 白框對比 #111 外框對比 leaf 2.27 8.32 arctic-water 2.26 8.37 dew 2.65 7.12 goldfish 2.76 6.85 flamingo 3.03 6.24 peacock 3.45 5.47（唯一過 3:1 的 tint） berry 7.91 （白字已合格，未受影響，維持不動）非飲品頁固定紫 `#5C2D91` 9.38 （頁首白框的原始前提，仍然成立）前五個 tint（leaf/arctic-water/dew/goldfish/flamingo）白框不合格（2.26–3.03）， 35/63 支飲品頁受影響，每一個頁首可聚焦元素都中；peacock（3.45）跟 berry（7.91）本來就過關，不需要也不該跟著動——把它們也改深框只是多做不必要的視覺改動，不是修 bug。 Reviewer 建議「把 header 整條從白框選擇器移掉」如果照字面做，會連非飲品頁（固定紫 `#5C2D91`，前提仍成立、白框本來就合格）一起改回黑框，量出來 `#111` 對這個紫色只有一般水準（未在此重算，但明顯是拿掉一個原本沒問題的白框，製造新的視覺回歸）——所以這裡不是整條移掉 `header`，而是沿用 Task 5b 已經在用、且已知穩定的 `body:has(.drink-hero:is(...))` 技巧，只在「有這五個失敗 tint 之一」時關掉白框，讓它退回全站預設的黑框 `#111`（前五個 tint 量到 6.24–8.37，全部遠超 3:1）；peacock、 berry、以及所有非飲品頁的頁首則完全不受這條規則影響，維持原本已合格的白框。 */ header :where(a, button, [tabindex]):focus-visible { outline-color: #fff; } body:has(.drink-hero:is(.drink-tint-leaf, .drink-tint-arctic-water, .drink-tint-dew, .drink-tint-goldfish, .drink-tint-flamingo)) header :where(a, button, [tabindex]):focus-visible { outline-color: #111; } /* 2.4.11 Focus Not Obscured：這裡刻意不放 scroll-margin-top。 2026-09-07 fix round 1：brief 原本要求桌機 169px、手機 121px（來自重建計畫對頁首的既定設計），部署後我方與 reviewer 各自獨立實測（含清除 LiteSpeed 快取排除舊快取誤判）都確認：目前線上版本沒有任何固定或 sticky 的頁首元素——捲動後頁首跟著頁面一起捲走；全頁唯一的 fixed 定位元素是手機選單抽屜展開時的關閉按鈕，不是頁首。也就是說這條規則要防的情境（固定頁首擋住剛聚焦或錨點跳轉到的元素）現在不存在，套用後唯一的可見效果是每次 Tab 停在畫面邊緣、或錨點跳轉時，該元素上方憑空多出 169px／121px 的留白——這是在修一個不存在的問題，而且會製造新的、看得到的副作用。已依 owner 裁示移除。2.4.11 的通過與否改成在最終驗證階段對當時的真實頁面實測確認，不是靠這種預先假設的規則。若之後真的做出固定疊層頁首，屆時再用實測到的頁首高度加回這條規則。 */ /* 2.5.8 Target Size (Minimum)：互動元素至少 24×24 CSS 像素。只補尺寸不改視覺：用 min-width/min-height 加置中，圖示本身大小不變。 2026-09-07 實測盤點（桌機 1440px／手機 390px，首頁＋門市頁＋飲品頁＋飲品列表頁）： - 主選單連結（nav a）在兩種 viewport 下實際曝光的那個變體都已經是 24px 高，本來就不算違規，這裡的規則對它是保險，不是修正。 - 真正低於 24×24 的是頁首與頁尾的社群圖示連結：`.bricks-link-wrapper`（桌機頁首約 21×31、頁尾約 35-40×16；手機頁尾約 21-24×16），下面這條規則對得上、修得到。 - brief 原本另外列的 `.brxe-icon a` 選不到任何東西：`.brxe-icon` 是圖示本身的 class，不是包住連結的容器（結構其實是反過來的 ` `），已移除這個選不到東西的選擇器，改由 `.bricks-link-wrapper` 涵蓋同一批圖示連結。 - 跳過導覽連結（.skip-link）平時是 clip 成 1×1 的視覺隱藏樣式（focus 時才變成 183×37），不是真的可點擊目標，不算違規，這裡不處理。 - 門市頁的「Use my location」按鈕、Leaflet 地圖版權連結、飲品列表頁窄螢幕下的分類篩選標籤（drink-cat）量到的高度也低於 24px，但這些元素屬於 Task 11（地圖鍵盤操作）與 Task 12（飲品篩選）的檔案範圍，這裡不動，避免跟後續任務的實作互相踩線。 - 手機版頁首的漢堡選單按鈕（.bricks-mobile-menu-toggle，「Open mobile menu」）量到 32×16，高度也不足 24px，但它的鍵盤操作與焦點管理是 Task 8 的範圍（同一顆按鈕），這裡同樣不動，避免搶在那個任務的鍵盤／焦點邏輯定案前先改了它的框大小。以上四項（Task 11／12／8 各自的元素）都已記錄在 Task 4 報告裡供追蹤。 2026-09-07 fix round 1（reviewer 發現）：原本還列了 `.brxe-pagination span`。實測 `.brxe-pagination` 底下所有 ``（目前頁碼指示 `.page-numbers.current`、省略號 `.page-numbers.dots`、裝飾用的上/下一頁停用占位符 `.drink-pager__nav--prev/next`、「of N」文字 `.drink-pager__total`）全部 `tabIndex === -1`、沒有 `onclick`、沒有 `role`、`cursor: auto`——沒有一個是真正互動元素，2.5.8 的「互動元素」範圍不包含它們。原本能「安全」只是巧合：省略號那個 span 剛好被另一支跟本次改動無關的分頁腳本用 inline style 設成 `display:none`，不是這條規則的功勞，也不該依賴一支自己管不到的腳本來保證安全。已移除 `.brxe-pagination span`，只留下真正可聚焦、可點擊的 ``（頁碼連結、上一頁／下一頁連結）。 */ .bricks-link-wrapper, nav a, .brxe-pagination a { min-width: 24px; min-height: 24px; display: inline-flex; align-items: center; justify-content: center; } /* 2.5.8 Target Size (Minimum)：手機選單漢堡鈕（.bricks-mobile-menu-toggle，「Open/Close mobile menu」），Task 4 記錄、保留給 Task 8（本任務）處理的第四個目標尺寸違規。2026-09-07 實測（390px）：32×16，高度不足 24px。這裡刻意不沿用上面 `.bricks-link-wrapper` 那條 min-width/min-height 做法：這顆按鈕所在的 `#brxe-nagwri`／`#brxe-egyrxy` 是靠子元素高度自動撐開的 flex 容器（實測其餘手足節點——手機選單面板與遮罩——都是 position:fixed，已脫離文件流，完全不參與這個自動撐開的高度計算，容器高度目前就是這顆按鈕自己的高度）；若直接把按鈕 min-height 設成 24px，會把這顆按鈕、連帶整個容器與頁首那一列的版面高度從 16px 撐大到 24px——這是看得見的版面尺寸變更，不是「只補尺寸不改視覺」，牴觸本次任務「不得改變一般使用者看到的畫面」的前提，也還沒經過個別核准。改用絕對定位的 `::after` 純擴大可點擊／觸控命中範圍：`position:absolute` 已脫離文件流，不會撐大任何父層或位移任何手足元素，內容留空、不上背景／邊框，視覺上不存在——這是 WCAG 2.5.8 Understanding 文件本身列出的合規做法（invisible target expansion），不是變通。四邊各加 4px：32×16 → 40×24，剛好達到 24×24 下限，且按鈕本身已是 `position: relative`（Bricks 原生樣式），`::after` 的絕對定位以它為基準，不需要額外宣告。已實測確認 `::after` 目前未被站台其他樣式使用（`content: none`），也已實測擴大後的命中範圍點擊仍會觸發開關（見 task-8-report.md）。 */ .bricks-mobile-menu-toggle::after { content: ''; position: absolute; inset: -4px; } /* 2.4.7／2.1.1：門市頁地圖容器現在可聚焦（tabindex 由 Leaflet keyboard:true 原生給、stores.js 的 accessibleMap() 又顯式宣告一次），理論上已經吃得到上面 `:where(...,[tabindex]):focus-visible` 那條全站規則——實測也確實吃得到（焦點外框顏色/寬度都對），但那條規則用了 :where()，特異度是 0，跟 Leaflet 自己 `.leaflet-container { outline-offset: 1px }`（一般規則，特異度是一個 class）在 outline-offset 這個屬性上打平，目前 leaflet.css 排在 a11y.css 之後，於是 offset 被 Leaflet 的 1px 蓋掉（外框本身看得到，2.4.7 不受影響，只是 offset 差 1px）。這裡用比 :where() 高的特異度顯式宣告一次，不依賴兩份樣式表之後的載入順序不會變。 */ .leaflet-container:focus-visible { outline: 3px solid #111; outline-offset: 2px; } /* 2.5.8 Target Size (Minimum)：門市頁地圖右下角的 Leaflet 版權連結，Task 4 記錄、保留給本任務處理的目標尺寸違規（另一項門市定位鈕屬於別的任務範圍，這裡不動）。2026-09-07 實測（1440px 桌機，/stores/ 頁，真瀏覽器量測）： `.leaflet-control-attribution a` 量到 51.375×14，高度不足 24px 下限、寬度已足夠，只差 10px 高。這顆連結貼在地圖右下角，旁邊沒有多餘版面可以讓 min-height 撐大視覺尺寸而不移動任何東西（父層 `.leaflet-control-attribution` 本身也只有 61.375×16.8，一樣不夠），跟手機漢堡鈕（見上面 fix round 1 那段）同一個理由，改用絕對定位的 `::after` 純擴大可點擊／觸控命中範圍：連結原本是 `position:static`，這裡把它設成 `position:relative`（沒有 top/left 偏移，不會移動連結本身），讓 `::after` 以連結自己（不是父層）為定位基準，四邊各加 5px（14+10=24，剛好達到下限），內容留空、不上背景／邊框，視覺上不存在。父層 `overflow` 實測是 `visible`，擴大範圍不會被裁掉；擴大後的命中範圍會蓋到地圖本身的一小塊邊角，但那個角落本來就被這條半透明版權列蓋住，不影響一般拖曳／點擊地圖的操作。 */ .leaflet-control-attribution a { position: relative; } .leaflet-control-attribution a::after { content: ''; position: absolute; inset: -5px; } /* 1.4.11 Non-text Contrast：Leaflet 縮放按鈕（+/−）之間、以及外圈的邊界。兩個來源都不合格：(1) 兩顆按鈕中間的分隔線 `.leaflet-bar a { border-bottom: 1px solid #ccc }`，對白底量到約 1.6:1；(2) 桌機（無觸控）情形下外層 `.leaflet-control-zoom` 只靠 `box-shadow: 0 1px 5px rgba(0,0,0,.65)` 做邊界，模糊漸層量不出可靠的 3:1（觸控裝置會多一條 `border: 2px solid rgba(0,0,0,.2)`，等效於對白底 #ccc 灰，一樣不到 3:1）。兩個來源都是「按鈕本身的邊」，所以直接在 `.leaflet-control-zoom-in`／`-out` 兩顆按鈕上各補一圈實心邊框，蓋掉原本的分隔線與外層那圈不可靠的陰影／半透明邊，顏色選 #595959——對白底量到約 5.5:1、對地圖預設底色 #ddd 量到更高，兩者都過 3:1。只動邊框顏色，不動按鈕文字色（+/− 原本就是黑字，對白底已經合格，不需要也不該動）、不動按鈕尺寸與版面位置，維持跟原本一樣的按鈕外觀與操作。 fix round（部署後實測抓到）：第一版選擇器 `.leaflet-control-zoom a` 對 `border-bottom` 這個子屬性跟 Leaflet 自己的 `.leaflet-bar a` 特異度打平（都是一個 class＋一個元素），leaflet.css 排在 a11y.css 之後印出，「後印的贏」，實測結果是三邊變 #595959、底邊仍是原本的 #ccc——比完全沒改還糟（看起來像沒套齊全的錯誤，而不是刻意的設計）。這裡把選擇器疊上容器實際同時具備的兩個 class（`leaflet-control-zoom leaflet-bar leaflet-control`，實測過的真實 class 清單），特異度變兩個 class＋一個元素，不靠印出順序就贏，不需要 `!important`。 fix round 1（reviewer 用放大截圖抓到，第一版報告誤寫成「只換了顏色」）：兩顆按鈕上下緊貼、中間沒有間隔，`border: 1px solid #595959` 對兩顆按鈕都是四邊全上——於是「+」的底邊與「−」的頂邊疊在一起，分隔線從原本的 1px 變成兩條相鄰的 1px 疊成一條約 2px 粗的深色帶，比外圈其餘三邊粗一倍，是沒注意到的第二個視覺改動，第一版報告只講了顏色、沒講粗細，是誤述不是省略。修法：分隔線只給其中一顆按鈕的那一邊，不要兩邊都給。這裡讓「−」（`:last-child`，下面那顆）拿掉自己的頂邊，分隔線只剩「+」（上面那顆）的底邊在，粗細就是單一的 1px，跟外圈其餘三邊一致；「−」原本就有的 `:last-child { border-bottom: none }`（Leaflet 自己的規則，維持不動，見上一輪）沒有被這裡動到，外圈最下面那段曲線一樣是靠 box-shadow 表示邊界。 */ .leaflet-control-zoom.leaflet-bar a { border: 1px solid #595959; } .leaflet-control-zoom.leaflet-bar a:last-child { border-top: none; } /* 2.5.8 Target Size (Minimum)：門市頁「Use my location」按鈕（`#store-use-location` `.store-search__geo`）。Task 4 當初量到 133×20 記在清單裡，但派工時寫「屬於其他任務」之後從未實際指派給任何任務——兩邊都以為對方會做，結果沒人做，是控制者的分派錯誤（task-12 複審發現、記在 progress.md），併入本任務補做，獨立於表單那組修正之外驗收。 2026-09-07 重新實測（1440/1024/768/390/320 五種寬度，novamira-chatime-com 開發機覆寫，/stores/ 頁，真瀏覽器量測 getBoundingClientRect）：五種寬度量到的尺寸完全一致，都是 133.25×20——記錄的數字是對的，不是像同一份原始清單裡「飲品分類篩選膠囊」那項（其實是 96×96 的滿版延展連結，Task 12 複審已更正）那種量測錯誤。寬度 133px 已遠超過 24px 下限，只差高度 4px。這顆按鈕 `position: static`，是 `.brxe-container` 底下第三個、也是最後一個直接子節點（前兩個是頁面標題 h1 與門市搜尋欄 `.store-search__field`），上緣與搜尋欄之間有 20-24px 空隙（依寬度而定，320px 最窄時仍有 20px），下緣與下一個 section（地圖／門市清單所在區塊）之間有約 180px 空隙——五種寬度都一樣寬裕，用不可見的擴大命中範圍（`::after`，WCAG 2.5.8 Understanding 文件本身列出的合規做法）往上下各加 2px（20+2+2=24），不會摸到搜尋欄或地圖，不需要另外判斷 viewport。實測過這顆按鈕目前沒有用到 `::after`（`content: none`），父層 `.brxe-container` 的 `overflow` 是 `visible`，擴大範圍不會被裁掉，也不會被裁掉去蓋到搜尋欄或地圖。按鈕本身已知會保持它現在的 `display: flex`，這裡只加 `position: relative` 讓 `::after` 以按鈕自己（不是父層）為定位基準，不改變任何看得見的排版（沒有 top/left 偏移）。 */ .store-search__geo { position: relative; } .store-search__geo::after { content: ''; position: absolute; top: -2px; bottom: -2px; left: 0; right: 0; } /* 只給螢幕閱讀器的文字：不能用 display:none，那樣讀不到。 */ .chatime-a11y-sr-only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } /* 1.4.3 Contrast (Minimum)：owner 2026-09-07 逐項核准的六項色彩對比修正（task-5-report.md 量測、task-5b 施作）。「近黑色」統一用 #1A1A1A——這不是隨手挑的，是 owner 核准清單裡每一個比值（leaf 7.67／arctic-water 7.71／ dew 6.56／goldfish 6.31／flamingo 5.75／peacock 5.04／按鈕 5.50／淺紫區塊 4.92／粉紅橫幅另用色卡的洋紅，不用近黑）算出來就是用 #1A1A1A 當前景色反推的，逐一核對過完全吻合（不是 a11y.css 別處拿來做 focus 外框的 #111——那是另一個用途、另一個值，兩者刻意不共用）。 */ /* 項目 1＋2：飲品內頁頁首導覽文字與圖示，疊在 tint 色塊上。頁首（
）不是 .drink-hero 的子元素——它是絕對定位、z-index 999 疊在 hero 上面的手足元素，tint class 掛在 .drink-hero 這個
上，頁首本身拿不到那個 class。純 CSS 選不到「看手足元素的 class 決定自己樣式」，所以這裡用 :has()（現行 Chromium/Firefox/Safari 皆支援）在共同祖先 body 上判斷「頁面裡有沒有這六種 tint 之一」，回頭改頁首的文字與圖示顏色。七色只挑六色（leaf/arctic-water/dew/goldfish/flamingo/peacock），故意排除 berry——berry 白字對比已經 7.91，本來就合格，不需要也不該被這條規則動到；非飲品頁（首頁/門市/加盟等）沒有 .drink-hero，:has() 一律不成立，頁首維持原本的白字，不受影響。四個 Font Awesome