折り畳まれたナビゲーションメニューの展開 (オーバーレイではなくインレイで)

• 公開日 : 2021年4月17日 (2021年6月6日 更新)
• カテゴリー : ユーザビリティ / アクセシビリティ

ナビゲーションメニューがデフォルトでは折り畳まれていて、いわゆる「ハンバーガーアイコン」を押すとメニューを展開表示するインタラクションを備えたウェブサイトを、昨今よく目にします。もともとはスマートフォンのように画面の大きさが限られたデバイス向けの UI でしたが、多くのウェブユーザーにとって馴染みのある UI になってきたからでしょうか、PC 向けのウェブサイトにおいても、採用される例が増えてきたように思います。そしてこれらは、ほとんどがオーバーレイ (overlay : ページの上に重ねる形での情報提示) でメニューを展開表示する仕様になっています。

オーバーレイの問題

オーバーレイでメニューを展開するインタラクションは、一見、問題なさそうに見えるかもしれませんが、以下の問題があります。

ひとつは、メニューの提示とその利用が、モーダルになってしまうことです。メニューを選ぶためには、まずメニューを展開するという特別なモードに入ることが求められます。このモードは、メニュー項目を選択するか、展開したメニューを任意で閉じない限り、抜け出してコンテンツの他の部分を見たり操作したりすることができません。

もうひとつは、アクセシビリティの問題です。よくあるのが、キーボード操作やスクリーンリーダー利用時の予期せぬ挙動です。たとえば、メニューが展開された状態で何度か [Tab] キーを押すと、(メニューがオーバーレイして背景側の元ページを覆い隠しているにもかかわらず) フォーカスが背景側に移動してしまったり、また、スクリーンリーダーでも、メニューをひととおり読み上げた後に (覆い隠されているはずの) 背景側を読み上げてしまったり、といった具合です。実装によって解決することはできますが (†)、案外、こうしたアクセシビリティを意識した実装が抜け落ちてしまっているケースが少なくありません。

オーバーレイではなくインレイで展開する

そもそも、折り畳まれて展開するメニューは、オーバーレイ (モーダル) である必然性はあるのでしょうか？たとえば、インレイ (inlay : ページ内の一部に挿し込む形での情報提示) で展開する、というのはどうでしょうか？

インレイでメニューを展開するインタラクションには、オーバーレイに対して、以下のメリットがあります。

ひとつは、メニューを展開した状態でも、コンテンツの他の部分 (メインとなるコンテンツ本文など) が覆い隠されないことです。つまり、展開されたメニューとメインコンテンツは併存する関係となり、互いの間をモードレスに行き来することができます。この操作感は、スマートフォンが登場する (いわゆる「ハンバーガーアイコン」によるメニューの折り畳みが考案される) 以前からの UI の慣習とも合致しています。

もうひとつは、アクセシビリティの観点で、オーバーレイで展開する際に生じていた、キーボード操作やスクリーンリーダー利用時の予期せぬ挙動が解消されることです。メニューが展開されている状態で何度か [Tab] キーを押す、あるいはスクリーンリーダーでメニューを読み進めると、その流れでフォーカスや読み上げ対象がメニューの外側、つまりメインコンテンツに移るわけですが、メインコンテンツはメニューによって覆い隠されているわけではないので、特に不自然さはありません。実装上のハック (フォーカス移動を制御するためのスクリプトなど) も不要です。

もうひとつ付け加えると、オーバーレイでメニューを展開する場合、それがオーバーレイであるとユーザーが瞬時に認知できるように視覚表現する必要がある、という制約もあります。たとえば、一瞥できるビューポート (above the fold) において、背景となる元ページの存在が視認できるように、メニュー表示領域の上下左右にはいくらかのマージンがあることが望ましく、その中にすべてのメニュー項目が収まることが求められるでしょう。メニューを閉じるためのクローズ (×) ボタンも、オーバーレイ領域の中で見つけやすいように配置しなければなりません。

インレイでメニューを展開するのあれば、そういった視覚的な制約がありません。必ずしもビューポート内にメニューが収まらず縦スクロールが発生しても破綻はしないので、サブメニューの追加的な展開を盛り込むこともできます。これは、特に大規模サイトでは大きなメリットになります。

以上のように考えると、基本的には、ナビゲーションメニューを展開表示する際は、オーバーレイではなくインレイのインタラクションを採用するほうが無難だと言えるでしょう。