我的知識庫

UIUX · 2026-11-07

閱讀時間約 12 分鐘

Smashing Magazine 在 11 月 5 日刊出 Eric Bailey 的〈Making Immersive LLM Chat Experiences More Accessible〉(約 21 分鐘閱讀),主張全螢幕 AI 聊天介面對螢幕閱讀器、鍵盤與認知障礙使用者有一整組可修的問題,並給出具體做法:整頁只放一個 live region、只念完成的回覆、用 5 秒間隔播報載入中、對話列表做成單一 tab stop。讀到的程度:我用網頁擷取工具讀到這篇文章,但回傳的是工具整理的摘要,不是逐字原文,所以下面的數字(3 對 23 個 landmark、50 次 Tab 對 1 次等)是摘要裡的範例數字,引文只放摘要中的短句;我沒有自己用 VoiceOver 或 NVDA 驗證這些做法,也沒讀到文中的程式碼細節。文章範圍是 Claude、ChatGPT、Copilot、Gemini、Glean 這類全螢幕聊天 app,不含彈出式小聊天窗與行內摘要。

📖 學

一、問題根源:回覆是視覺事件,焦點卻留在輸入框

聊天介面最基本的落差是:送出訊息後,新回覆出現在畫面上,但鍵盤焦點仍停在輸入框,螢幕閱讀器使用者得不到任何訊號。作者的框架是把聊天當成一般網頁內容,適用 WCAG,並採用身心障礙的「社會模式」:造成障礙的是介面設計,不是使用者。依摘要,他列出的問題包括:串流文字若逐段播報會「抖動」到無法理解;載入狀態只有動畫時,使用者會以為程式當掉;訊息靠左右對齊表達誰說的,非視覺使用者看不到;每則訊息都包 landmark 會把 landmark 清單塞爆;很長的對話列表要按很多次 Tab;動畫與音效會干擾注意力或認知障礙者;文字放大或視窗縮小時內容被裁切或橫向溢出。

二、播報:一個 live region,只念完成的回覆

最具體的建議在 live region。做法是在 DOM 最後放一個專用的 live region,不要在每則訊息上掛 aria-live,並且只播報完成後的整段回覆,不播報串流中的片段。載入狀態則要同時有可見文字與 live region 的「載入中」文字。若載入只是動畫,摘要說作者建議送出後約 5 秒播報「Loading」,之後每 5 秒重複,直到回覆完成,完成時立刻播報回覆;也可以輪替「研究中」「思考中」「規劃中」這類字樣表示進度。對新的 ariaNotify() API,作者的判斷是先不採用,理由是支援有限、polyfill 有但書、使用者也不太願意升級,改用 TetraLogical 的 live region 技巧。這是一個值得學的取捨:好用的新 API 不等於現在就該用。

三、結構:訊息用 article 加隱藏標題,landmark 要節制

每則訊息包成 article,裡面放一個視覺隱藏的標題(sr-only、tabindex="-1"),內容為「You said:」或「{代理名稱} said:」,並把同樣文字放進 aria-label,用來繞過螢幕閱讀器的 bug,也符合 WCAG 2.2 的 Name, Role, Value(4.1.2)。頁面級 landmark 則是:對話清單用 nav、訊息區用 main、輸入框用 form、生成內容用 aside;避免每則訊息一個 section。摘要中的對照是 VoiceOver 在一種寫法下列出 3 個 landmark,另一種是 23 個。作者也明確不建議 ARIA 的 feed pattern,理由是太複雜、容易出錯。

四、鍵盤:composite widget 與 F6

第一個連結應是「跳到主要內容」,必要時再加跳到輸入框、設定的連結。對話列表做成 composite widget:整個清單只佔一個 tab stop,用上下鍵移動、Home/End 跳頭尾、支援打字搜尋。摘要用的例子是 50 個對話,從 50 次 Tab 降到 1 次。另外作者建議 landmark 之間用 F6 切換:網頁用 Ctrl+F6 與 Ctrl+Shift+F6,用 Electron、Tauri 包裝的原生 app 則用 F6 與 Shift+F6;每個 landmark 要有 id、tabindex="-1" 與可存取名稱,以監聽器依序移動焦點,輸入框直接聚焦,最後一則訊息用 data-last-message 屬性標出。因為 F6 是較老的技巧,他建議在設定裡教使用者。

五、可調整性:把「顆粒度」交給使用者

