安安～我是ChiYu～
昨天才把專案結構和命令入口整理清楚，我按下成員列上的「停用帳號」，畫面中央立刻出現一張白色卡片。後面有灰色遮罩，右下角還放了一顆紅色按鈕。
昨天收尾就停在這個畫面。下面是我依照第一版問題，在網站上重建的錯誤現場；它不含真實帳號與個人資料：
圖 1：和昨天結尾是同一張畫面。彈窗只問「確定要停用嗎」，沒有說停用誰；初始焦點落在危險操作，背景卻仍然能點。
看起來非常像一個完成品。
需求其實只有這樣：
按停用時跳出一個漂亮的彈窗。
「漂亮」很快就做到了。背景能不能繼續操作、Escape 會不會取消、初始焦點跑去哪裡，以及停用後究竟影響誰，全部還在場外排隊。
Vibe Coding 遇到彈窗時，很容易先談卡片寬度、遮罩深淺和按鈕顏色。這些都能調，但使用者一旦被中斷，真正決定介面能不能用的，是他為什麼被攔下來、現在必須回應什麼，以及還能不能安全離開。
今天就依中斷程度拆開 Dialog、Modal Dialog、Non-modal Dialog 與 Alert Dialog，再補上一個常見的危險確認情境。這一篇沿用 LumenDesk 的虛構成員管理情境，所有人名、帳號與資料都是示範資料。
我把這四種語意和一種確認情境放進 Vibe UI Atlas 的 Dialog 家族比較頁。同樣浮在頁面上，背景是否還能操作，會讓它們走向完全不同的互動。
圖 2：白色卡片和灰色遮罩只能說明外觀；是否中斷背景、需不需要立即回應，才決定 Dialog 類型。
停用成員之前，我不會先問紅色夠不夠醒目。我會先確認停用誰、後果能不能復原，再看 Escape 是否適合作為取消。中斷越強，理由就得越具體。
我實際打開網站上的 Confirmation Dialog，沒有急著去按「停用帳號」。第一個動作是看焦點落在哪裡，接著按 Escape。
這次 Demo 的結果符合預期：開啟後，初始焦點停在安全的「取消」；按下 Escape，林子安的帳號沒有被停用，Dialog 關閉，焦點也回到原本的「停用成員帳號」按鈕。畫面下方同步顯示「已用 Escape 取消，將回到開啟按鈕」。
| 我檢查的瞬間 | 實際結果 | 我為什麼在意 |
|---|---|---|
| Dialog 剛開啟 | 焦點先停在「取消」。 | 使用者不會順手按 Enter 就執行危險動作。 |
| 按下 Escape | Dialog 關閉，帳號狀態不變。 | 鍵盤使用者有可預期的撤退方式。 |
| Dialog 關閉 | 焦點回到觸發按鈕。 | 不必從頁首重新尋找剛才的位置。 |
| 危險動作文案 | 按鈕寫「停用帳號」，沒有只寫「確定」。 | 按下前還能再確認真正後果。 |
這段測試沒有任何華麗動畫，卻比紅色按鈕更能決定危險確認是否安全。Prompt 只寫「做一個刪除確認視窗」，AI 很可能把外觀做對，焦點卻直接放到危險操作；關閉後，也可能把使用者送回頁面最上方。
所以我會明確交代初始焦點、Escape、背景操作與焦點歸還。紅色只是提醒，取消路徑才是使用者還沒做決定時的保險。
先把名詞分清楚：Confirmation Dialog 是產品設計裡常見的情境名稱，不是另一個獨立的 ARIA 角色。實作時仍要依中斷程度與訊息性質，選擇一般 dialog 或 alertdialog。它不能因為按鈕是紅色，就自動多出一套語意。
| 當下情境 | 背景能否操作 | 使用者需要回應什麼 | 合適的元件 |
|---|---|---|---|
| 查看輔助資訊，同時還要對照原頁 | 可以 | 看完或自行關閉 | Non-modal Dialog |
| 短暫完成一個聚焦的小任務 | 不可以 | 完成、取消或關閉 | Modal Dialog |
| 系統出現不可忽略的警示 | 不可以 | 理解訊息並明確回應 | Alert Dialog |
| 即將停用帳號、刪除草稿或覆蓋資料 | 不可以 | 確認對象與後果，再取消或執行 | 危險確認情境；依需求使用 Modal Dialog 或 Alert Dialog |
這張表可以擋下兩種相反的誤用。使用者還要比對原頁資料時，不必為了一張浮動卡片鎖住整個背景；危險操作真的需要停下來確認時，也不能讓背景照樣可點。
把這四層畫成選型路徑後，判斷會更直覺：
圖 3：先看背景工作是否能繼續，再判斷訊息重要性與動作風險；關閉後的焦點路徑也要一起規劃。
接下來逐一看四種語意與危險確認情境。它們可能使用很接近的卡片樣式，對使用者做出的承諾卻不一樣。
Dialog 元件頁先示範一個暫時浮在目前頁面上的內容區域。Dialog 可以只提供補充資訊，也可能要求使用者先完成一件工作。
圖 4：Dialog 只是一個統稱；背景是否暫停，還得由任務情境繼續決定。
畫面浮在上面，不會自動讓它變成 Modal。真正的分界是使用者能不能繼續操作背景，以及不先處理 Dialog 會不會造成問題。
如果只是邊看原頁、邊參考一段資訊，可以往 Non-modal Dialog 走；需要先完成或取消一個小任務，才考慮 Modal Dialog。警示與危險確認則還要多看訊息重要性和後果。
Modal Dialog 元件頁使用邀請成員的確認工作。送出前需要核對收件人與角色，在確認或取消以前，背景的成員列表不應再被誤點。
圖 5：Modal Dialog 要求使用者先處理眼前任務，背景不可操作，關閉後焦點回到入口。
模態不是比較有質感的外觀，而是暫時中斷背景工作。一個可用的 Modal Dialog 至少要完成下面幾件事：
W3C 的 Modal Dialog Pattern 也要求開啟時把焦點移進 Dialog，關閉後通常回到觸發元素。至於初始焦點，沒有一個位置適合所有彈窗；要依內容與任務決定。LumenDesk 這次處理不可逆風險，所以我刻意先放在「取消」，避免使用者順手按下 Enter 就停用帳號。W3C WAI-ARIA APG：Modal Dialog Pattern
可以到 Modal Dialog 操作 Demo按一次 Tab、Shift + Tab 和 Escape。若焦點還能鑽到背景，遮罩再深也只是視覺效果。
管理員查看成員資料時，可能想開一個小型檢視器確認最近登入時間與角色，同時繼續整理背景清單。Non-modal Dialog 元件頁就是這種情境。
圖 6：Non-modal Dialog 提供暫時工具或參考資訊，背景工作仍然可以繼續。
最容易出現的 bug，是畫面沒有遮罩，程式卻加上 aria-modal="true" 或把焦點鎖在 Dialog 裡。視覺說背景可以用，鍵盤行為卻把人困住，兩邊各自宣布一套規則。
HTML 原生 <dialog> 可以透過 show() 開啟為非模態，也能用 showModal() 進入模態狀態。差別仍在是否阻斷背景互動，不在 CSS 長得像不像。MDN：<dialog>
打開 Non-modal Dialog 操作 Demo後，再按背景的「更新背景工作」。計數有增加，才表示它真的沒有把背景按下暫停。
Alert Dialog 元件頁處理使用者必須讀到並回應的訊息，例如同步失敗、權限異常，或不理解就無法安全繼續的系統狀況。
圖 7：這張網站 Demo 把同步失敗放進 Alert Dialog；但如果使用者不必立刻回應，改用頁內 Alert 或 Banner 會更合適。
「有 3 位成員的權限尚未同步，請稍後重試。」雖然重要，卻不一定需要 Alert Dialog。若使用者看完就能繼續其他工作，頁內 Alert 或 Banner 已經足夠；硬要他按一次「我知道了」，只是在失敗之外再附贈一次中斷。「草稿已自動儲存。」就更不必出動 Dialog，讓狀態在原頁回報即可。
比較適合的情境是：「權限同步失敗，現在無法安全完成停用。請重新驗證，或取消這次操作。」使用者必須當場選擇，工作才能繼續。W3C 將 Alert Dialog 定義為會中斷流程、傳達重要訊息並取得回應的模態對話框；若訊息只需要被讀到、不需要立刻回應，通常應使用 Alert，而不是把背景一起鎖住。W3C WAI-ARIA APG：Alert Dialog Pattern、W3C WAI-ARIA APG：Alert Pattern
Alert Dialog 操作 Demo只提供「我知道了」。這裡不靠按鈕數量製造重要感，訊息、原因和下一步寫清楚比較有用。
停用帳號、刪除專案、清空資料與覆蓋內容都會造成明確後果。Confirmation Dialog 元件頁讓使用者在動作前看見對象、影響與取消出口。
圖 8：對話框直接寫出要停用林子安、停用後的影響，以及「取消」與「停用帳號」兩條路。
不夠好的文案只有一句：
確定要繼續嗎？
使用者不知道「繼續」指什麼、影響誰，也不知道之後能不能救回來。這次 Demo 把事實寫完整：
停用林子安的帳號？停用後，林子安將無法登入 LumenDesk，目前的專案指派會保留。
按鈕也使用「停用帳號」，沒有只寫「確定」。紅色 Danger Token 可以提醒風險，真正幫助判斷的仍是具體對象與後果。
在 Confirmation Dialog 操作 Demo裡，這個確認情境使用 Modal Dialog：初始焦點先停在「取消」，Escape 等同取消，背景不能被操作，關閉後焦點回到「停用成員帳號」。只有當訊息重要到必須中斷流程並立刻取得回應時，才改用 alertdialog。即使真的按下「停用帳號」，這也只是操作示範，不會變更真實帳號資料。
原始需求只有「漂亮彈窗」。如果工作是停用帳號，我會改成下面這樣：
在 LumenDesk 製作一個 Modal Dialog，用於確認是否停用「林子安」帳號。這是產品上的危險確認情境，不要自行發明新的 ARIA 角色。
標題與內文要寫出帳號名稱、停用後無法登入，以及目前的專案指派會保留。提供「取消」與使用紅色 Danger Token 的「停用帳號」按鈕；不要使用模糊的「確定」。
開啟時背景不可操作，初始焦點放在「取消」。Escape 視同取消，關閉後焦點回到開啟入口。只有當流程必須因重要訊息立刻取得回應時，才改用 alertdialog。這是 Demo，不要真的變更帳號資料。
這段 Prompt 交代風險、文案、焦點、鍵盤行為與安全限制。AI 可以更換卡片樣式，卻不能把取消路徑和帳號後果一起換掉。
交付前，我會依序確認：
使用者還沒做出決定時，系統不能偷偷替他越過那條線。這就是我先按 Escape、而不是先測紅色按鈕的原因。
這次按下 Escape 後，帳號狀態沒有改變，Dialog 關閉，焦點也回到原本的「停用成員帳號」。開頭那句「漂亮彈窗」，現在多了可以驗收的背景規則、焦點路徑、文案與取消行為。
不過管理員在決定停用以前，還想查看林子安的部門、角色和目前專案。需求也很直白：
「點成員資料表的一列，顯示完整資料。」
下面這張圖，是我依照第一版需求在網站上重建的錯誤現場，不含真實帳號與個人資料：
圖 9：林子安的資料確實出現了，其他成員列、部門與角色卻全部被遮罩壓在後面。想比較下一位，只能先關閉，再重新打開。
這次 Modal 沒有做壞，它只是回答錯了問題。使用者不是要停下來處理一件獨立任務，而是想一邊查看詳細資料、一邊保留原本的成員清單。把背景鎖住之後，剛才拿來比對的脈絡也一起消失。
明天，我們沿著這個問題認識 Drawer、Sheet 與 Bottom Sheet，看看詳細資料出現時，原本的清單到底該留下多少。
<dialog>（查閱日期：2026-08-07）
iThome鐵人賽
看影片追技術