一 先分非模態與模態
畫面同時有關鍵警報、一般提示和需要確認的操作時，先決定是否必須中斷目前工作。非模態警報區固定在主畫面可見位置，讓操作員仍能查看設備與切換頁面；模態dialog只用於確實需要使用者回應的短流程，例如確認刪除草稿或承認一個資訊事件。模態不是提高警報等級的同義詞。
關鍵警報可以在非模態區使用固定位置、對比、聲音與持續記錄呈現，但資訊呈現不等於安全迴路。不要讓一個彈窗遮住所有警報，也不要把紅色框或最高z-index當成安全保護。安全停機、聯鎖與人身保護必須由獨立且經驗證的設計負責。
關鍵警報區要在不同頁面保持一致位置與名稱，避免操作員換頁後找不到。警報摘要至少包含來源、狀態、發生時間與可查看的歷史入口；顏色應搭配文字或圖示，不能只依紅綠色判讀。
| 介面類型 | 焦點行為 | 適合內容 |
|---|---|---|
| 非模態alert區 | 不搶焦點 | 持續警報、連線品質、狀態變更 |
| 一般dialog | 依流程進入並可關閉 | 查詢或編輯輔助資料 |
| alertdialog | 暫時限制焦點 | 需要明確回應的確認訊息 |
| 安全控制 | 不由HMI遮罩保證 | 由獨立安全設計處理 |
W3C APG指出alert用於不打斷工作的短訊息，而alertdialog是會中斷流程並取得回應的模態對話框。實作時先畫出主畫面、警報區和dialog的空間，再定義焦點與鍵盤路徑，不能只調CSS層級。
二 層級與焦點設計
建立三層資訊：固定警報區、一般通知層、目前唯一的確認dialog。固定警報區保留關鍵警報摘要與跳轉入口；模態期間入口暫停互動，關閉後恢復；一般通知可排隊但不能蓋住摘要；確認dialog開啟時，焦點移入dialog，Tab與Shift+Tab只在dialog內循環，Escape是否關閉要依操作風險明確決定。不要同時堆疊多個模態視窗。
dialog必須有可讀標題、訊息、明顯的取消或關閉按鈕，以及可用鍵盤操作的主要按鈕。關閉後焦點通常回到觸發它的元素；若觸發元素已不存在，回到合理的流程位置。長訊息先把焦點放在標題或說明起點，避免第一個按鈕讓輔助技術跳過上下文。
警報區的更新不應把焦點從正在輸入的欄位搶走。可以用可辨識的文字、圖示、聲音或非模態live region通知；頻繁更新要合併同類事件，避免每次輪詢都打斷操作。若使用者選擇查看警報，才把焦點移到具體項目。
鍵盤測試還要包含焦點可見指示與反覆開關dialog。若關閉後觸發按鈕已被移除，焦點應回到合理的流程元素；若沒有可用元素，要把焦點放在主內容標題並留下可理解的狀態。
| 測試事件 | 預期焦點 | 預期結果 |
|---|---|---|
| 非模態警報新增 | 焦點留在原欄位 | 警報區可見且可進入 |
| 確認dialog開啟 | 焦點進入標題或按鈕 | Tab不離開dialog |
| 按取消/關閉 | 回觸發元素 | 主畫面可繼續操作 |
| 警報持續更新 | 不搶焦點 | 狀態更新但不打斷 |
三 警報與確認的分工
假設主畫面已有高溫警報，操作員正在編輯配方。高溫警報摘要應留在固定警報區，顯示來源、時間、目前狀態與查看入口；若要確認刪除未送出的配方，才開啟alertdialog。dialog的確認只確認刪除這個介面資料，不應把高溫警報標成已處理，也不應呼叫PLC Reset。
若兩個事件同時到達，先依產品定義排程，不用z-index決定哪個比較重要。一般通知可延後；需要回應的dialog要有明確優先順序與取消方式；關鍵警報仍在非模態區持續可見。對話框開啟期間，外部警報摘要可維持可見，但模態開啟時不可互動；若需查看，先取消或關閉對話框再跳轉，但不能被遮罩到使用者完全不知道有事件。
常見失敗是每個錯誤都使用modal，結果操作員只能不停按OK；另一種失敗是所有內容都放非模態toast，訊息很快消失且沒有歷史。應依是否要中斷、是否需要回應、是否要持續可查三個問題決定呈現。警報事件本身需保存事件ID、來源、發生時間、確認狀態與歷史。
當警報連續到達時，將相同來源的事件合併成摘要，保留每筆事件ID與時間；不要每一筆都開一個模態窗。若使用者正在輸入資料，非模態區可增加未讀數，但不能把輸入游標移走。
| 情境 | 呈現 | 不要混淆 |
|---|---|---|
| 高溫持續 | 固定警報區+歷史 | 不等同安全停機 |
| 刪除草稿確認 | alertdialog | 不改PLC狀態 |
| 連線短暫恢復 | 非模態通知 | 不遮蓋警報 |
| 多筆事件 | 清單/摘要 | 不以z-index排序因果 |
四 驗收與平台限制
驗收以鍵盤優先：從輸入欄位觸發dialog，確認焦點進入、Tab循環、Escape規則、可見關閉按鈕與關閉後焦點返回；同時注入警報，確認摘要仍可見；模態中的使用者若需獲知新警報，於對話框內提供同步且可讀的狀態摘要、主畫面控制不被視覺遮罩誤導。再測小螢幕、放大字體、觸控與多個警報連續到達。
如果產品使用ARIA，只有在程式真的讓背景不可互動且視覺上被遮蔽時才使用aria-modal=true；背景摘要即使視覺保留，仍不得讓鍵盤焦點跑出dialog。非模態警報不能標成alertdialog；alertdialog需要標題與說明關聯，且按鍵要能完成或取消流程。不同HMI未必支援WAI-ARIA，需依其元件能力做等效鍵盤與焦點測試，不能只貼屬性名稱。
無限增加z-index只能改變繪製順序，不能修正焦點、鍵盤、螢幕閱讀器或安全責任。關鍵區域應保留最小可見摘要和清楚狀態；如果模態遮住它，提供固定摘要、縮小dialog或延後非關鍵提示。安全警報仍由獨立的安全系統、聯鎖和驗證程序負責。
完成標準是使用者能知道哪個警報仍存在、哪個訊息需要回應、目前焦點在哪裡，以及關閉後如何回到工作。所有事件和確認結果要可查，不用畫面是否彈出來推論控制動作是否執行。
驗收也要模擬讀屏與放大字體，確認標題、說明和按鈕名稱能被理解。若只在正常尺寸滑鼠操作通過，仍不能證明鍵盤焦點和輔助技術可用。
五 FAQ與官方來源
FAQ1：最高z-index能保證關鍵警報一定被看到嗎？答：不能；還要設計固定可見區、焦點、聲音、歷史與使用者流程。
FAQ2：非模態警報可以搶鍵盤焦點嗎？答：一般不應搶焦點；讓使用者主動進入警報區查看。
FAQ3：所有錯誤都應開alertdialog嗎？答：不應。只有需要中斷工作並取得回應的訊息才適合模態確認。
FAQ4：alertdialog確認可以順便停機或Reset嗎？答：不能把UI確認冒充安全控制；控制動作需獨立契約、權限與驗證。
參考：W3C WAI-ARIA APG Alert Pattern，說明不打斷工作流程的alert與焦點原則。
參考：W3C WAI-ARIA APG Dialog與Alert Dialog Pattern，說明模態焦點循環、關閉與aria-modal條件。