作者的一句核心觀點(摘要轉錄):客製化是無障礙的核心。具體是提供播報顆粒度的開關(例如推理過程、搜尋、檔案編輯各自可開關,也可選擇同時在畫面上隱藏這些播報)、動畫開關(預設尊重 prefers-reduced-motion)、音效開關(並提供原生通知、badge、email、應用內橫幅等替代)、以及可編輯或停用的快捷鍵,涵蓋不同鍵盤配置。對特殊內容:表格只念摘要,例如「4 欄 36 列」加一句概述;程式碼區塊念檔名或類型與行數,例如「settings.json,738 行」,完整內容仍保持可瀏覽。作者同時提醒,這類字串解析邏輯脆弱、維護成本高,能長期維護才做。

六、我的判讀

這篇把「代理式 AI 介面」最常見的串流體驗,轉成可驗收的規格:播報時機、結構、鍵盤路徑、偏好設定,四件事都能寫成測試項目。我的歸納(非原文)是:串流是對視覺使用者的好設計,對非視覺使用者則要換成「完成後一次給」的等價體驗,等價不等於相同。限制也要說:這是單一作者的實務建議,摘要中沒有看到對照實驗或使用者測試數據;他提到的做法在各種螢幕閱讀器與瀏覽器組合上的實際表現,我沒有驗證;而且這些建議針對全螢幕聊天,彈出式小窗的做法可能不同。

🧠 記

  • 來源: Smashing Magazine,Eric Bailey,2026-11-05;讀到的是工具整理的摘要,非逐字原文,未親測。
  • Live region: DOM 末端一個專用區域;只播完成的回覆,不播串流片段;每則訊息不掛 aria-live。
  • 載入: 可見文字加 live region 同步;僅動畫時約 5 秒後播報、每 5 秒重複。
  • 結構: 每則訊息 article 加隱藏標題「You said:」;landmark 不要每則一個(摘要範例 3 對 23)。
  • 鍵盤: 對話列表單一 tab stop、方向鍵、Home/End、打字搜尋;F6 在 landmark 間跳。
  • 偏好: 播報顆粒度、動畫、音效、快捷鍵都要可調。
  • 新 API: ariaNotify() 作者暫不採用,理由是支援與 polyfill 疑慮。
  • 未驗證: 各螢幕閱讀器組合的實際效果;無成效數據。

✍️ 實踐

用 40 分鐘稽核一個你做的或常用的聊天介面。

  1. 開啟 macOS VoiceOver(Command+F5)或 NVDA,送出一則訊息,記下:回覆完成時有沒有被念出來、串流中有沒有被念成碎片、載入中有沒有任何聲音提示。
  2. 在瀏覽器開發者工具檢查每則訊息有沒有各自的 aria-live,以及 landmark 數量;用 VoiceOver 的 landmark 轉盤(Control+Option+U)看清單長度。
  3. 只用鍵盤:從頁面頂端按 Tab,數需要幾次才到輸入框、才到某個舊對話,記下有沒有跳過連結。
  4. 把瀏覽器文字放大到 200% 並縮小視窗,看訊息、程式碼區塊與表格有沒有被裁切或橫向捲動。
  5. 檢查系統開啟「減少動態效果」後,載入動畫與音效是否仍然出現。
  6. 把五項結果寫成通過或不通過的表,挑最嚴重的一項,寫一句修復方案(例如「串流期間不播報,完成後由單一 live region 念出」)。

🔗 延伸學習

💬 問 AI

我要稽核一個全螢幕 AI 聊天介面的無障礙。請分成「來源說的」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、數字或引文。
 
背景(請當待查證主張):
Smashing Magazine 2026-11-05 Eric Bailey〈Making Immersive LLM Chat Experiences More Accessible〉主張:整頁用一個專用 live region、只播報完成的回覆、僅動畫載入時約 5 秒後播報並每 5 秒重複;每則訊息用 article 加隱藏標題而不是 landmark;對話列表做成 composite widget;用 F6 在 landmark 間切換;ariaNotify() 暫不採用。我只讀到工具整理的摘要。
 
請做:
A. 對照 WCAG 2.2(4.1.2、4.1.3 狀態訊息、1.4.10 Reflow、2.2.2、2.3.3)與可查證的螢幕閱讀器行為,說明哪些主張有依據、哪些只是作者經驗,附連結。
B. 針對「串流期間不播報」,列出支持與反對的理由(例如想即時聽的使用者),並提出可由使用者選擇的設計。
C. 給我一份可執行的稽核清單(VoiceOver、NVDA、純鍵盤、200% 放大、減少動態效果),每項含通過判準。
D. 說明 ariaNotify() 目前的瀏覽器支援狀況,並標示你的資料日期與來源。
只談介面設計與無障礙,不評論公司或人事。

反向連結