はじめに
メニューバーを作成するときは、見た目だけでなく、リンクの意味、キーボード操作、スマートフォンでの折り返しまで同時に考える必要があります。そのため、単に横並びの文字列を置くのではなく、nav、ul、li、aを組み合わせ、構造と装飾を分けて設計する流れが扱いやすくなります。
これから作成するメニューバーの結論は、navで領域を示し、display:flexで項目を並べ、:hoverと:focus-visibleで操作中の状態を見せる構成です。ただし、ドロップダウンや固定表示を加える場合は、positionやz-indexの影響を受けるため、先に土台を整えるほうが崩れにくくなるのが基本です。
- HTML Living Standard
- CSS Snapshot 2024
- Google Chrome 126 / Mozilla Firefox 127 / Safari 17
- メニューバー作成に必要な基本構造
- 横並び、余白、配色を整えるCSSの考え方
- スマートフォン表示で崩れにくい設計
- ドロップダウンと固定表示を加える判断基準
- アクセシビリティと内部リンク設計の確認方法
完成形から逆算してメニューバーを作成する
結論として、標準的なメニューバーは「領域」「リスト」「リンク」「状態表示」の組み合わせで作成します。この構成にしておくと、ページ内移動、カテゴリ一覧、問い合わせ導線などを同じルールで増やせます。
その考え方は、公式仕様の役割分担とも相性がよい形です。要素の意味はWHATWGのnav要素で確認でき、リンクの基本仕様はMDNのa要素が参考になるのが目安です。
結果: 期待される表示は、3件のリンクが横方向に並び、マウス操作やキーボード操作で背景色と輪郭が変わるメニューバーです。
この最小構成では、aria-labelでナビゲーションの目的を補い、list-style:noneで箇条書き記号を外し、gapで項目間の距離を決めています。ただし、リンク先の数が増えると横幅が足りなくなるため、画面幅に応じた折り返しや縦配置も検討します。
メニューバー作成の早見表
メニューバーの作成では、要素選び、CSS、操作状態、レスポンシブ対応を分けて確認すると抜け漏れが減りますし、ここがポイントです。そのため、作業前に次の早見表で役割を整理しておくと、後からデザインを変える場合も判断しやすくなります。
| 項目 | 使う要素・プロパティ | 役割 | 確認する点 | 関連する注意 |
|---|---|---|---|---|
| 領域 | nav | 主要な移動領域を示す | 他のリンク群と区別できるか | aria-labelを併用する |
| リスト | ul | リンクのまとまりを表す | 項目の順序が自然か | 見た目だけで構造を消さない |
| 項目 | li | 各リンクを分離する | 余白が均等か | 入れ子が深すぎないか |
| リンク | a | 遷移先を持たせる | hrefが正しいか | 空リンクを避ける |
| 横並び | display:flex | 項目を行方向に配置する | 狭い幅で崩れないか | flex-wrapを検討する |
| 間隔 | gap | 項目間の距離を整える | クリックしやすいか | 余白の重複を避ける |
| 内側余白 | padding | 押しやすい面積を作る | 指で触れやすいか | 文字だけを狭くしない |
| 外側余白 | margin | 周辺要素との距離を保つ | 見出しと近すぎないか | 親要素との関係を見る |
| 背景 | background | 領域や状態を見せる | 文字色と差があるか | 薄すぎる色を避ける |
| 文字色 | color | リンク文字を読みやすくする | 背景と対比できるか | 訪問済み色も考える |
| 下線 | text-decoration | リンクらしさを調整する | リンクと分かるか | 状態表示で補う |
| 輪郭 | outline | キーボード操作を示す | 消していないか | focus-visibleを使う |
| ホバー | :hover | マウス操作の反応を出す | 変化が分かるか | 色だけに依存しない |
| フォーカス | :focus-visible | キーボード位置を示す | 十分に目立つか | outline-offsetも使える |
| 現在地 | aria-current | 表示中ページを伝える | 現在地が一目で分かるか | 複数付けない |
| 固定表示 | position:sticky | スクロール中に残す | 本文を隠さないか | topを合わせる |
| 重なり | z-index | 前面表示を制御する | ドロップダウンが隠れないか | 乱用を避ける |
| 幅 | max-width | 広い画面で読み幅を保つ | 中央寄せできるか | margin:autoと組む |
| 折り返し | flex-wrap | 狭い幅で行を増やす | 項目が重ならないか | 高さの増加を見る |
| 縦配置 | flex-direction | 小画面で縦に並べる | タップしやすいか | メディアクエリと組む |
| 分岐 | @media | 画面幅でCSSを切り替える | 境界幅で崩れないか | 実際の端末幅を想定する |
| 開閉 | button | メニューを開閉する | 操作対象が分かるか | aria-expandedを更新する |
| 状態 | hidden | 非表示状態を表す | 読み上げ対象から外れるか | CSSだけの非表示と区別する |
| 装飾 | border | 区切り線を加える | 濃すぎないか | 背景色と合わせる |
| 角丸 | border-radius | ボタン風の形にする | デザインに合うか | 過度に丸めない |
| 影 | box-shadow | 浮き上がりを表す | 文字を邪魔しないか | 固定表示で控えめにする |
| 速度 | transition | 状態変化を滑らかにする | 遅すぎないか | 操作反応を妨げない |
| ドロップダウン | position:absolute | 子メニューを重ねる | 親項目から外れないか | キーボード操作を確認する |
| 表示制御 | visibility | 見え方を切り替える | フォーカス移動と合うか | opacityとの違いを見る |
| サイズ | font-size | 文字の大きさを整える | 小さすぎないか | ズーム時も読む |
構造はnavとリストで組み立てる
メニューバーの土台では、divだけでリンクを並べるより、navとリストを使う形が自然です。その構造にすると、支援技術や検索エンジンに対して、ページ移動の領域であることを伝えやすくなります。
これにより、内部リンクの設計も整理しやすくなります。たとえばページ内の特定位置へ移動する導線はHTMLでアンカーリンクを活用する方法10選、フォームへの導線はHTMLで問い合わせフォームを作成する方法5選!と結び付けると、読者の移動目的が明確になるのがポイントです。
結果: 期待される表示は、サイト内メニューという名前を持つナビゲーション領域の中に、構造、カレンダー、表示演出のリンクが並ぶ形です。
このとき、class名は見た目ではなく役割に合わせて付けると保守しやすくなります。ただし、menu1やred-linkのように用途が読み取りにくい名前は、後から項目を追加したときに意味がずれやすいので避けます。
💡 Tips:aria-labelは、同じページに複数のnavがあるときに役割を区別する助けになるのが一般的です。主要メニュー、パンくず、フッターリンクなど、同じ要素でも目的が違う場合に使い分けます。
横並びの見た目はflexで整える
構造が決まったら、メニューバーの見た目をCSSで整えます。その中心になるのがdisplay:flexで、リスト項目を横方向に並べながら、gapで距離を管理できるのが現実的です。
一方、古い作り方としてfloatで横並びにする例も残っていますが、現在の作成ではflexやgridのほうが配置の意図を読み取りやすいです。公式ドキュメントでも、CSS Flexible Box Layoutとして柔軟な一次元レイアウトが整理されています。
結果: 期待される表示は、白い背景の下に薄い境界線が入り、中央寄せされたリンクが一定間隔で横並びになるメニューバーです。
これらの指定では、align-items:centerで縦方向の位置がそろい、justify-content:centerで全体が中央に寄ります。ただし、項目数が多いサイトでは中央寄せより左寄せのほうが探しやすい場合もあるため、情報量に合わせて調整します。
具体的には、メニューの数が少ないブランドサイトなら中央寄せ、カテゴリが多いメディアなら左寄せ、管理画面に近いUIなら余白を抑えた配置が向いていると整理できます。その判断を誤ると、作成したメニューバーが見た目だけ整っていても、目的のリンクを探しにくくなります。
操作中の状態を見える形にする
メニューバーは読むだけの部品ではなく、クリック、タップ、キーボード操作を受ける部品です。そのため、:hoverだけでなく:focusや:focus-visibleも合わせて設計する必要があります。
これを省くと、マウスでは問題なく見えても、キーボード操作中に現在位置が分かりにくくなると理解できます。特に押さえたいのは、outline:noneで輪郭を消したまま代替表現を用意しない書き方を避けることです。
結果: 期待される表示は、ホバー時に薄い緑系の背景へ変わり、キーボードフォーカス時にはリンクの外側に輪郭が出る状態です。
このとき、現在表示しているページのリンクにはaria-current="page"を付けると、見た目と意味をそろえられます。ただし、複数のリンクに同じ現在地を示す属性を付けると混乱するため、ページ単位でひとつに絞ります。
スマートフォン向けに折り返しと縦配置を用意する
横並びのメニューバーは、画面幅が狭くなると文字が詰まりやすくなります。そのため、作成時点でflex-wrapによる折り返し、または@mediaによる縦配置を決めておくと安定すると考えられます。
一般に、項目数が少ない場合は折り返しで十分ですが、項目数が多い場合は開閉式メニューが向いています。ただし、開閉式にするとbutton、aria-expanded、hiddenなどの状態管理が増えるため、必要以上に複雑にしない判断も求められます。
結果: 期待される表示は、広い画面では横並び、640px以下の画面ではリンクが縦に積み重なるメニューバーです。
これにより、横幅が足りない状態でもリンク同士が重なりにくくなります。一方、縦配置にした分だけ高さは増えるため、ページ冒頭の見出しや本文を押し下げすぎない余白設計が必要になります。
同様に、スライドショーやカレンダーのような横幅を使う部品が近くにあるページでは、メニューの高さが画面全体の見え方に影響すると言えるでしょう。関連するUIを扱う場合は、HTMLとCSSで手軽に作るスライドショーコピペ12選やHTMLとJSを使ってカレンダーを作成・更新する方法10選のような部品との並びも意識します。
ドロップダウンを加えるときの考え方
カテゴリ数が多いサイトでは、メニューバーにドロップダウンを加えたくなる場面があります。その場合でも、親リンクと子リンクの関係をulの入れ子で表し、CSSだけで見た目を無理に作り込まないほうが管理しやすくなるのが基本です。
ただし、ドロップダウンは操作方法が増えるため、初心者がつまずきやすい箇所でもあります。マウスを外した瞬間に消える、キーボードで子項目へ移れない、スマートフォンでタップできないといった問題が起きやすいからです。
結果: 期待される表示は、学習ガイドの下にアンカーとフォームの子メニューを持つ階層型メニューバーです。
結果: 期待される表示は、親項目にマウスを重ねるか子リンクへフォーカスしたときに、白い子メニューが下方向へ表示される状態です。
この作り方では、:focus-withinを含めることで、キーボード操作でも子メニューを開きやすくなります。もっとも、スマートフォンではホバーが前提にならないため、必要に応じてJavaScriptで開閉状態を切り替える設計が現実的です。
固定表示にする場合の注意点
スクロール中もメニューバーを残したい場合は、position:stickyを使うと比較的少ないCSSで固定に近い表示を作れます。その表示はページ移動の負担を下げますが、本文の上に重なると読みにくさにつながります。
このとき、top、z-index、背景色を合わせて設定するのがポイントです。ただし、管理バーや広告枠など、上部に別の固定要素があるサイトでは、top:0のままだと重なる可能性があります。
結果: 期待される表示は、スクロールしても画面上部に残り、本文より前面に表示されるメニューバーです。
逆に、短いページやランディングページでは、固定表示が読者の視界を狭める場合があります。そのため、固定にするかどうかはデザイン上の好みではなく、移動頻度と画面占有率のバランスで決めますが、これは押さえたい点です。
内部リンクとラベルを整理する
メニューバーの作成では、リンクの見た目より先にラベルの分かりやすさを整える必要があります。その理由は、読者がクリック前に遷移先を判断する材料が、短いラベルと並び順に集中するためです。
具体的には、「詳しく」「こちら」のような曖昧なラベルを避け、リンク先の内容が分かる言葉を使います。ツリー構造の考え方を整理したい場合は、HTMLとツリー構造をマスターする!初心者からプロまでわかる7つの完全ガイドのように、階層とラベルの関係を確認すると理解しやすくなるのが一般的です。
そのうえで、主要カテゴリ、よく読まれるページ、問い合わせ、資料請求などを同じ階層に置きすぎないようにします。一方、運営上どうしても項目が増える場合は、グループ分けやドロップダウンを使い、読者が目的を追いやすい形にします。
💡 Tips: メニューバーのリンクは、ページのすべてを載せる場所ではありません。主要な移動先を絞り、補助的なリンクはフッターやカテゴリページへ回すと、上部の導線が読み取りやすくなるのが現実的です。
作成後に確認したい品質チェック
作成したメニューバーは、見た目が整った段階で終わらせず、操作と意味の両面から確認します。その確認では、リンク切れ、フォーカス表示、スマートフォン幅、現在地表示、外部リンク属性を順に見ると抜けを減らせます。
これらは、公開後の使いやすさに直結すると整理できます。たとえば、target="_blank"を使う外部リンクにはrel="noopener noreferrer"を添え、同一サイト内のリンクでは不要な新規タブを避ける形が一般的です。
ただし、外部リンクと内部リンクの扱いを混ぜると、編集時の判断が曖昧になります。そのため、本文中の公式ドキュメントは新規タブ、サイト内の関連記事は通常遷移というように、作成ルールをそろえておくと運用しやすくなります。
結果: 期待される表示は、外部ドキュメントへのリンクが新しいタブで開き、内部記事へのリンクは同じタブで移動する構成です。
一般に、メニューバーは複数ページで共通利用されるため、小さな不具合がサイト全体へ広がりますし、これが一つの目安です。そのため、テンプレート化する前に、表示幅を変えながらリンクの折り返し、開閉、フォーカス移動を確認します。
実装パターン別の使い分け
メニューバーの作成方法は、サイトの規模によって変わります。小規模なページなら静的な横並びで十分な場合が多く、中規模以上ならレスポンシブ対応やドロップダウン、管理しやすいテンプレート化が必要になると理解できます。
一方、すべての機能を最初から入れると、CSSの依存関係が増えて調整が難しくなります。基本的には、静的な構造、状態表示、スマートフォン対応、必要な場合だけ開閉制御という順序で広げると扱いやすくなります。
| パターン | 向いている場面 | 主な構成 | 気を付ける点 |
|---|---|---|---|
| 横並び固定 | 項目数が少ないサイト | navとflex | 狭い幅で詰まらないようにする |
| 折り返し型 | 項目数が中程度のサイト | flex-wrapとgap | 行数が増えたときの高さを見る |
| 縦配置型 | スマートフォンを重視するサイト | @mediaとflex-direction | リンク面積を十分に取る |
| ドロップダウン型 | カテゴリ階層があるサイト | position:absoluteと:focus-within | キーボード操作を妨げない |
| 固定表示型 | 長いページが多いサイト | position:stickyとz-index | 本文や上部要素と重ねない |
この比較から分かるように、正解はひとつではありません。作成するサイトのページ数、項目数、読者の移動頻度をもとに、最小限の構成から広げる考え方が安定します。
公開前の仕上げ
メニューバーの仕上げでは、構造、装飾、操作、リンク先を同時に確認します。その確認を後回しにすると、見た目だけ完成していても、現在地が分からない、スマートフォンで押しにくい、内部リンクの意図が弱いといった問題が残りやすくなると覚えるとよいでしょう。
そのため、navの役割、aria-labelの有無、hrefの正しさ、:focus-visibleの見え方、@mediaの切り替わりを順に確認します。これらを押さえると、メニューバー作成の品質が見た目だけに偏らず、読者の移動を支える部品として成立します。
とはいえ、最初から複雑な開閉や多階層メニューを作る必要はありません。静的な横並びで目的が足りるなら、その構成を保ち、必要になった段階でドロップダウンや固定表示を加えるほうが保守しやすくなると考えられます。
関連記事
- 『HTMLでアンカーリンクを活用する方法10選
- HTMLとJSを使ってカレンダーを作成・更新する方法10選
- HTMLとCSSで手軽に作るスライドショーコピペ12選
- HTMLとツリー構造をマスターする!初心者からプロまでわかる7つの完全ガイド
- HTMLで問い合わせフォームを作成する方法5選!
※本記事は実在のエンジニア複数名で構成される Japanシーモア編集部が、AI支援を活用して作成・校正・公開しています。


