削除の確認画面では、何が消えるか、誰に影響するか、元に戻せるかを伝えます。「本当によろしいですか？」に答えるだけでは、利用者は操作の結果を確かめられません。
一覧や管理画面を設計する人に向けて、公開デザインシステムの指針と、共有フォルダーの作例をまとめます。作例は架空で、誤操作の削減効果を測定した事例ではありません。
確認を挟む前に、戻せるかを決める
GOV.UK Design Systemは、利用者が簡単に取り消せない重大な操作に警告ボタンを使い、実行前の確認を挟むことを勧めています。赤色だけに頼らず、文脈とボタン名で結果を伝える指針です。Button：Warning buttons
まず、自分のサービスで「削除」が何をするのかを確かめます。次の表は設計を考えるための整理です。
| 操作の性質 | 先に決めること | 画面で伝えること |
|---|---|---|
| 一覧から外すだけ | 元データはどこに残るか | 「一覧から外す」など実際の操作名 |
| ごみ箱から戻せる | 誰が、いつまで、どこから復元できるか | 復元方法と期限 |
| 元に戻せない | 消える対象と他の利用者への影響 | 実行前の確認と、取り消せないこと |
確認画面をすべての操作に増やせばよいわけではありません。Carbonも、モーダルは作業を中断させるため、頻繁に必要な操作なら元の画面で完結する方法を検討するよう案内しています。Modal：Overview
「戻せます」と書けるのは、復元の仕組みがある場合です。短時間だけ出る通知を逃したら戻せないのか、ごみ箱から後で戻せるのかも、先に確認します。
「はい・いいえ」を、対象と操作に置き換える
共有フォルダーを完全に削除する作例です。この例では、中のファイルも消え、利用者自身では復元できない仕様とします。
対象が分からない例
本当によろしいですか？
［いいえ］ ［はい］
対象と影響を示す例
共有フォルダー「採用資料」を削除しますか？
中のファイル12件も削除されます。共有メンバー全員が開けなくなり、この操作は取り消せません。
［キャンセル］ ［フォルダーを削除］
この作例なら、選んだフォルダーを間違えていないか、ファイルも含む操作かを確認できます。件数や共有範囲は、その時点で確認できた情報を表示します。確認中に内容が変わるサービスでは、実行時に対象を再確認する処理も必要です。
Carbonは、確認する操作と影響を説明し、見出しとボタンにも実行する操作を反映させるよう勧めています。Modal：Confirm a user decision
複数選択なら、件数だけで足りるかも検討します。名前が同じ対象や別の部署の資料を含むなら、選択内容を確認できる一覧が必要になることがあります。情報量が多ければ、狭いダイアログへ詰め込まず確認専用のページにする案もあります。
削除確認を試す
このページ内の作例です。実際のファイルには影響しません。
共有フォルダー
確認画面でキャンセルして、戻る動きを試せます。
キーボードでも、実行せずに戻れるようにする
見た目の確認に加え、フォーカス（キーボード操作の対象）がどこへ移るかを決めます。W3CのAPGは、モーダル内へのフォーカス移動、Tab移動を内部に保つこと、Escapeで閉じること、閉じた後の戻り先を説明しています。Dialog (Modal) Pattern
この短い削除確認の作例では、次の動きを設計案にします。
- 開いたときは「キャンセル」にフォーカスを置く。
- TabとShift＋Tabで操作しても、背後の一覧へフォーカスが抜けない。
- キャンセルとEscapeは、削除を実行せずに閉じる。
- キャンセル後は、確認を開いた操作へフォーカスを戻す。
- 削除成功で元の行がなくなったら、一覧の見出しなど次の作業を続けられる位置へ移す。
最初の位置を常にキャンセルにする決まりではありません。長い説明では見出しに置くなど、内容に合った位置を選びます。APGも、取り消しが難しい操作では影響の小さい選択肢を初期位置にすることを検討しています。
スクリーンリーダーでは、ダイアログの名前として対象を含む見出しが伝わるか、影響の説明と両方の操作を読めるかを確かめます。属性を付けただけで完了とせず、使う部品と実際の操作で確認します。
押した後も、「成功」「失敗」「結果不明」を分ける
以下は、共有フォルダーの作例に追加する処理の仕様案です。確認画面の文言だけでは、通信失敗や二重実行は防げません。
| 状態 | 表示の例 | 処理で確認すること |
|---|---|---|
| 応答待ち | 削除しています | 同じ操作を重ねて送らない |
| 成功を確認 | 「採用資料」を削除しました | 一覧を更新し、次の操作へ進める |
| 削除されていないと確認 | 削除できませんでした | 対象を残し、理由と再試行できるかを示す |
| 応答が途切れ、結果が不明 | 削除結果を確認できませんでした | 現在の状態を取得してから次の操作を決める |
応答が返らないだけで「削除に失敗しました」とは断定できません。成功していたのに同じ要求をもう一度送らないよう、画面だけでなくサーバー側の重複処理も開発者と決めます。
実行後にダイアログを閉じられる設計なら、閉じることと処理の取り消しは区別します。要求を送った後にも「キャンセル」で止められると見せるなら、その取り消し処理が実際に成立する必要があります。
設計レビューに使う確認メモ
次のメモを、自分のサービスの仕様で埋めてください。作例の「復元不可」を、そのまま採用する必要はありません。
削除する対象：
一緒に消えるデータ・影響を受ける人：
復元できる範囲・期限・操作場所：
確認画面の見出し：
実行ボタンの名前：
実行前に中止する操作：
開いた時・閉じた時のフォーカス：
応答待ち・成功・失敗・結果不明の表示：
対象の変更・連打・通信切断時の処理：
レビューでは、対象を間違えて開く、キーボードだけで中止する、実行直後に通信を切る、という操作を試します。利用者が「何が消えるか」を説明できるかも確かめてください。この確認は、サービス全体のアクセシビリティや誤操作防止を保証するものではありません。
動きを仕様に落とすなら受け入れ条件の書き方、削除後に一覧が空になる画面は検索結果が0件のUIも参考にしてください。