コラム ／ 制作会社・広告会社向け
固定ヘッダーとページ内リンクの実装｜CSSの余白とキーボード操作を検証
固定ヘッダーで目次の移動先が隠れる問題を、PCとスマホ相当幅で再現しました。CSSの固定値と実寸対応を比べ、見出しの位置・キーボードの操作先・直接リンクを確認する実装例を示します。
長いサービス紹介ページの目次を押したのに、移動先の見出しが固定ヘッダーの裏へ隠れることがあります。対策は、ヘッダーが占める高さをスクロール時の余白へ反映することです。さらに、キーボードの操作先が移動先へ続くかを別に確かめます。
顧客のサービス案内を実装する制作会社様向けに、CSS指定を比較しました。目次の項目選びと依頼内容に続く実装例です。自社ローカルの架空ページを使い、顧客案件の実績とは区別しています。アイキャッチは生成イラストです。
見える位置と次の操作先を分ける
ページ内リンクは、URL末尾の「#scope」のような目印と、移動先のidを対応させます。見出しが画面の上端へ来ても、上部に固定表示があれば文字を読めません。独自の画面移動では、操作位置が目次に残る場合もあります。
今回は通常のリンクを使い、見出しへtabindex=”-1″を付けました。見出しを普段のTab順へ増やさず、移動先としてフォーカスを受け取る形です。idの変更と重複にも注意します。
<a href="#scope">対応範囲を読む</a>
<h2 id="scope" tabindex="-1">対応範囲</h2>PC用の固定値ではスマホの見出しが隠れた
再現ページには、固定の案内と二つの見出しを置きました。指定なし、86px固定のscroll-margin-top、実際のヘッダー高に16pxを足すscroll-padding-top、同じ余白を見出しに付けるscroll-margin-topの四条件です。単位はCSSのpx、小数は概数です。
検証日は2026年11月4日、ブラウザーはIABのChromium 156です。PC幅1280pxとスマホ相当幅390px、いずれも高さ900pxで、画面上端から見出しまでの位置を測りました。
| 指定 | PCの見出し上端 | スマホの見出し上端 |
|---|---|---|
| 余白なし | 約0px：隠れる | 約0px：隠れる |
| 86px固定 | 約86px：読める | 約86px：一部隠れる |
| 実寸＋16pxのpadding | 約86px：読める | 約143px：読める |
| 実寸＋16pxのmargin | 約86px：読める | 約143px：読める |
ヘッダーの下端はPCで70px、スマホで約127pxでした。案内が折り返されるスマホでは、86px固定だと見出しが約41px重なりました。文字の折り返しと実寸を確かめる必要があります。
余白を全体へ付けるか見出しへ付けるかを選ぶ
scroll-padding-topはスクロールする側で上部の表示領域を確保する指定です。ページ全体ならhtmlへ指定します。scroll-margin-topは移動先の要素へ付けます。今回の単純なページでは両方式とも同じ到達位置でした。
次は見出し側へ指定する例です。ResizeObserverでヘッダーのサイズ変更を監視し、高さをCSS変数へ渡します。変数がまだない間の70pxは仮値です。headerが一つあるページ用の例です。実サイトでは固定ヘッダーを指すセレクターへ置換し、対象の存在を確認してください。
/* 問題が残る例：スマホの高さを考慮しない */
h2[id] { scroll-margin-top: 86px; }
/* 修正例：実寸と余白を使う */
h2[id] {
scroll-margin-top: calc(var(--header-height, 70px) + 16px);
}const header = document.querySelector("header");
new ResizeObserver(() => {
document.documentElement.style.setProperty(
"--header-height",
`${header.getBoundingClientRect().height}px`
);
}).observe(header);全体へ付ける方式なら、見出しの指定を外してhtmlへscroll-padding-topを設定します。両方へ同じ余白を重ねると大きく空くため、一方を選びます。独自のスクロール領域があるサイトでは、その領域を対象に見直してください。
この処理は次の移動に使う余白を更新します。移動後に画像やフォントが読み込まれて高さが変わった場合、自動で再配置はしません。遅れて出るお知らせ帯などがあれば、その状態でも確認が必要です。
クリック・直接URL・キーボードで検収する
- 目次をクリックし、見出しが固定部分の下に出るか確認します。
- 目次をEnterで開き、見出しのフォーカスと、次のTabで本文リンクへ進むことを確かめます。
- 目印付きURLを直接開き、同じ見出しを読めるか確かめます。
修正例では二つの幅で三つの操作を確認できました。横方向のはみ出しもありません。ただしスマホは画面幅を変えた検証で、実機、Safari・Firefox、スクリーンリーダーは未検証です。実サイトでは管理バーの有無や文字拡大後も、対象環境で確かめてください。
WCAG 2.2の「フォーカスが隠されない（最低限）」は、キーボードフォーカスを受けた操作対象が、作成者の表示で完全に隠れないことを求めます。すべての見出しの位置へそのまま適用する規則ではありません。本稿でも、見出しの読みやすさと操作対象の見え方を別々に確認しています。
依頼時は固定要素と操作手順を渡す
GreenCodingには、ページ内リンクの実装、スマホでの重なりの修正、WordPressの目次との調整、公開前後の動作確認を相談できます。対象URL、固定要素、画面幅、再現手順から、コーディング・WordPressの対応範囲を具体化できます。
参照した一次資料
公式参照情報
Web案件の進め方が未確定でも、
ご相談いただけます。
支給資料と現在決まっている範囲を確認し、必要な工程、役割分担、実装・検証範囲を整理します。
制作パートナー向けサービスを見る