小さなウィンドウでも、作業の流れを大きく変えてしまうことがあります。ここでは架空の場面を考えてみます。ある人がプロジェクトの相談文を書いている途中で、依頼内容のまとめ方について短い説明を開きました。疑問が解けて元の画面に戻ると、書きかけの文章が消えていた。説明そのものが親切でも、この体験では安心して続きを書けません。ダイアログの設計で大切なのは、開いた瞬間だけでなく、用事を終えて元の作業へ戻るまでです。
まず、その情報にモーダルは必要か
配置やアニメーションを考える前に、いったん作業を止める理由があるかを確かめます。たとえば配送日数やサイズの説明なら、選択肢のすぐそばに置いたほうが判断しやすいことがあります。補足が長ければ、その場で展開できる形も候補です。選ぼうとしているものと説明を同時に見られれば、内容を覚えてから画面を行き来する負担を減らせます。
モーダルが向いているのは、先へ進む前に一つの限定された判断へ注意を向ける必要がある場面です。ページを短く見せたいという都合だけでは、十分な理由になりません。じっくり読む資料なら、独立したページのほうが落ち着いて扱えるでしょう。今回の相談フォームでも、短い説明を入力欄の横に置くだけで目的を果たせるかもしれません。
判断の目安は、その説明を読む間に元の内容を見比べる必要があるかどうかです。見比べたい内容を背景へ隠すと、確認のために何度も開閉することになります。情報の量だけでなく、読む人が何と照らし合わせるのかまで考えると、置き場所を選びやすくなります。
何をする場所か、どう戻れるかを明確に
見出しは、そのウィンドウを開いた理由に答える言葉にします。「お知らせ」より「相談内容をまとめるときのヒント」のほうが、読む目的をつかみやすくなります。ボタンも、押した後に起こることを表す必要があります。「相談を送信」と「説明を閉じる」は別の行動です。閉じる手段は、長い本文を最後まで読まなくても見つけられる位置に置きます。
MDNによれば、showModal()は背景を操作不能にし、show()やopenは非モーダルです。WAI-ARIAのダイアログパターンでは、フォーカスをモーダル内に保ち、Tabで循環させ、Escapeで閉じ、通常は開いた要素へ戻します。アクセシブルな名前を付けます。見える閉じるボタンも推奨されています。
操作できることに加えて、今どこを操作しているかが見えることも大切です。順番に移動できても、現在位置がわからなければ次の行動に迷います。この点は、キーボード操作と見えるフォーカスでも取り上げています。見た目を整える段階で、こうした手がかりを薄くしてしまわないようにしたいところです。
書きかけの文章を、すでに使った時間として扱う
入力途中の文章には、利用者が考え、言葉を選んだ時間が含まれています。架空の相談フォームなら、説明を開く、閉じる、もう一度開くという動きで、その文章が失われないことが基本になります。ウィンドウの外側にうっかり触れただけで消えてしまう設計も避けたいものです。補足を読むために、文章を別の場所へコピーしておく必要があっては本末転倒です。
そのためには、「閉じる」「キャンセルする」「内容を破棄する」を実装前に分けて考えます。単に説明を閉じることと、入力をやめて内容を捨てることは同じではありません。失われる内容があるなら、その結果を実行前にわかる言葉で伝えます。一方、何も失われない操作で毎回確認を出すと、必要な警告まで読み飛ばされかねません。実際の損失に合わせて保護を設計します。
説明を閉じても文章が残ることと、ページを再読み込みしても残ることは別です。どこまで保持するかを決め、必要な場面ではその範囲を伝えます。画面に「保存済み」と出すなら、何が保存されたのかも曖昧にしません。安心させる表示と実際の動作が一致しているかを確認します。
スマートフォンでは、キーボードが出た後を見る
広い画面で整っているだけでは、十分に確認したことにはなりません。スマートフォンでは入力用のキーボードが現れると、読める範囲も操作できる範囲も変わります。閉じるボタンが見えなくならないか、入力中の場所が隠れないかを確かめます。指で動かしたときに説明がスクロールするのか、その後ろのページが動くのかも、体験のわかりやすさに関わります。
確認には、短い仮の文章ではなく、少し長めの相談文や画面の高さを超える説明を使います。文字を大きくした状態でも試します。困ったときに操作を続けられる余地があるか、戻る手段が届く場所にあるかを見るためです。問題を細かな例外処理で隠す前に、文章を整理する、補足を別の場所へ移す、といった構成の見直しも考えられます。
見出し、本文、ボタンを一画面に詰めることだけを目標にすると、読むための余白がなくなります。すべてを常に表示する必要はありませんが、今の内容を読み進める方法と、作業へ戻る方法は、競い合わないように整理しておきます。
開閉ではなく、一つの用事を最後まで試す
テストは、ダイアログを開く直前からではなく、相談を書き始めるところから行います。数文入力し、説明を開き、内容を読み、閉じて、文章を続ける。その後、キーボードだけで同じ流れをたどり、スマートフォンでも試します。閉じた後に入力が残っているか。続きに戻る場所を探し直していないか。操作単体では見えなかったつまずきが、流れの中で見つかります。
最後は、必須項目の入力漏れを直して再度送信を試みる場面まで含めます。入力エラーを修正の助けにする設計と同じように、ダイアログもそれまでの作業を支える存在であるべきです。説明を読んだ後に、余計な記憶ややり直しを要求しないこと。迷わず続きを始められること。その小さな連続性が、安心して使える画面につながります。