記事の目次はどこに置く？スマホ・PCで読みやすいデザインと配置

目次は、記事の全体像と読みたい節への入口を示す

目次には、記事に何が書かれ、どの節へ進めるかを示す役割があります。サイト全体のメニューや、別の記事へ進む関連記事一覧とは分けて設計します。

長い記事を最初から読む人もいれば、すでに知っている説明を飛ばして必要な条件を確かめたい人もいます。目次は、どちらの人にも記事の構成を示し、必要な節への入口を用意するものです。目次の項目だけを増やし、どれを選べばよいか分からなくしないでください。

W3Cの目次を提供する技法G64は、文書の全体像を示すことと、特定の節へ直接進めることを挙げています。これは技法の一例で、すべての記事へ目次を義務化する説明や、目次だけでサイトの適合を認定する説明ではありません。

導入の答えを読んでから、必要な説明を選べるようにする

記事の題と最初の答え、何を扱うかが分かる短い説明の後に、主な節を案内すると、読者は何の目次を見ているかを判断できます。題の直後を長い一覧で埋め、主な問いへの答えをずっと下へ送ることから始めないでください。

短く一続きで読める説明や、節を選ぶ必要がほとんどないページでは、大きな目次を足すより本文自体を整理する方がよい場合もあります。「何文字以上なら必ず付ける」と一律に決めず、読者が探す説明と本文の構成から必要性を考えます。

別の記事で次の疑問を解く道案内は、読者の次の疑問へつなぐ内部リンク設計の範囲です。ここでは、一つの長い記事の中で、どこを読むかを選べるようにします。

読者が探す内容を、分かる見出し名へ対応させる

読者の知りたいことを短く書き、その答えがある節の見出しを目次へ載せます。本文と同じ名前・読む順で案内すると、選んだ項目と移動先を対応させやすくなります。

架空の「研修の準備ガイド」では、初めて社内研修の準備を担当する人が、事前に用意する資料を探しています。本文の主な節は「準備する資料」「当日の流れ」「変更時の連絡」です。この三つは説明例の設定で、すべての記事の目次を三項目へそろえる規則ではありません。

「内容1」「詳しくはこちら」だけでは、資料の説明を読みたい人がどれを選ぶか判断しにくくなります。「準備する資料」のように、本文で得られる答えを名前にしてください。見出しを短くする場合も、目次と移動先で対象が変わらないようにします。

事前資料を探す読者は、どの項目を選ぶでしょうか。図では、目次の名前と本文の同じ見出しを対応させて見てください。

原寸画像を開く

目次が示すのは、記事の全体像と、説明があるはずの行き先です。図に線を引いたことを実移動の成功にせず、組み込んだ記事で、その節の本文を読めるかまで確かめます。

主要な節を先に選び、細かい見出しを載せるか決める

小見出しをすべて並べると、目次を読むだけでも長くなる場合があります。まず大きな問いへの答えがある節を選び、さらに細かい選択が必要な記事だけ、小見出しを加えます。階層を示す場合は、どの大見出しの中の話かが分かる並べ方にします。

W3Cの見出しによるページ構造の説明を参考に、本文の大きな節とその中の小見出しを整理します。見出しの数や文字の大きさをそろえることより、内容のまとまりと関係を伝えることが目的です。

自動の目次で見出しが集まらない問題は、本文の見出し形式や収集対象を調べる別の点検です。配置を変えただけでその原因を解消したとはしません。今回の配置案では、主な節と案内する名前が決まっている前提で進めます。

冒頭を基本に、PC横欄とスマホ途中の案内を選ぶ

最初に読む全体像は本文冒頭に残し、途中の案内は必要な用事があるときだけ追加します。PCの横欄とスマホの本文内では使える幅が違うため、同じ置き方を縮小するのでなく、本文を読める場所を残して選びます。

この架空案には、会社名とサイトメニューの既存固定ヘッダーがあり、今回の検討では変更しません。その実際の高さは未確認です。新たな案内を追加する前に、既存の上部案内と本文・図が占める場所も確認する必要があります。

三案は同じ記事の別の配置検討です。PCからスマホへ変更した結果や、どれが読了率を上げたかを示すものではありません。追加案をどちらも必ず実装する必要もありません。

同じ記事で、本文と案内の場所をどう分けるでしょうか。図では共通の冒頭目次を保ち、PCの横欄とスマホの節の区切りを見ると、違いを追えます。

原寸画像を開く

横欄のために本文や図が細くなりすぎるなら、横欄を小さく詰め込むのでなく、本文内の案内へ戻す選択ができます。案内があることより、読みたい内容と案内を続けて使えることを優先します。

冒頭だけで足りる場合と、途中の入口が必要な場合

読者が最初に一度行き先を選び、その節の中で用事を終えられるなら、冒頭の目次を基本にできます。途中で別の条件を読み比べる、長い節を読んだ後に全体像を見直すといった用事があるなら、その区切りから目次へ戻れる入口を検討します。

「記事の目次へ戻る」は、単に一番上へ戻るリンクと区別して、戻る対象を名前で示す案です。同じ記事の案内の位置へ着くようにします。別の節へ直に進む案内を置く場合も、「次へ」だけでなく、次に読める内容を伝えてください。

スマホの横欄が常に不可能という意味ではありません。ただし、PCと同じ横幅を使えない条件で、本文より案内が目立つ、図を読む場所が消える、説明を閉じないと本文へ戻れないなどの問題がないかを確かめます。見え方の案だけで、実際に使いやすいと判断しません。

追従や開閉を付ける前に、本文と図の場所を守る

案内を常に見せる利点と、読む場所を狭くする不利益を一緒に考えます。固定・開閉・小さなアイコンのどれかを必須にせず、本文を読む用事を妨げないかで判断します。

