サイト内検索を入れた直後に「検索するとページの一部が動かなくなる」という報告が上がることがあります。検索の処理自体は正しく、該当箇所も正しく黄色くなっている。それでも、その周辺のアコーディオンが開かなくなったり、フォームの入力内容が消えたりする。
原因はたいてい検索ロジックではなく、ハイライトの入れ方です。 該当文字列を <mark> で囲むために innerHTML を書き換えると、その範囲の DOM は作り直しになります。付いていたイベントリスナーは消え、フォーカスは外れ、React や Vue が管理していた要素なら状態も飛びます。
この副作用を避ける手段が、2026年3月に主要ブラウザで揃いました。
DOMを触らずに色を付ける
CSS Custom Highlight API は、文字列の範囲を JavaScript の Range として指定し、CSS 側で見た目を付ける仕組みです。HTML の構造には一切手を入れません。
const range = new Range();
range.setStart(textNode, 12);
range.setEnd(textNode, 18);
CSS.highlights.set("search-hit", new Highlight(range));::highlight(search-hit) {
background-color: #fff3a3;
color: #1a1a1a;
}やっていることは、ブラウザが ::selection（テキスト選択時のあの色）で以前から持っていた仕組みを、任意の範囲に対して開放したものです。同じ系統に ::spelling-error や ::target-text があり、いずれも DOM の外側で描画される点が共通しています。
DOM が変わらないので、イベントリスナーもフォーカスもコンポーネントの状態も保持されます。 ハイライトを消すときも CSS.highlights.delete("search-hit") を呼ぶだけで、元の HTML を復元する処理が要りません。innerHTML を戻す実装で起きがちな「ハイライト解除のたびに少しずつ壊れる」問題が構造的に発生しなくなります。
対応状況は Chrome / Edge が105（2022年8月）、Safari が17.2（2023年12月）、Firefox が149（2026年3月）。最後の1つが揃ったのが2026年3月で、Baseline に加わったのもこのタイミングです。
できないことのほうが、判断材料になる
導入を検討するとき、実際に効いてくるのは制約のほうです。
1. 使える CSS プロパティが限られる。 指定できるのは color、background-color、text-decoration とその関連プロパティ、text-shadow、そして -webkit-text-stroke-color などのごく一部だけです。background-image は指定しても無視されます。padding や border でハイライトを囲む、角丸を付ける、といった装飾はできません。
2. クリックできない。 ハイライトは描画されるだけで、ポインタイベントの対象になりません。「ハイライトされた箇所をクリックしたら次の該当箇所へ飛ぶ」という UI は、この API 単体では作れません。位置を取るには元の Range から座標を求める処理を別に書くことになります。
3. 支援技術には伝わらない。 ここが最も見落とされます。DOM に何も追加していないため、スクリーンリーダーにとっては、ハイライト前後で文書は完全に同一です。 視覚的に「3件見つかった」ことが分かっても、読み上げでは何も変わりません。
3つ目は、この API の欠陥ではなく設計上の帰結です。装飾であって意味付けではない、という割り切りで作られています。したがって、検索件数や「◯件目 / 全◯件」といった情報は、ハイライトとは別にテキストとして提示する必要があります。 ライブリージョンで件数を読み上げさせるのが定石です。
逆に言えば、「意味を持つ強調」には従来どおり <mark> 要素を使うべきです。 原稿中の重要箇所や検索エンジンに伝えたい強調は、DOM に存在しなければ意味がありません。
発注・実装のときに決めておくこと
「検索結果をハイライトする」という要件は一行で書けますが、実装方式によって満たせる範囲が変わります。要件を詰める段階で確認しておくと、後戻りが減ります。
ハイライトされた箇所を操作するか。 クリックで移動、ホバーで詳細表示といった操作が要件に含まれるなら、Custom Highlight API だけでは足りません。この一行の有無で実装方式が変わります。
ハイライトの見た目に、下線や枠が含まれるか。 背景色と文字色、下線までなら問題ありません。角丸の枠やアイコンが付く指定なら、装飾のプロパティ制限に当たります。デザイン確定前に確認しておく箇所です。
読み上げ環境での要件があるか。 公共系や社内システムでアクセシビリティ要件がある案件では、件数の通知を別途実装する前提で見積もる必要があります。「ハイライトすれば分かる」は、視覚的に見ている人にだけ成り立つ前提です。
DOM を後から書き換えたことで支援技術側の挙動が壊れる話はBlocked aria-hiddenの警告と直し方でも扱いました。今回のハイライトも、根は同じ「見た目を変える処理が、意味の層を巻き込む」問題です。制作会社への発注時にどこまで実装標準を握っておくかについてはState of CSS 2026を発注側が読み解くも合わせて参考にしてください。
次にやること
サイト内検索やドキュメントビューアを持っているなら、ハイライト処理が innerHTML の書き換えで実装されていないか確認してください。 該当する場合、検索後に周辺の操作が効くかどうかを一度試すだけで、潜在的な不具合が見つかることがあります。
新規に組む場合は、要件表の「検索結果のハイライト」の行に「ハイライト箇所への操作の有無」と「件数の読み上げ対応の有無」を書き足しておくと、実装方式の選定がその場で決まります。
サイト内検索の実装、既存サイトのアクセシビリティ改修、フロントエンドの実装標準の整備については、グリームハブの開発・AI・自動化のご相談で承っています。既存実装の構成によって改修範囲が変わるため、個別にご相談ください。お問い合わせからどうぞ。
