スムーススクロールCSS：WordPress干渉とアクセシビリティ対応

CSS の scroll-behavior: smooth は html タグに1行書けば動く。
ただし、それだけでは今の現場水準を下回るケースがある。
動き酔いを起こすユーザーへの配慮と、WordPress プラグインとの干渉——この2点を見落としたまま納品すると、公開後にトラブルになりやすい。
上位記事の大半がこの2点を扱っていないため、実務でそのままコピペすると穴が空いたまま動くことになる。
解決策は prefers-reduced-motion のセット記述と、WordPress でのスコープ絞りの2点だ。

scroll-behavior: smooth は prefers-reduced-motion とセットで書く

対応は CSS を3行追加するだけで完了する——ユーザーの設定を上書きしない形で実装できる。
それにもかかわらず、上位10記事を確認した範囲で prefers-reduced-motion を解説しているものはゼロだった。
前庭障害や視覚過敏を持つユーザーにとって、意図しないスクロールアニメーションは吐き気や頭痛の原因になることがある。
prefers-reduced-motion は、OS の「アニメーションを減らす」設定を受け取るメディアクエリだ。
macOS なら「視覚効果を減らす」、Windows なら「アニメーションをオフにする」に相当する。
この設定を有効にしているユーザーのブラウザでは、prefers-reduced-motion: reduce がマッチする。

html {
  scroll-behavior: smooth;
}

@media (prefers-reduced-motion: reduce) {
  html {
    scroll-behavior: auto;
  }
}

prefers-reduced-motion: reduce 時は scroll-behavior: auto で即時ジャンプに切り替える。
T2（制作会社）案件でアクセシビリティ要件が明記されるケースが増えている今、単体実装のままではチェックリストに引っかかるリスクがある。
自分の案件でも、以前からこの組み合わせを標準実装にしている。

WordPress では html へのグローバル適用がプラグイン干渉を招く

WordPress 案件では、html 全体への適用を避け、.site-main などコンテンツエリアにスコープを絞るのが安全な実装判断だ。
html セレクタへのグローバル適用は、ページ全体のスクロール動作を変える。
Swiper.js や GSAP ScrollTrigger のような独自スクロール制御を持つプラグインが入っていると、挙動が崩れることがある。

以前関わった案件で、数十ページ規模の WordPress リニューアル中にこの問題に当たった。
複数プラグインが常時稼働している環境で html にグローバル適用すると、スライダー送り時にスクロール位置がずれた。
.site-main などコンテンツエリアにスコープを絞ることで解消した。
テーマによってはコンテンツエリアのクラスが .entry-content や #primary の場合もあるため、実装前に確認しておく。

/* html 全体（プラグイン干渉リスクあり） */
html {
  scroll-behavior: smooth;
}

/* スコープ絞り込み（WordPress 推奨） */
.site-main {
  scroll-behavior: smooth;
}

@media (prefers-reduced-motion: reduce) {
  .site-main {
    scroll-behavior: auto;
  }
}

スライダーやパララックス系が入っているかどうかに関わらず、この判断を標準にしておくと後の修正が減る。

固定ヘッダーの位置ズレは scroll-margin-top で解決する

固定ヘッダーがある場合、アンカーリンクで移動するとコンテンツがヘッダーの下に隠れる。
JS でオフセットを計算するより、CSS の scroll-margin-top を使うほうがシンプルだ。
アンカー先の要素に scroll-margin-top: 80px のような値を指定すると、ヘッダー分の位置ズレを CSS だけで解決できる。
ヘッダー高さが可変なら、CSS カスタムプロパティと組み合わせると管理しやすい。

CSS 実装と JS 実装の使い分けと、納品前チェック2項目

CSS 実装と JS 実装の使い分けは、次の基準で判断している。

LP 以外の WordPress 案件では、イージングやコールバックが不要なケースが大半だ。
CSS 実装で十分な場合が多い。
JS が必要な場面は、スクロール完了後に別アニメーションを起動したいときなど、限られた条件に絞られる。
jQuery の .animate() を使う場合、WordPress では読み込みタイミングが原因でエラーが起きやすい。
$ is not defined への対策も同時に想定しておく必要がある。

納品前に最低2点を確認する。

1. OS の「動きを減らす」設定をオンにした状態でアンカーリンクが即時ジャンプするか
2. スライダーやパララックス系のあるページでスクロール位置が正常か

この2点を確認するだけで、公開後の「動き酔いクレーム」と「スライダー誤動作」の大半は防げる。
JS 実装を選ぶ場合は jQuery 競合も起きやすいため、WordPress の jQuery が動かない原因と修正手順も合わせて確認してほしい。

まとめ

• scroll-behavior: smooth は prefers-reduced-motion とセットで書く（CSS 3行追加）
• WordPress では html 全体を避け、.site-main にスコープを絞る
• 固定ヘッダーの位置ズレは scroll-margin-top で解決できる
• 納品前チェックは動き酔い設定オフ時の動作確認とプラグイン干渉確認の2点

コーディング代行・実装判断で詰まったら Build に振ってください。