オーバーレイとダイアログシステム
目的
オーバーレイとダイアログシステムスキルは、プライマリインターフェースの上に配置される一時的なコンテンツレイヤーを管理するための方法論を提供します。割り込みがユーザーのタスクに比例し、可能な限りコンテキストが保持され、モーダル、ドロワー、またはポップオーバーを使用する際にインターフェースがアクセシブルでレスポンシブであることを保証します。
使用例
- 破壊的なアクションに対する確認フローの設計(モーダル)
- ページコンテキストを失わずに複雑な詳細を編集するためのセカンダリワークスペースの作成(ドロワー)
- 特定のUI要素に対するコンテキストヘルプやツールチップの実装(ポップオーバー)
- フィルターや検索のためのモバイル専用ディスカバリーレイヤーの設計(ドロワー)
使用すべきでない場合
- プライマリナビゲーション: メインサイト構造にオーバーレイを使用しないでください。代わりに
site-navigation-systemを使用してください。 - 永続的なコンテンツ: 情報がユーザーにとって常に重要である場合、それはオーバーレイではなくベースページレイアウトの一部であるべきです。
- 複雑な複数ページフロー: タスクに2〜3ステップ以上必要な場合は、ユーザーの混乱を防ぐためにモーダルではなく専用ページを検討してください。
- トースト/スナックバー通知: 「保存しました」「クリップボードにコピーしました」などの受動的でブロックしないステータスフィードバックには、代わりに
toast-and-snackbar-systemを使用してください。このシステムは、そのレイヤーの配置、スタッキング、表示時間、アクセシビリティを詳細にカバーします。
入力
- コンテンツ量: 表示する必要がある情報量はどれくらいですか?
- 割り込みレベル: ユーザーは続行する前にこのタスクを 必ず 完了する必要がありますか、それとも任意ですか?
- トリガーコンテキスト: ユーザーはどこから来ており、何が起こると予想していますか?
- プラットフォーム/ビューポート: モバイル、デスクトップ、またはレスポンシブハイブリッドのどれですか?
出力
- パターン選択: 割り込みマトリックスに基づいた、モーダル、ドロワー、ポップオーバーの明確な選択。
- アナトミー仕様: 定義された領域(ヘッダー、コンテンツ、フッター/アクション)とその内部階層。
- 動作仕様: バックドロップ動作、クローズトリガー、レスポンシブ適応のルール。
- アクセシビリティ要件: フォーカス管理とARIAロールの定義。
ワークフロー
1. 割り込みレベルによる分類
オーバーレイに必要な「重大度」を決定します。
- レベル1(高):モーダル。 背景を無効化します。重要な決定や集中を要するタスクに使用します。
- レベル2(中):ドロワー。 端からスライドインします。親コンテキストを参照できると便利な複雑なサブタスクに使用します。
- レベル3(低):ポップオーバー。 特定の要素にアンカーします。コンテキスト設定や情報に使用します。
受動的でブロックしないステータスフィードバック(レベル4)については、toast-and-snackbar-system を参照してください。ここでは範囲外です。
2. 内部階層の定義(アナトミー)
visual-hierarchy-system をオーバーレイに適用します。
- ヘッダー: 明確なタイトルと一貫した「閉じる」メカニズム(Xボタン)。
- ボディ: プライマリコンテンツエリア。コンテンツが長い場合は、スクロール動作(固定ヘッダー/フッター)を定義します。
- フッター: プライマリアクションとセカンダリアクションを一貫して配置します(通常、デスクトップでは右揃え、モバイルでは全幅)。
3. エレベーションとバックドロップの確立
- Zインデックス戦略: オーバーレイが正しいスタッキングコンテキストに配置されるようにします。モーダルにはネイティブの
<dialog>要素を推奨します。この要素は自身のトップレイヤースタッキングを管理し、スクリム用の::backdrop疑似要素を提供し、Escapeキーによるクローズをネイティブに処理します。 - バックドロップ(スクリム): モーダルとドロワーで背景を暗くし、注意を集中させるために使用します。バックドロップをクリックしたときにオーバーレイを閉じるかどうかを定義します。
<dialog>を使用する場合は、手動でレンダリングするオーバーレイ<div>の代わりに::backdropを介してスクリムをスタイリングします。 - 背景の不活性化: オーバーレイが開いているときは、ページの残りの部分は操作不可能で、支援技術から隠されていなければなりません。
<dialog>.showModal()はこれを自動的に行います。カスタム(<dialog>以外の)オーバーレイの場合は、aria-hiddenだけに頼るのではなく、背景コンテンツにinert属性を適用します。 - シャドウ: 奥行きを使用して、ベースレイヤーの上のオーバーレイの位置を示します。
4. レスポンシブ適応の設計
オーバーレイは画面サイズに基づいて変換される必要があります。
- デスクトップのポップオーバー → モバイルのドロワー: 小さなコンテキストメニューは、モバイルでは親指のリーチを良くするために下部に沿ったドロワーになることがよくあります。
- デスクトップのモーダル → モバイルのフルスクリーン: 大きなモーダルは、小画面のスペースを最大限に活用するために、小さな画面ではビューポート全体を占有する必要があります。
- ドロワーの動作: モバイルでは、ドロワーがビューポート幅の90%を超えないようにします。
5. 閉じる&終了パターンの定義
- 非クリティカルなオーバーレイを終了するための少なくとも3つの方法を提供します:「閉じる」ボタン、
Escapeキー、バックドロップのクリック。 - クリティカルな(警告)モーダルの場合は、明示的なアクション(例:「キャンセル」または「確認」)を要求します。
決定ルール
- 「モーダル vs. ドロワー」ルール: ユーザーが作業中に背景コンテンツを参照する必要がある場合は、ドロワー を使用します。タスクが「止めて修正する」瞬間である場合は、モーダル を使用します。
- 「親指」ルール: モバイルでは、アクションを親指の自然なリーチ内に保つために、下部ドロワー を優先します。
- 「2ステップ」ルール: オーバーレイに2つ以上の内部「ビュー」またはステップが必要な場合、それはおそらく独自のページに属します。
- バックドロップロジック: 「外側をクリックして閉じる」は、非破壊的なオーバーレイにのみ許可します。データが失われる可能性があるフォームでは決して許可しないでください。
制約
- アクセシビリティ: キーボードでナビゲート可能である必要があります。モーダルはフォーカスをトラップする必要があります(ネイティブの
<dialog>要素はshowModal()で開いた場合にデフォルトでこれを行います)。背景コンテンツはinert(または同等)にし、スクリーンリーダーとキーボードフォーカスがそこに逃げないようにする必要があります。ネイティブ要素を使用しない場合は、role="dialog"またはrole="alertdialog"とaria-modal="true"、およびタイトルを指すaria-labelledbyを使用します。 - レスポンシブ性: オーバーレイは水平スクロールを引き起こしてはなりません。内部のコンテンツはレスポンシブである必要があります。
- 階層: オーバーレイのH1/タイトルは、コンテナ内で最も目立つ要素である必要があります。
よくある失敗パターン
- オーバーレイスープ: 複数のモーダルを互いの上にスタックすること。
- コンテキストロス: ユーザーがタスクを完了するために必要な情報を覆い隠すモーダルを使用すること。
- 「見えない閉じる」: 閉じるボタンを隠したり、タッチ用に小さすぎる(最小44x44px)にすること。
- スクロールの競合: オーバーレイが開いているときにバックグラウンドページをスクロール可能にすること(混乱を招く)。
- 一貫性のないアクション: 異なるオーバーレイ間で「キャンセル」と「確認」ボタンの位置を変えること。
検証基準
- 選択されたパターン(モーダル/ドロワー/ポップオーバー)がタスクの割り込みレベルと一致している。
- 内部階層が明確で、明確なタイトルとプライマリアクションがある。
- モバイル向けのレスポンシブ適応(例:ポップオーバーからドロワー)が定義されている。
- 「外側をクリックして閉じる」ロジックがデータリスクに対して適切である。
- フォーカス管理とキーボードアクセシビリティ要件が指定されている。
- エレベーション(シャドウ/バックドロップ)がベースページからレイヤーを区別している。
- モーダルまたはドロワーが開いているときは常に、背景コンテンツが
inert(またはネイティブの<dialog>要素が使用)にされる。