iPhone Duo 今天正式開賣，首批評測在 10 月 21 至 22 日全部出齊，對介面的判決出奇一致：內螢幕是「比 iPad 更像平板的平板」，外螢幕是「最糟的 iPhone」，而兩者之間的分水嶺幾乎都是同一件事——App 有沒有用 iOS 27 以上的 SDK 重新建置。Daring Fireball 的 John Gruber 把話說得最重，9to5Mac 的整理、The Verge、WIRED、CNET 則各抓到不同的細節。今天的任務是把昨天的待驗項對帳，再把這些評測拆成能直接用在版面決策的觀察，並補上另外兩條與「尺寸不再固定」有關的線：W3C 在 10 月 7 日的 WCAG 3 編輯草稿裡對比演算法仍是「待定」，以及 Smashing 對容器查詢的實務整理。
承接 昨日 UIUX：昨天談的是 Apple 一手資料規定了什麼，今天看的是第一批真人拿到機器後，哪些規定在現實裡變成了問題。本文所有網頁都經網頁抽取摘要，不是我讀完整原文，也沒有任何一台實機在我手上。
📖 學
一、昨天待驗項對帳
| 昨天的待驗 | 今天查到 | 狀態 |
|---|---|---|
| HIG iPhone Duo 頁與 HomeView 的 pt 規格 | Apple 設計「What’s new」頁最新條目仍是 10 月 13 日：Widgets 加入 HomeView 指引、Live Activities 加入限寬版面，其後沒有新條目，頁面沒有 pt 數值 | 仍未公布 |
| Pitre 評分規則 | 我打開了 Southleft 的 ds-contracts-poc 儲存庫頁面，摘要說裡面沒有 A/B 測試的文件，也沒有評分規則、模型、執行次數；只有「衡量完成的使用者旅程與覆蓋率」這類通則。搜尋摘要仍重述 69 比 100 的分數，但那是轉述 | 查不到評分規則；不能判 |
| Guidelines 遵守率 | 今天沒有找到任何量化測試 | 查不到 |
| USWDS 後續 | GitHub API 顯示 v3.14.0 發行於 2026-08-18；前一版 v3.13.0 在 2025-05-23。自算相隔 452 天，而更早的 v3.11.0（2024-12-18）到 v3.12.0（2025-03-07）是 79 天、再到 v3.13.0 是 77 天。換句話說，這個設計系統長期是約 11 週一版，中間出現過一次約 15 個月的空窗，之後才補上 3.14.0。目前離 3.14.0 又過了 66 天，沒有更新的版本 | 已確認：昨天說的「後續週期」有答案——3.14.0 已在 8 月出 |
| GOV.UK Frontend | API 的最新發行仍是 v6.6.0（2026-10-15），前一版 v6.5.1 為 2026-09-14，距今 8 天沒有新版 | 已確認：沒有新版 |
| 11 月 13 日實機字高 | 還沒到日期 | 待驗 |
| 外螢幕點數 | 沒有 Apple 一手資料，評測只講英寸 | 見下文自算，仍是推論 |
USWDS 還有治理與人事方面的新聞，搜尋結果摘要談到這個，我沒有打開那些報導，也不在這裡評論；對使用者有影響的只有一件事，就是版本釘在哪一版、多久更新一次。
二、評測怎麼說：先看爭議最小的共識
把九篇評測與整理放在一起，真正沒爭議的只有三件事。
第一，舊 SDK 的 App 看起來很糟。Gruber 的原話是「不是為 iOS 27.0 SDK 更新過的 App 是糟糕的體驗，它們只像漂浮在一片黑海上的小小虛擬 iPhone Mini」。9to5Mac 的 Ben Lovejoy 在 10 月 22 日的整理寫得更具體：很多 App 還沒更新，最壞的情況是 iPhone 版面被擱在幾乎全黑的內螢幕中央。WIRED 的 Julian Chokkattu 說這些 App 在左右兩側有「大片黑邊」，建議等幾個月讓開發者最佳化，這段是 MacRumors 彙整頁的轉述。昨天我整理的三階 SDK 對照（iOS 26 以前黑邊、iOS 27 多延伸、iOS 27.1 滿版）與 WorksOnDuo 追蹤站的分類完全吻合，該站用的就是同樣的三種狀態，外加「滿版」「部分適配」「黑邊」「待確認」。
第二，右側控制列是 Apple 的主要賭注，而且有成本。The Verge 與 WIRED 都質疑把 iOS 的導覽元件全部搬到右側軌道，在某些 App 浪費很多空間，但也都承認 App 把這塊空間用滿的時候覺得可以接受。9to5Mac 整理中 HTX Studio 的評語是兩個螢幕的長寬比互相拉扯：改善外螢幕，內螢幕就變成一個很大的空方形。Gruber 對 Dock 搬到右邊的看法是「打破了我 19 年的空間記憶」。這三個意見其實講的是同一件事——固定位置的控制換來一致性，代價是內容少的頁面看起來空。
第三，分割畫面這件事是對的。Gruber：「Duo 上的分割畫面直覺、自然、有用，而且大致顯而易見。」他另外提到兩側各有自己的 Home 指示條，工具列位置在外緣。tech-ish 的整理則提醒限制：只有固定對半分，不能調整比例，也沒有第三個 App，對照 Samsung Fold 8 同時跑三個。這是單篇的整理，我沒有核對 Samsung 的規格。
三、評測互相打架的地方
最有意思的是不一致，因為這些不一致告訴你變數在哪。
外螢幕鍵盤。 CNET 的 Abrar Al-Heeti 說鍵盤寬敞、占外螢幕約一半，打字順暢、錯誤沒有增加（這段是 MacRumors 彙整頁的轉述）。Gruber 卻說外螢幕開著鍵盤時，如果同時有 Live Activity，連一對工具列按鈕都放不下。兩者並不矛盾，條件不同：前者是單純打字，後者是鍵盤加上 Live Activity 加上工具列。The Verge 另外提到外螢幕鍵盤沒有單手縮小的選項。對設計師而言，最糟的情況才是驗收標準：鍵盤升起時，你的主要動作還在不在。Gruber 的原話只說「放不下」，按鈕會被收進更多選單變成多一次點擊，這一步是我的推論，不是他說的。
哪些 App 已經更新。 tech-ish 的整理說 Netflix、Instagram、Slack、Spotify、TikTok 已更新，Telegram、Gmail、LinkedIn 還是不填滿畫面。但 WorksOnDuo 的頁面把 Instagram、TikTok、Spotify、Gmail 都列在「未確認」，只把 Netflix、Zoom Workplace、Slack（企業版）與 Detail 標為就緒；另外 X 上一則貼文轉述 Marques Brownlee 的影片，說 YouTube 與 Spotify 還有黑邊，這是搜尋摘要裡的二手轉述，我沒有看影片。這份追蹤站的數字也有一處自相矛盾：摘要說追蹤 854 個 App、2 個已就緒，卻同時列出四個就緒的 App，可能是頁面還在更新或抽取有誤，所以我不報告它的數字，只報告分類。判讀：「未確認」不等於「沒適配」，它的意思是沒有公開證據；而「已更新」是 App 的更新日誌聲稱，兩者差距是可以預期的。對設計師最實用的訊號只有一個：自己的 App 要用哪一個 SDK 建置。
三之一、內螢幕主畫面與 Live Activity：版面邏輯換了
Gadget Review 在 10 月 21 日的文章（它自己註明截圖只涵蓋部分方向與狀態）描述內螢幕主畫面：Today 檢視與小工具在左，App 圖示在右，鎖定畫面的控制在右下角，狀態列在右上角，而且內螢幕沒有常駐的 Dynamic Island，提醒與 Live Activity 改成從側邊展開。這幾句是我讀到的描述，沒有圖也沒有實機。從設計角度看，這是一次閱讀順序與操作區的重新分配：資訊在左、操作在右。
這個分配有兩個可以追問的設計後果，都是我的推論而非評測結論。第一，操作集中在右邊，右手持機的人拇指好到，左手持機的人要換手或伸過去；Apple 有沒有為左手使用者提供鏡像選項，我沒有查到，不能說有或沒有。第二，Live Activity 從側邊展開，意味著它占用的是橫向空間而不是頂部空間，Gruber 說的「鍵盤加 Live Activity 就放不下一對工具列按鈕」正是外螢幕在這種分配下的極端情況。Apple 在 10 月 13 日的「What’s new」頁已經為 Live Activities 加入了限寬版面的指引，我只讀到條目標題與一句說明，沒有讀到指引內文，所以不知道它規定了什麼；但時間上的巧合值得記一筆：限寬版面的指引在開賣前十天出現。
四、一個自算：內螢幕與外螢幕的尺寸關係
評測給了英寸，Apple 沒給點數，昨天的 669×951 點是我的推論值（沒有一手資料）。拿 Gruber 摘要裡的數字交叉：展開機身 4.6 乘 6.5 英寸，長寬比 1.413；我推論的 951 除以 669 是 1.4215，差 0.6%，在四捨五入到小數點後一位的誤差之內。再用 7.6 英寸對角算：寬 4.373 英寸，669 點除以它是每英寸 153 點，與一般 iPhone 的每英寸約 153 點（460 ppi 除以 3，這是我記憶中的常見數字，沒有核對）一致。這代表推論的點數至少不與英寸相衝突，但不代表它是對的，這個交叉只能排除離譜的情況。
如果把內螢幕固定對半分，寬度對半約 334 點，連一半一半的間隙都沒扣，這大概比常見 iPhone 的寬度都窄（我沒有逐一核對各機型）。這個數字依賴我的推論點數，也不知道 Apple 分割是水平還是垂直、中間留多少，所以只能當成提醒：測試時要準備比常見手機更窄的視窗。
五、WCAG 3 草稿：對比演算法仍是「待定」
W3C 的 WCAG 3 編輯草稿日期是 2026 年 10 月 7 日，我打開了。裡面「文字對比足夠（最低）」是核心要求，狀態為「發展中」，而判準的位置寫的是「對比量測，待決定」的占位文字。另一個頁面（W3C TR 版，九月工作草稿）的編輯註記說：「WCAG 3 使用的對比演算法尚未決定。本草稿假設演算法會包含字級與字重因素。」所以「WCAG 3 已確定採用某個演算法」的說法，在這兩個 W3C 頁面上都找不到根據。
另一個我要更正的是搜尋摘要的說法：某篇第三方文章說九月草稿是 Bronze、Silver、Gold 三級。我打開的 W3C 文件與 Shawn Lawton Henry 在 9 月 25 日的官方部落格都沒有這三個詞。部落格說的是：單一一級「核心要求」，建立在 WCAG 2.2 的 A 與 AA 之上；難以客觀量測的部分放進「補充要求」與「建議實務」；用標籤讓法規訂定者依情境調整（重要的政府服務更嚴格）；以及多個報告層級鼓勵超越最低要求。所以我不採用 Bronze、Silver、Gold 的說法。W3C 公告也要求不要把它當成非草稿來引用。
這件事對設計師的意思：對比檢查在短期內不用改標準，繼續用 WCAG 2.2 AA；但草稿已經預告演算法會帶字級與字重。我用 APCA 的公開實作（Myndex 的 apca-w3，我打開了，版本字串是 Beta 0.1.9 W3，常數照該檔）自己寫了計算，對照 WCAG 2 的比值：
| 前景／背景 | WCAG 2 比值 | APCA Lc（自算） |
|---|---|---|
#767676 在白底 | 4.542 | 71.6 |
#777777 在白底 | 4.478 | 71.1 |
#949494 在白底 | 3.033 | 57.1 |
#595959 在白底 | 7.005 | 84.3 |
#0a84ff 在黑底 | 5.757 | -38.4 |
#0a84ff 在白底 | 3.647 | 63.3 |
白字在 #0a84ff | 3.647 | -68.8 |
兩件事值得看。其一，#767676 與 #777777 在 WCAG 2 下一個過、一個不過，APCA 的 Lc 卻只差 0.5，是連續的；這就是「門檻是不是該硬切」的辯論所在。其二，同一個藍色 #0a84ff：在黑底 WCAG 看起來有 5.757（通過），APCA 的絕對值卻只有 38.4，遠低於它在白底的 63.3。換句話說，WCAG 2 覺得黑底上的藍字比白底上好很多，APCA 的結論相反。APCA 的字級與字重對照表我這次沒有打開，所以不下「到底夠不夠用」的結論；這只是顯示兩個演算法對深色模式的判斷可能分歧。這些數字都是我的實作，不是任何工具的輸出，Lc 的實作可能有細節誤差。
五之一、灰階邊界怎麼算出來的
為什麼 #767676 剛好過、#777777 剛好不過，可以手算。WCAG 2 的相對亮度先把每個色版從 sRGB 轉成線性值：色版值 118（十六進位 76）轉出來是 0.18116，色版值 119（十六進位 77）是 0.18447。灰色三個色版相同，所以亮度就是這個線性值本身，因為三個係數 0.2126、0.7152、0.0722 加起來是 1。白色亮度是 1，所以比值是 1.05 除以（亮度加 0.05）：118 得 4.5422，119 得 4.4781。我再往旁邊掃了一段：色版值 117 為 4.6075、116 為 4.6740，120 為 4.4151。也就是說在白底上，通過 4.5 的最淺灰色就是色版值 118，再淺一階就不及格，兩者相差約 1.4%（4.5422 與 4.4781）。
這也說明為什麼不能信任把比值顯示成一位小數的工具：4.4781 四捨五入到一位小數是 4.5，肉眼看起來剛好達標，實際不達標。這個結論只適用於灰階；彩色的邊界要逐個色版算，沒有一階一階的規律。
五之二、設計團隊現在能為 WCAG 3 做的準備
W3C 自己說這份草稿會大幅改動，所以現在能做的準備都該是不押注的。我認為有三件事不會白做，以下是我依部落格描述做的推論，不是 W3C 的建議。其一，既然核心要求建立在 WCAG 2.2 的 A 與 AA 之上，現有的 AA 稽核成果不會作廢，把每個頁面的稽核結果存成可以逐條對照的清單，之後對映新的要求比較快。其二，部落格說補充要求處理難以客觀量測的部分，這類內容（例如易讀性、認知負荷）過去常被當成「做了更好」，之後可能變成正式的報告項目，所以現在就為這些項目留下設計決策的紀錄，例如為什麼用這個字級、這個行長。其三，標籤讓法規訂定者依情境調整，意味著同一個產品在不同國家或不同業務線可能面對不同的嚴格度，設計系統的元件文件最好標明每個元件已通過哪些檢查，而不是只寫「符合 AA」。這三件事共同的原則是：把證據留在元件層，而不是頁面層。
六、容器查詢：為什麼 iPhone Duo 讓它更重要
Smashing 在 9 月 16 日的《Stop Treating CSS Container Queries Like Traditional Media Queries》（Victor Ayomipo）是我今天打開的另一篇。核心區分很清楚：媒體查詢朝外看視窗，管頁首、頁尾、主要格線這類「巨觀」版面；容器查詢朝內看元件自己的容器，管卡片、表單、導覽這類「微觀」版面。該文與搜尋摘要引用的數字是瀏覽器支援約 94%，開發者認知 86%，實際使用只有 41.4%（State of CSS 2025）。它列出三個陷阱：容器不能查詢自己，需要多一層外包；在沒有明確高度時使用 size 型容器會塌成 0 像素；容器查詢裡不能用 var()。
這跟 iPhone Duo 的關係，是同一個元件可能出現在外螢幕、內螢幕、對半分的一半、或右側軌道旁。原生 App 靠尺寸類別處理，網頁則該用容器查詢。我用該文的範例 clamp(1rem, .5rem + 3cqi, 2rem) 自算（以 16 像素為 1rem）：容器寬 320 時字級 17.6 像素，450 時 21.5，669 時 28.07，到 800 時碰到上限 32；低於約 267 寬就停在 16 的下限。就是說這個字級在內螢幕整面時會偏大（我拿 669 當寬，仍是推論值），如果你的標題用這種寫法，要看它擺在內螢幕的實際位置，而不是用視窗寬度想像。
七、NN/g 與 Smashing 的列表
NN/g 最近的條目：10 月 19 日的影片《5 Design Principles in Context: Stripe》（Rachel Krause，4 分鐘）、10 月 16 日的合成受訪者與 UX 地圖詞彙表。我只看了列表，沒打開影片，所以它對 Stripe 的結論我不報告。Smashing 首頁列表最新是 10 月 20 日的 CSS random() 一文，10 月 21 日 Intercom 導覽那篇沒有出現在我今天打開的列表中，這與昨天的狀況一致。今天沒有新的設計工具發表需要追。
八、給可摺疊裝置的驗收矩陣（自己整理）
把評測裡出現的壓力條件合起來，最小的驗收矩陣是：兩個螢幕（外、內）、兩個方向（直、橫）、鍵盤有無、Live Activity 有無，相乘是 16 個狀態；再乘上三種動態字級（預設、大、特大）是 48 個。這個數字是我自己的排列組合，不是 Apple 的測試清單，也沒有包含分割畫面與摺起或攤平的轉換；實務上不用全跑，但要把最糟的幾格（外螢幕、橫向、鍵盤、Live Activity、特大字級）固定下來。下表把評測的抱怨對應到能預先檢查的設計動作：
| 評測裡的抱怨 | 對應的設計問題 | 預先檢查 |
|---|---|---|
| 舊 SDK 的 App 浮在黑色中央 | 沒有用 iOS 27 以上的 SDK 建置 | 在建置設定與 Xcode 27.1 的模擬器裡確認版本，截一張內螢幕滿版圖 |
| 右側軌道旁邊一大片空白 | 內容沒有隨容器延展，或主要動作沒放進系統列 | 把內容區在寬容器下的最大寬度與欄數寫進設計稿，不要只畫手機版 |
| 外螢幕鍵盤加 Live Activity 放不下按鈕 | 主要動作位置固定在頂部工具列 | 把主要動作改到鍵盤上方或可滾動區，並測最糟狀態 |
| 對半分只剩窄窗 | 元件假設最小寬度比實際大 | 用 320 以下的容器寬測試每個元件 |
| 追蹤站顯示「未確認」 | 沒有公開證據，不等於沒適配 | 自己的 App 自己驗，不要靠第三方名單 |
這張表沒有「成功的案例」欄，因為我今天讀到的評測沒有給出具體的成功設計案例，只有「把空間用滿的 App 覺得可以接受」這種籠統說法；之後如果有人整理出哪些 App 是公認適配得好，值得拿來逐項拆解。
🧠 記
- 評測共識： 舊 SDK 的 App 在內螢幕是「黑海上的小 iPhone Mini」；分水嶺是用哪一版 SDK 建置，iOS 27.1 才滿版。
- 爭議在變數： 外螢幕鍵盤是否夠用取決於有沒有同時顯示 Live Activity 與工具列；最糟情況才是驗收標準。
- App 更新狀態不可全信： 更新日誌聲稱與追蹤站的「未確認」不一致，兩者說的是不同東西。
- WCAG 3： 10 月 7 日編輯草稿的對比演算法仍待定，只假設含字級字重因素；Bronze、Silver、Gold 的說法在我打開的 W3C 頁面找不到。
- 自算：
#7676764.542 與#7777774.478 在 APCA 只差 0.5；#0a84ff在黑底 WCAG 5.757 而 APCA 絕對值 38.4，兩個演算法對深色可能分歧。 - USWDS： v3.14.0 為 2026-08-18，前一版是 452 天前。
邊界： 本文所有網頁都經網頁抽取摘要，沒有讀完整原文。Gruber 的引文是我再抓一次後得到的原話，其餘評測內容是摘要轉述；Android Central、Tom’s Guide、PetaPixel 的頁面今天抓不到內文（前兩者回傳不完整、PetaPixel 回 403），沒有採用。Lovejoy 對 HTX Studio 與 The Verge 的轉述是 9to5Mac 整理中的二手。WorksOnDuo 的數字有矛盾，只用分類。669×951 點與 153 點每英寸是我的推論與記憶，沒有 Apple 一手資料。APCA 計算是我依 apca-w3 常數的自實作，未用外掛交叉驗證。沒有任何一台 iPhone Duo 在我手上。
✍️ 實踐
用 30 分鐘為專案的設計 token 做一次「兩種演算法」的對比盤點，並檢查元件在窄容器下的行為。
- 從設計 token 或 Figma 樣式挑出 10 組實際使用的「文字色／背景色」，至少包含 3 組深色模式的組合與 2 組品牌色。
- 執行下面的腳本，同時輸出 WCAG 2 比值與 APCA Lc；把兩者排名不一致的組合記下來。
def lin(c):
c /= 255
return c / 12.92 if c <= 0.03928 else ((c + 0.055) / 1.055) ** 2.4
def rgb(h):
h = h.lstrip('#')
return [int(h[i:i+2], 16) for i in (0, 2, 4)]
def wl(h):
r, g, b = rgb(h)
return 0.2126 * lin(r) + 0.7152 * lin(g) + 0.0722 * lin(b)
def wcag(a, b):
hi, lo = sorted([wl(a), wl(b)], reverse=True)
return (hi + 0.05) / (lo + 0.05)
def y(h):
r, g, b = rgb(h)
return 0.2126729 * (r/255)**2.4 + 0.7151522 * (g/255)**2.4 + 0.0721750 * (b/255)**2.4
def apca(txt, bg):
ty, by = y(txt), y(bg)
if ty < 0.022: ty += (0.022 - ty) ** 1.414
if by < 0.022: by += (0.022 - by) ** 1.414
if abs(by - ty) < 0.0005: return 0
if by > ty:
s = (by**0.56 - ty**0.57) * 1.14
return 0 if s < 0.1 else (s - 0.027) * 100
s = (by**0.65 - ty**0.62) * 1.14
return 0 if s > -0.1 else (s + 0.027) * 100
for t, b in [('#767676', '#ffffff'), ('#777777', '#ffffff'), ('#0a84ff', '#000000')]:
print(t, b, round(wcag(t, b), 3), round(apca(t, b), 1))- 先用上面三組驗證腳本：我跑出 4.542 與 71.6、4.478 與 71.1、5.757 與 -38.4；你的結果不同就先檢查輸入格式。
- 在你的網站或元件庫找一個卡片，加上
container-type: inline-size，用瀏覽器開發工具把容器拉到 320、450、669、800 像素，確認標題與按鈕在每一個寬度仍然可讀、可點。 - 如果有 iOS App：在 Xcode 看自己的 App 用哪個 SDK 建置，並列出所有用
UIScreen.main.bounds或userInterfaceIdiom的位置，這些是最先壞的。
🔗 延伸學習
- The iPhone Duo（Daring Fireball） — Gruber 的評測，對外螢幕與分割畫面的判斷最具體，我打開並抽取了原話。
- WCAG 3.0 編輯草稿（W3C） — 10 月 7 日版，可看對比要求的占位文字與各項要求的狀態，我打開過。
- Crafting WCAG 3 for more accessible user experiences（W3C 部落格） — 9 月 25 日，說明單一核心要求、標籤與報告層級的設計，我打開過。
- Stop Treating CSS Container Queries Like Traditional Media Queries（Smashing Magazine） — 巨觀與微觀版面的區分與三個陷阱，我打開過。
💬 問 AI
我想為「可摺疊 iPhone 的介面判斷」與「WCAG 3 對比演算法」做一次設計盤點。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、版本號、數字或引文,也不要給任何投資或財務建議。
背景(請當待查證主張):
1. iPhone Duo 於 2026-10-23 開賣;評測(Daring Fireball、9to5Mac 整理、The Verge、WIRED、CNET)一致認為未用 iOS 27 以上 SDK 重建的 App 在內螢幕會有大片黑邊;Apple 的設計 What's new 頁最新條目仍是 2026-10-13(Widgets 的 HomeView、Live Activities 的限寬版面),沒有公布外螢幕點數。
2. Gruber 稱外螢幕鍵盤升起且有 Live Activity 時,放不下一對工具列按鈕;CNET 則稱鍵盤寬敞、錯誤沒有增加。
3. W3C 的 WCAG 3 編輯草稿(2026-10-07)中,文字對比判準仍是「待決定」;九月工作草稿編輯註記說演算法尚未決定,假設會含字級與字重因素;W3C 部落格(2026-09-25)描述單一核心要求、補充要求、標籤與多層報告;有第三方文章稱九月草稿為 Bronze/Silver/Gold,我在 W3C 頁面找不到。
4. 我自算(依 apca-w3 常數):#767676 在白底 WCAG 4.542、APCA 約 71.6;#777777 為 4.478、71.1;#0a84ff 在黑底 WCAG 5.757、APCA 約 -38.4,在白底 3.647、63.3。
5. Smashing(2026-09-16)稱容器查詢瀏覽器支援約 94%、開發者實際使用 41.4%。
請做:
A. 逐點驗證 1 到 5,標示「成立/部分成立/查不到」並附一手連結;特別確認 iPhone Duo 外螢幕與內螢幕的點數是否已有 Apple 公布、WCAG 3 目前是否真的沒有 Bronze/Silver/Gold。
B. 檢查我第 4 點的 APCA 實作是否有誤,並說明 APCA 的字級與字重對照表怎麼用,以及它是否已被任何法規採用。
C. 我的 App 有自訂工具列與浮動按鈕:列出外螢幕鍵盤升起且有 Live Activity 時最可能壞掉的 5 個位置,各附「不靠肉眼」的檢查方式。
D. 設計一個 5 分鐘流程,驗證任一對比外掛是否把 4.478 四捨五入成 4.5,並分別顯示 WCAG 與 APCA。
不要評論公司或人事,只談設計實務、量測方法與證據強度。