追従させるなら、既存の固定要素と一緒に見る

追従する目次は、本文を下へ読んだ後も節を選び直せる案になります。一方、画面上部のヘッダーや下部の固定案内と重なれば、本文や図、リンクを読む場所が減ります。実際にページを開き、長い見出しや図の下端、リンクの位置まで読み進めて確認してください。

この例では、PC横欄を追従させるかはまだ未決です。図の横欄があることから追従実装済みとはせず、必要なら使う環境で検討します。画面幅だけでなく、表示領域の高さや文字の拡大なども、見える量に関係します。一律の高さや固定位置を全記事の正解にしません。

開閉するなら、何を開くかと閉じた後を説明する

長い目次を閉じる案は、本文を読む場所を増やせる場合があります。ただし、閉じた状態が分かりにくいアイコンだけなら、目次があることに気づけないかもしれません。「記事の目次を開く」のように役割が分かる名前を検討し、開いた後に内容が読め、本文へ戻れるかを確認します。

開いた案内が本文へ重なる形式にするか、本文を下へ押して表示する形式にするかでも、読む条件が変わります。この記事は操作デモを追加するものではありません。実装する場合に、開閉・キー操作・フォーカスの移り方と本文との関係を確認する担当を決め、同じ記事で試します。

W3Cのフォーカスが隠れないことに関する解説は、キー操作で選ばれた部品が作成側の内容によって全体を隠されないことを扱います。AAの当該基準と、まったく遮られないAAAの基準は別です。一部が重なっただけで即座に当該AA違反と決めたり、見出しの位置だけでサイト全体の適合を判断したりしません。

基準の限定的な判定とは別に、本文と図が普通に読めるかも見ます。読むために毎回案内を避ける必要があるなら、固定を外す、本文内へ置くなど、より単純な配置を検討できます。

移動先と読める位置を、スマホ・PC・キー操作で確かめる

項目名が正しいかだけでなく、実際に選んで、意図した節とその説明を読めるかを確認します。配置案を描いたこと、リンクを指定したこと、実到達と理解を確認したことは別です。

1. 本文と目次を同じ版で照合する。

   記事の主な見出しと並びを読み、目次の項目名・順序・深さが対応するかを見ます。説明を改稿したら、目次側の古い名前も残っていないかを確認します。項目数を合わせるだけで終えません。

2. 表示された項目を選び、移動が止まった先を読む。

   スマホとPCで同じ項目から移動し、意図した見出しと説明に着くかを確かめます。移動中の画面だけで成功にせず、停止後に上部案内へ隠れていないか、図を含む本文を続けて読めるかを見ます。

3. キーボードでも、案内を選べるか確かめる。

   Tabキーで目次のリンクを選び、選んでいる位置を見分けられるか、Enterキーで目的の節へ進めるかを試します。リンクの指定先の位置と、次のTabでどこを選ぶかは別の確認です。実際の挙動を見ず、画面が動いたことだけで全操作を合格にしません。

4. 途中の案内を使い、本文へ戻って読み続ける。

   横欄や本文途中の再案内がある場合、その名前から何が起きるかを読んでから使います。目次へ戻る入口なら目次の位置、別の節への入口ならその節を確かめます。固定・開閉を採用する場合は、開いた内容と本文が重ならないか、閉じ方とキー操作も確認します。

5. 読む人に近い相手へ、探してもらう。

   「事前に用意する資料の説明を探してください」のように、今回の用事を伝えます。選んだ項目や迷った場所を記録し、名前か配置か、本文の説明自体かを分けて直します。操作を観測していないなら、到達や理解を確認済みにしません。

G64の確認方法も、目次の名前・順と節の対応、正しい節へのリンクを扱っています。MDNのnav要素の説明は、主要なページ内案内の意味を示す参考です。すべてのリンクを同じ要素で囲むことや、固定・JavaScript処理を必須にはしていません。

修正依頼は、用事と本文を残す条件まで書く

研修の準備ガイドで、初めて担当する人が「事前に用意する資料」を探せるようにしたいです。主な節は「準備する資料」「当日の流れ」「変更時の連絡」で、同じ名前の節へ案内してください。

冒頭の目次を基本にし、PC横欄を足す案では本文と図の幅を残してください。スマホはPC横欄を小さく載せず、必要なら節の区切りから記事の目次へ戻れる案内を検討したいです。

既存の上部ヘッダーは今回変更しない条件です。実際のページで見出し・本文・図が読めるか、項目からの移動とキー操作、途中の案内からの戻り先を確認してください。実案件では対象URL・原稿版・見た環境と該当箇所を添えます。

これは今回の架空設定に基づく依頼の見本です。既存ヘッダーの実高さ、重なり、実際のキー操作や各案の節への到達は未確認です。読者の理解・読了、問い合わせ数や検索順位、変更後の結果も測っていません。全設定は次の補足で照合できます。

まとめ：同じ記事の見出しと案内を、読む幅に合わせる

目次は記事の全体像と、読みたい節への入口です。導入で答える範囲を示した後に、分かる見出し名と同じ節への案内を置きます。主要な節を先に選び、細かい見出しを載せるかは読者の用事で判断します。

途中の再案内が必要なら、本文と図の幅、既存の固定要素、節を選び直す用事を踏まえて、PC横欄やスマホ本文中の入口を選びます。追従や開閉を付けること自体を目的にせず、実際の移動先と本文の読みやすさ、キー操作を確かめてください。

会社の記事で説明が長くなり、読みたい場所へ案内しにくいときは、対象記事と読む人、探したい内容、現在の目次と困る箇所をDREEXYへお知らせください。支援範囲・費用・条件は個別に確認します。Webサイトの記事構成と読みやすさを相談する