NN/g 在 10 月 23 日發表的〈UX Disciplines: Glossary〉把「Agent Experience（AX）」列為一門獨立的 UX 領域，定義是「設計數位產品與服務，讓 AI agent 代替人操作時能有效理解並使用」。這個定義在實務上有一個可以直接檢查的對應物：Chrome 團隊 6 月 22 日的〈A developer toolkit to make your website agent-ready〉寫明「agent 以無障礙樹（accessibility tree）作為主要資料模型」，Lighthouse 也已經有一個「Agentic Browsing」類別在量這件事。今天的主軸是：為 agent 設計的那一半，大部分其實就是無障礙工作本身。
承接 昨日 UIUX：昨天看 iPhone Duo 的適配標籤與展開圖示，今天換到另一條持續累積的線，也就是介面的「使用者」不再只有人。本文所有網頁都經網頁抽取摘要，不是我讀完整原文；數字在不同抽取之間有出入的地方，我會直接標明。
📖 學
一、昨天待驗項對帳
| 昨天的待驗 | 今天查到 | 狀態 |
|---|---|---|
| Apple 設計「What’s new」頁有無新條目 | 今天抓取成功（昨天是 500 錯誤），最新仍是 10 月 13 日的 Widgets（新增 HomeView 指引）與 Live Activities（新增限寬版面指引）；iPhone Duo 的專頁是 9 月 9 日、產品外框圖是 9 月 18 日 | 已確認：10 月 13 日後沒有新條目 |
| WCAG 3 對比演算法 | W3C 的 TR 頁面是 2026 年 9 月 10 日的工作草稿，寫「WCAG 3 使用的對比演算法尚待決定」，並假設演算法會含字級與字重因子；昨天讀到的編輯草稿是 10 月 7 日版，兩者結論相同 | 仍待定 |
| 各主流 App 適配狀態 | 搜尋摘要提到評測中 Google Maps、Gmail、Uber 尚未針對大螢幕更新；我沒有打開那篇原文，來源是搜尋結果的彙整敘述，只能當線索 | 部分線索，未驗證 |
| 外螢幕與內螢幕的點數、HomeView pt、11 月 13 日實機字高、Pitre 評分規則、Guidelines 遵守率 | 今天沒有新資料，也沒有再追 | 待驗 |
這張表想說的是：Apple 的設計文件這一週是靜止的。iPhone Duo 10 月 23 日開賣後，一手規格沒有補件，補件的是評測與第三方範例。
二、NN/g 的詞彙表：AX 與 UI、視覺、互動的切分
NN/g 的 Raluca Budiu 在 10 月 23 日發表〈UX Disciplines: Glossary〉，一篇 10 分鐘的定義彙整。我對同一頁做了三次抽取，回報的領域數分別是 28、26 與 30，彼此對不上，所以我不寫總數，只引用我兩次抽取都一致的定義。
AX 的定義是：設計數位產品與服務，使其「能被 AI agent 在代替人行動時有效地理解與操作」。UI 設計被定義為設計產品的介面，即由元件（按鈕、可點連結）、設計元素（圖片、圖示、標題）與互動構成的集合；互動設計是設計「產品與使用者如何彼此回應」，包含可採取的動作、系統給的回饋，以及動作後狀態如何改變；視覺設計是決定線條、形狀、色彩、格線與空間如何組合。詞彙表自己的結論是 UI 設計等於互動設計加視覺設計，而 UX 的範圍比介面更大，含研究、策略與內容。內容設計被說成比 UX 寫作更廣，後者只管介面文案。
設計上值得抓的是切分的方式。互動設計的定義裡「系統給什麼回饋、狀態怎麼變」這一段，對 agent 與對人是同一套問題：agent 點了一個按鈕，要靠頁面狀態的改變才知道成功與否。這是我的連結，詞彙表本身沒有展開 AX 與互動設計的關係。
三、Chrome：agent 讀的是無障礙樹
Chrome 的 Kasper Kulikowski 與 Michael Hablich 在 6 月 22 日的文章列出三個部分：Lighthouse 的 Agentic Browsing 類別（需 Chrome 150 以上，發表時為資訊性、沒有基準分）、WebMCP 標準（在既有網站上對 agent 暴露結構化工具）、以及 Chrome DevTools for Agents（模擬 agent 互動並可直接呼叫 Lighthouse 稽核）。文中原句是「agents rely on the accessibility tree, derived from DOM for assistive technology (AT), as their primary data model」，我是從抽取摘要讀到這句話，沒有核對上下文。WebMCP 的測試要在 chrome://flags/#enable-webmcp-testing 開旗標。
第三方整理（debugbear、savvy.co.il 等，我只讀搜尋摘要，沒有逐一打開）說 Lighthouse 13.3 在 5 月 7 日加入這個第五類別，共六項稽核，其中三項計分、權重各為 1：無障礙樹是否乾淨、累積版面位移（CLS）、llms.txt 檔案是否存在；另外三項 WebMCP 稽核權重為 0。自算：三項計分稽核權重合計 3，各占加權分數的三分之一（33.3%）；Lighthouse 13.3 的 5 月 7 日到 Chrome 的工具組文章 6 月 22 日相隔 46 天。這些細節若要拿去做決策，請回到 Lighthouse 的官方文件核對。
這裡對設計實務有意義的是：六項稽核裡，會被設計決定直接影響的有兩項，無障礙樹（標籤、角色、名稱是否清楚）與版面位移（載入中元素是否跳動）。這兩項在人類使用者身上早就是可用性問題，現在多了機器讀者。
四、Cassidy Williams：bot 變成多數之後，無障礙有了新的理由
Cassidy Williams 寫了一篇〈Accessibility and the Internet〉，主張網路的商業模式正隨 bot 流量過半而改變，連帶讓無障礙因為務實而非人道的理由變得重要：若人類操作不了一個網站，agent 也可能操作不了。文章頁面顯示的日期是 10 月 1 日，但 Smashing 首頁的抽取把它列在 10 月 22 日附近，兩者不一致，我以文章頁為準，不確定。她引用 Cloudflare 的「Bot vs. Human」追蹤；作者自己的說法是對未來樂觀，文中沒有明確的操作建議。
數字補充：Cloudflare 的 CEO 在 6 月 3 日說自動化流量首度超過人類，我讀到的報導寫 57.4% 或 57.5% 的 HTTP 請求來自 bot（兩個來源差 0.1 個百分點，我不選邊），人類約 42.6%。自算：以 57.4 比 42.6，約每 1 個人類請求對應 1.35 個 bot 請求。這個比例量的是 HTML 內容的請求次數，不是使用者停留時間，報導自己也提醒，以互動時間與影音串流量來看人類仍是主要使用者。所以「bot 過半」不能直接推成「介面主要使用者是 agent」。
五、一張給今天的檢查表
| 今天讀到的事 | 設計動作 | 驗證方式 |
|---|---|---|
| agent 以無障礙樹為主要資料模型 | 每個可操作元件都有可被讀出的名稱與角色 | 開瀏覽器開發者工具的無障礙樹檢視，逐一檢查主要流程上有沒有沒名稱的按鈕 |
| 互動設計包含「狀態如何改變」 | 每個動作後都有可被讀出的成功或失敗狀態 | 只靠無障礙樹與頁面文字，不看畫面，走一遍結帳或表單流程 |
| 版面位移是 Agentic Browsing 的計分項 | 非同步載入的區塊先保留空間 | 用 Lighthouse 對主要頁面跑一次，記下 CLS 與無障礙樹兩項 |
| 詞彙表把 AX 與 UI、互動分開 | 設計評審新增一欄「agent 能不能完成」，不取代「人能不能完成」 | 評審紀錄分兩欄，不混成一個通過／不通過 |
🧠 記
- NN/g 把 AX 列為獨立領域： 定義是讓產品能被 AI agent 代替人時有效理解並操作；詞彙表的領域總數我三次抽取不一致，不引用。
- Chrome 的說法： agent 以無障礙樹為主要資料模型；Agentic Browsing 稽核需 Chrome 150 以上。
- Lighthouse 細節（第三方整理）： 六項稽核、三項計分（無障礙樹、CLS、
llms.txt）、WebMCP 三項權重為 0；自算計分項各占 33.3%。 - bot 流量： 約 57.4% 或 57.5% 的 HTML 請求來自 bot，自算約 1.35 比 1；量的是請求次數，不是人類注意力。
- Apple 設計文件與 WCAG 3： What’s new 最新仍是 10 月 13 日；WCAG 3 對比演算法在 9 月 10 日工作草稿仍待決定。
邊界： 本文所有網頁都經網頁抽取摘要，沒有讀完整原文。NN/g 詞彙表的領域數三次抽取不一致，我沒有採用。Lighthouse 13.3 的日期與權重來自第三方文章，不是我讀到的官方文件。bot 占比 57.4 與 57.5 兩種數字並存。Cassidy Williams 文章的日期兩個來源不一致。Google Maps、Gmail、Uber 未適配只是搜尋彙整的敘述，沒有原文。Spotify、TikTok、YouTube 適配狀態、外內螢幕點數、HomeView pt、11 月 13 日實機字高、Pitre 評分規則、Guidelines 遵守率今天都沒查到。沒有任何一台 iPhone Duo 在我手上。
✍️ 實踐
用 30 分鐘為你的產品做一次「不看畫面」的無障礙樹走查，同時回答「人」與「agent」是否能完成同一件事。
- 挑出產品最重要的一條流程，例如註冊、結帳或預約，寫下它的步驟數。
- 打開瀏覽器開發者工具的無障礙樹檢視，從第一步走到最後一步，只看樹裡顯示的名稱與角色，不看畫面，把「沒有名稱的可點元件」逐一記下來。
- 對每個缺名稱的元件，補上可見文字或
aria-label，優先用原生元素（button、a、label），不要用一堆div再補角色。 - 動作後的狀態檢查：每一步完成後，頁面上是否有可被讀出的成功或錯誤訊息（例如放進有
role="status"的區域），沒有就補。 - 用 Lighthouse 對同一頁面跑一次，記錄無障礙與 CLS 兩項的分數，改完再跑一次，用前後差距當作這次走查的成果，不用外推到其他頁面。
🔗 延伸學習
- UX Disciplines: Glossary（NN/g） — 10 月 23 日，AX 與 UI、視覺、互動設計的定義彙整，我打開並抽取過。
- A developer toolkit to make your website agent-ready（Chrome for Developers） — 6 月 22 日，Lighthouse Agentic Browsing、WebMCP 與無障礙樹作為 agent 資料模型的一手說明，我打開並抽取過。
- Accessibility and the Internet（Cassidy Williams） — bot 流量過半與無障礙關係的評論，無具體操作建議，我打開並抽取過。
- Apple 設計「What’s new」 — 今天抓取成功，最新條目仍是 10 月 13 日。
💬 問 AI
我想為「讓產品同時對人與 AI agent 都可用」做一次設計盤點。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、版本號、數字或引文,也不要給任何投資或財務建議。
背景(請當待查證主張):
1. NN/g 在 2026-10-23 發表 UX Disciplines: Glossary,把 Agent Experience(AX)列為獨立領域,定義為讓產品能被 AI agent 代替人時有效理解並操作;UI 設計 = 互動設計 + 視覺設計。我不確定該文列出的領域總數。
2. Chrome 團隊在 2026-06-22 的 agent-ready 工具組文章寫「agent 以無障礙樹為主要資料模型」;Lighthouse 的 Agentic Browsing 類別需 Chrome 150 以上。
3. 第三方文章稱 Lighthouse 13.3(2026-05-07)有六項稽核,其中無障礙樹、CLS、llms.txt 各計分權重 1,WebMCP 三項權重 0。
4. Cloudflare 稱 2026-06-03 自動化流量首度超過人類,約 57.4% 或 57.5% 的 HTML 請求來自 bot;我自算約 1.35 比 1,但這量的是請求次數,不是人類注意力。
5. 我讀到 W3C WCAG 3 工作草稿(2026-09-10)仍寫對比演算法尚待決定;Apple 設計 What's new 頁最新條目是 2026-10-13。
請做:
A. 逐點驗證 1 到 5,標示「成立/部分成立/查不到」並附一手連結;特別確認 NN/g 詞彙表的領域總數,以及 Lighthouse Agentic Browsing 各稽核的權重是否與第三方說法一致。
B. 說明「無障礙樹乾淨」在 Lighthouse 該項稽核中實際檢查哪些條件,哪些設計決策會直接影響它。
C. 我的產品有結帳流程與一個非同步載入的推薦區塊:列出最可能讓 agent 與螢幕閱讀器同時卡住的 5 個位置,各附「不看畫面」的檢查方式。
D. 設計一個 30 分鐘流程,用無障礙樹與 Lighthouse 對一條主要流程做前後對照,並說明這個對照能與不能證明什麼。
不要評論公司或人事,只談設計實務、量測方法與證據強度。