安安～我是ChiYu～
管理員準備儲存成員角色時，畫面同時冒出三則訊息：
我當時留給 AI 的需求只有一句：
系統有錯誤或提醒時，顯示一個通知。
結果三句話全部被送到頁面最上方，再統一換成黃色橫幅。
圖 1：三句話都站在頁首，真正阻止儲存的通知管道錯誤，反而離修正欄位最遠。
畫面的配色很團結，訊息的責任完全沒有。
使用者要自己判斷：哪一句正在擋住眼前操作？哪一句會影響其他頁面？哪一句只是做決定前的建議？黃色不會替產品回答這三題，紅色也不會自動讓訊息站到正確位置。
所以今天不先挑顏色，而是先問三件事：
這三個答案會把 Alert、Banner 與 Callout 分開。我也把完整操作整理在 Vibe UI Atlas 的比較頁。
圖 2：眼前的操作錯誤、跨頁公告與決策建議，分別靠近當前操作、主要內容與相關設定。
把三則訊息攤開後，位置其實不難判斷：
| 事件 | 影響範圍 | 使用者接著要做什麼 | 合適位置與元件 |
|---|---|---|---|
| 沒選通知管道就儲存 | 通知設定卡 | 補選一種管道後重試 | Alert，留在設定區附近 |
| 晚上系統維護一小時 | 成員管理與相關頁面 | 知道時間與受影響功能，必要時提早處理 | Banner，放在主要內容前 |
| 正在設定新成員角色 | 角色選擇這個決策 | 先理解最小權限原則 | Callout，貼著決策說明 |
| 儲存成功，後面沒有工作 | 當前操作已完成 | 知道結果即可 | 不硬塞進這三種；明天再談 Toast |
同一個頁面可以同時有三種訊息，前提是它們各自回答不同範圍。真正要避免的不是元件一起出現，而是所有訊息都擠到頁首，讓使用者再走一遍尋路流程。
如果訊息的下一步在某個欄位旁，距離就應該近；如果影響整個服務，才值得站到主要內容之前；如果只是決策建議，就別用警報語氣把人嚇一跳。
我先拿「請至少選擇一種通知管道」做測試，故意放到三個位置。
放到頁首 Banner 時確實醒目，但問題只發生在通知設定卡。使用者得先往上找訊息，再回頭找出是哪一組欄位有問題。
改成 Callout，語氣又像儲存前的建議，沒有明確告訴人「剛才的儲存已經失敗」。如果做成會自動消失的 Toast，使用者還沒修完，錯誤原因可能先下班。
最後，我回到網站的 Alert Demo：不選任何通知管道，直接按「儲存通知設定」。警示出現在同一張設定卡裡：
無法儲存通知設定，請至少選擇一種通知管道，再重新儲存。
鍵盤焦點仍留在儲存按鈕。訊息被宣布，但沒有擅自把焦點抓走；使用者下一步可以直接回到通知選項修正。
圖 3：通知設定儲存失敗後，Alert 出現在同一張卡片裡，訊息寫出原因與修正方法。
這種把同一句話搬錯位置的測試，比看三張完成圖更有用。訊息有沒有幫忙，不是看它有多醒目，而是看出現後能不能讓人繼續完成工作。
在這篇的產品設計語境裡，Alert 是一塊需要立刻注意、但不必把整個流程按下暫停的訊息。它可能使用 ARIA 的 alert 語意，也可能只是留在錯誤區域，再用其他 live region 策略通知變化；不能只因為畫了一個紅框，就一律加上 role="alert"。
LumenDesk 的通知設定失敗，就應該讓 Alert 靠近設定卡，並說清楚：
W3C 對 ARIA Alert 的描述很貼近這種「按下儲存後才出現的重要結果」：動態加入的訊息通常會被螢幕閱讀器宣布，也不應改變鍵盤焦點。W3C WAI-ARIA APG：Alert Pattern
但 Alert 不能取代欄位錯誤。若只有一個欄位填錯，具體修法仍要留在欄位附近；若一次有多個問題，再加上表單錯誤摘要。否則整張卡都知道出事了，只有真正填錯的地方保持沉默。
這類阻礙性錯誤也不適合幾秒後自動消失。問題還沒修正，證據就不該先離場。使用者修正通知管道並重新儲存成功後，Alert 才能收起，或改成適合的成功回饋。
還有一個很容易被忽略的細節：同一個錯誤若連續重試，不要每按一次就讓 live region 把完全相同的句子重新喊一遍。需要更新時，可以補上重試失敗的時間、次數或新的原因；內容沒有改變，就不必把輔助科技當成廣播重播機。
Alert 和 Confirmation Dialog 也不是同一件事。停用帳號或刪除資料時，使用者必須先看懂後果，再選擇取消或確認；那是 Dialog 家族。Alert 負責回報眼前狀態，不替危險操作做決定。
role="banner" 不能順手借來用第二則訊息是系統維護。
LumenDesk 預計在 8 月 12 日 22:00 到 23:00 維護，期間不能調整成員角色。它影響的不是某一個欄位，而是一段時間內的成員管理工作。
這時把通知放在主要內容前比較合理。使用者進入相關頁面時，就能看到維護時間、受影響功能與需不需要提早處理，不必等按鈕失敗後才收到一句「操作失敗」。
圖 4：維護通知放在成員管理主要內容前，交代 8 月 12 日 22:00–23:00 的時間與角色功能影響。
Banner 的內容至少要有：
產品若允許關閉 Banner，也要先決定關閉的有效範圍。只在本頁暫時收起、這次工作階段不再顯示，還是記住到事件版本變更？維護時間若從 22:00 改到 21:30，舊的「已關閉」紀錄不能讓新版公告永遠消失。實務上可以替公告建立版本或事件 ID，內容更新後重新顯示。
這裡有一個名字很像、語意卻完全不同的坑：產品設計常把通知橫條叫做 Banner，但它不等於 ARIA 的 role="banner"。
ARIA 的 banner 是網站頁首 landmark，通常包含站點識別、導覽或站內搜尋。一份文件通常不該到處出現這個 landmark。通知元件若因名稱相同就順手套上，輔助科技會讀到一排假頁首。W3C WAI-ARIA 1.2：banner role
GOV.UK 的 Notification Banner 指引也提供很實際的邊界：它適合服務整體問題、接近期限，或前一頁操作的結果；若資訊直接關係到正在處理的欄位，就應放回主要內容。表單驗證錯誤不該只靠頁首 Banner 解決。GOV.UK Design System：Notification banner
第三則訊息是「先從最小權限開始」。
它沒有回報錯誤，也不影響整個服務。這句話只需要在管理員選擇新成員角色時出現，幫忙少做一次權限過大的決定。
圖 5：Callout 留在角色選擇附近，提醒新成員先使用檢視者角色，需要時再提高權限。
Callout 的價值是補上決策脈絡。它可以放原則、範例或例外，但內容應該和附近操作直接相關。若只是把整份權限文件搬進卡片，讀者依然不知道這次該怎麼選。
Callout 沒有通用的 ARIA role。它可能依文件關係使用 aside、section，也可能只需要一般段落；不要因為有邊框、圖示或藍色背景，就全部標成 alert。
WCAG 對 Status Message 的要求是：頁面在不移動焦點的情況下新增重要狀態時，輔助科技仍要能辨識變化。靜態教學文字沒有緊急事件，不需要假裝自己正在拉警報。W3C WCAG 2.2：Status Messages
網站 Demo 可以把 Callout 標示為已閱讀，但這不等於產品一定要記住閱讀狀態。若內容會影響安全或合規，單純「看過」不能取代真正的授權規則；如果只是一般建議，也不必把每一句提示都變成永久待辦。
同一頁同時出現多則訊息時，我不會只按顏色排序。
這三種訊息可以同時存在，卻不需要互相競爭誰的背景色更亮。真正的優先順序，是使用者能不能完成眼前任務，以及不處理會造成什麼後果。
圖 6：先從使用者正在處理的任務出發，再依影響範圍把訊息放到局部操作、主要內容或決策旁。
我的判斷順序是：先找事件發生的位置，再確認影響範圍，最後寫出下一步。走完後，元件通常已經選好了，還沒必要打開配色表。
在 LumenDesk 的成員管理後台建立三種不同訊息，不要把它們全部放到頁首。
1. 通知設定表單：使用者未選任何通知管道就按儲存時，在設定區附近動態顯示 Inline Alert：「無法儲存通知設定：請至少選擇一種通知管道。」Alert 不可自動消失，需保留到問題修正；螢幕閱讀器要能得知新訊息，但不要自動移走鍵盤焦點。欄位旁仍保留具體錯誤與修法。
2. 成員管理主要內容前：顯示 Notification Banner：「8 月 12 日 22:00–23:00 進行系統維護，期間無法變更成員角色。」交代影響範圍和時間，提供「關閉通知」與重新顯示方式。以公告版本識別關閉狀態；時間或內容更新後，要重新顯示。這是視覺通知橫幅，不可使用 role="banner"，因為網站 Header 已是頁首 landmark。
3. 角色設定旁：放 Callout「先從最小權限開始」，說明新成員預設為檢視者，需要時再提高權限。它是可持續閱讀的建議，不用 role="alert"，也不要做成自動消失的 Toast。
同一錯誤重複送出時，不要無條件重複宣告完全相同的 live message；只有內容、重試結果或原因改變時才更新訊息。
這份 Prompt 沒有指定三個不同顏色，卻把 AI 最容易混在一起的地方拆開了：哪裡出現、影響多大、何時離開、要不要宣布，以及使用者下一步在哪裡。
交付前，我會逐則確認：
role="banner"？如果 Alert 只寫「發生錯誤」、Banner 沒有時間、Callout 又離決策八百公尺遠，換再漂亮的圖示也還不能交付。
最後，我把未選通知管道的錯誤留在設定卡，把維護公告放到主要內容前，再讓最小權限建議待在角色設定旁。
重新操作一次後，使用者不必來回捲動畫面找錯誤，也能在維護前看見影響範圍。三則訊息沒有互相搶工作，開頭那排黃色橫幅也終於可以拆掉。
位置解決了，時間卻又出事。
角色儲存成功，只要短暫告知；移除活動草稿後，要留下復原機會；新的專案申請則不能看過就消失。我把三件事交給 AI 時，只補了一句：
儲存完成後跳一個通知；刪除草稿後也跳同一種。新的申請同樣顯示通知。
圖 7：三件事共用同一種通知和四秒倒數；連復原入口與待處理紀錄，也被當成可以準時下班的東西。
儲存完成可以消失，刪除後的「復原」不能跟著蒸發，新的申請更不該四秒後就當作處理完畢。
明天，這三則訊息會一起走上時間軸。我們來看看 Toast、Snackbar 與 Notification 各自應該活多久，又該在什麼條件下離開。
iThome鐵人賽
看影片追技術