「FAQ で言葉を検索したら、ヒットした箇所が黄色くハイライトされるけど、その上の文字が読めない」——マニュアルサイトや FAQ、ドキュメントサイトの受託でよく受ける指摘です。ブラウザの「ページ内検索」（Ctrl+F / Cmd+F）でヒットした語に付くハイライトは、サイト側の配色を考慮してくれません。ダークテーマや濃い背景色の上だと、ブラウザ標準の明るいハイライトと文字色が衝突し、肝心の「探していた語」がいちばん読みにくくなる。これを直そうとして、JavaScript で本文を走査してヒット箇所を <span> で囲む自前のハイライトを実装すると、今度はその実装の保守と、ブラウザ標準の検索との二重管理が始まります。
この問題は、ブラウザの検索ハイライトそのものの見た目を CSS で整えることで、自前実装なしに解けます。CSS-Tricks が 2026 年 6 月にまとめた ::search-text（CSS-Tricks Almanac） のとおり、ページ内検索でヒットしたテキストを対象にスタイルを当てられる擬似要素が使えるようになりました。本記事では、受託のドキュメント系サイトで「検索しても読める」状態を、CSS だけで担保する方法を整理します。
なぜ「検索ハイライトが読めない」が起きるのか
ページ内検索のハイライトは、ブラウザがユーザー体験として提供する機能で、サイトの CSS とは独立して描画されます。多くのブラウザの初期値は、明るい黄色〜オレンジ系の背景に黒い文字です。これは白背景・黒文字の素朴なページなら問題ありませんが、受託で作る実際のサイトは事情が違います。
ダークテーマの本文（明るい文字色）にこのハイライトが重なると、明るい背景に明るい文字が乗ってコントラストが消えます。逆に、ブランドカラーで背景に色を敷いた領域では、ハイライトの黄色とぶつかって視認性が落ちる。つまり「ハイライトされた瞬間に、その語だけ読めなくなる」という、検索の目的と真逆の状態が起きます。
従来、これを直す手段は限られていました。ブラウザ標準の検索の見た目には触れず、JavaScript で本文を走査して独自のハイライトを実装する——という回避策が一般的でしたが、これには相応の代償があります。
| 対処法 | 問題点 |
|---|---|
| 何もしない（ブラウザ標準のまま） | 配色次第でハイライト箇所が読めない |
| JS で本文を走査して自前ハイライト | 実装の保守コスト・ブラウザ標準検索との二重化・DOM 改変の副作用 |
| ::search-text で標準ハイライトを整える | CSS のみ・標準検索のまま見た目だけ調整 |
::search-text は、この三つ目の選択肢を可能にします。ブラウザのページ内検索という機能はそのまま使い、ヒット箇所の見た目だけをサイトの配色に合わせて上書きする。JavaScript も DOM の改変も要りません。
::search-text の基本 — 標準検索の見た目を上書きする
使い方は、検索でヒットしたテキストに対して、背景色と文字色を CSS で指定するだけです。
/* ページ内検索のヒット箇所をサイトの配色に合わせる */
::search-text {
background-color: #ffd54f; /* サイトのアクセント色 */
color: #1a1a1a; /* その上で確実に読める文字色 */
}
/* いま選択中のヒット（次へ送りで強調される箇所）を区別する */
::search-text:current {
background-color: #ff8a3d;
color: #ffffff;
}ポイントは ::search-text:current です。ページ内検索は通常、すべてのヒット箇所を薄く強調しつつ、いま選択中の一件だけを濃く強調します。:current を併用すると、この「全ヒット」と「現在地」を別の見た目に分けられるため、ユーザーが「いま何件目を見ているか」を見失いません。これは自前実装だと地味に手間がかかる部分で、標準機能に乗ったまま CSS で表現できるのは大きな利点です。
注意点として、::search-text で指定できるのは主に色や装飾線などの限られたプロパティで、レイアウトを変えるような指定はできません。あくまで「標準ハイライトの色を、読める配色に直す」用途に絞るのが正しい使い方です。
アクセシビリティとして「コントラストを保証する」
::search-text を入れる目的は、見た目の好みではなく 可読性の担保です。ハイライトの背景色と文字色のコントラスト比が不足すると、結局ヒット箇所が読めないという元の問題に戻ります。色を指定するときは、背景色と文字色の組み合わせが十分なコントラストを持つかを必ず確認します。
ダークテーマとライトテーマを切り替えられるサイトなら、テーマごとに ::search-text の配色も分けます。
/* ライトテーマ */
::search-text { background-color: #ffe08a; color: #1a1a1a; }
/* ダークテーマ */
[data-theme="dark"] ::search-text {
background-color: #5b73ff;
color: #ffffff;
}このように、配色を「テーマの一部」として設計し、どのテーマでもハイライトが読める状態を保証する。色の組み合わせを直書きで散らさず仕組みで保証する考え方は、contrast-color() で自己修正するカラーシステムの記事と同じ発想です。検索のハイライトも、そのカラーシステムが守備すべき範囲のひとつだと捉えると、設計に一貫性が出ます。
なお ::search-text はページ内検索（ブラウザの Ctrl+F）のヒットを対象にするもので、サイト内に自前で設置する検索フォームの結果ハイライトとは別物です。両者を混同しないことが大切で、サイト内検索の体験設計そのものについては、サイト内検索UXの記事で扱った「探しているものに最短でたどり着かせる」観点とあわせて考えると、検索まわりの体験を漏れなく押さえられます。
受託で導入するときの落とし穴
弊社が改修を引き継いだある業務システムの操作マニュアルサイト（社名は伏せます）では、ダークテーマでページ内検索をすると、ヒット箇所の文字が背景と同化して読めないという問い合わせが、利用企業から繰り返し届いていました。前任の実装は、この対策として JavaScript で本文 DOM を走査し、検索語を <span> で囲んでハイライトを付ける独自実装でした。これがブラウザ標準の Ctrl+F と二重に動き、ハイライトが入れ子になって表示が乱れる副作用も出ていました。
私たちは自前ハイライトの実装を撤去し、ブラウザ標準のページ内検索に一本化したうえで、::search-text と ::search-text:current でライト・ダーク両テーマの配色を整えました。やったのは、独自実装で二重化していた機能を標準機能へ戻し、その見た目だけを CSS で読める配色に直しただけです。結果、テーマを問わずヒット箇所が読めるようになり、DOM を改変していたスクリプトを丸ごと削除できたため、本文のコピーや読み上げに出ていた副作用も消えました。
この案件で一番効いた学びは、ブラウザが標準で持っている機能を、わざわざ JavaScript で作り直さないということです。検索のハイライトのように OS・ブラウザ側が提供する体験は、ユーザーが既に使い方を知っている。そこを独自実装で置き換えると、保守対象が増えるうえに標準機能と衝突します。標準に乗ったまま、足りない部分（配色の可読性）だけを CSS で補う方が、軽くて壊れにくい。
もう一つの落とし穴は、対応状況の差です。::search-text を解釈しないブラウザでは、ハイライトはブラウザ標準の見た目のまま表示されます。つまり「指定が効けば読みやすくなり、効かなくても従来どおり」という安全な劣化になるため、使うこと自体のリスクは低い。ただし「全ブラウザで必ずこの配色になる」と顧客に約束はできないので、どこまで保証するかの線引きは、モダンCSSネイティブ機能の記事で触れた Baseline の考え方で説明できるようにしておきます。
どこから着手するか
ドキュメントや FAQ、マニュアルのように「ユーザーが本文を検索する」前提のサイトを受託しているなら、まず自分のサイトをダークテーマ（または濃色の領域）でページ内検索してみることをお勧めします。ヒット箇所が読みにくければ、それは ::search-text で直すべき場所です。
最初の一歩は、サイトのアクセント色を背景に、その上で確実に読める文字色を組み合わせた ::search-text を一つ書き、:current で現在地を区別すること。テーマを切り替えられるサイトなら、テーマごとの配色も忘れずに分けます。自前のハイライト実装が走っているなら、それを標準検索へ戻せないかも合わせて検討する価値があります。
マニュアルや FAQ で検索しても読めない、自前のハイライト実装が重く保守しづらい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行サイトの検索体験を拝見し、標準機能を活かして可読性とアクセシビリティを担保する形に整えます。
