【テクニカル・上級編】 :focus-visible 疑似クラス – CSS実践ガイド

`:focus-visible` の要塞化：キーボードユーザーのアクセシビリティと描画パフォーマンスを極限まで両立させるアーキテクチャ

こんにちは。フロントエンドの現場で日々CSSの描画パフォーマンスとアクセシビリティの狭間に頭を悩ませているエンジニアなら、一度は `:focus` 疑似クラスの暴力的なまでの「全方位フォーカスリング表示」に殺意を覚えたことがあるはずだ。

マウスでボタンをクリックした瞬間、あるいはJavaScriptからプログラムでモーダルを開き、強制的に要素へフォーカスを奪還させた瞬間に、野暮ったい青や黒のリングがバキッと現れる。デザインチームからは「マウス操作の時は消してくれ、でもキーボード操作の時はアクセシビリティ担保のために絶対出せ」という、ブラウザのデフォルト挙動を真っ向から否定する要件が飛んでくる。

かつて、私たちはこの課題を解決するために、JavaScriptで `mousedown` イベントを監視し、`body` 要素に `.is-user-tabbing` のようなクラスを付与するという、泥臭いハックを量産していた。DOMツリー全体を監視し、イベントリスナーのオーバーヘッドを背負いながら、メモリリークの恐怖に震える日々だ。

しかし、現代のブラウザエンジンには、この問題に終止符を打つための決定的な仕様が存在する。それが `:focus-visible` だ。

今回は、この `:focus-visible` を単なる「便利なCSSセレクタ」としてではなく、エンタープライズ規模のWebアプリケーションを堅牢に支えるためのパフォーマンス最適化とアクセシビリティの要塞として、内部挙動のレベルから徹底的に解剖していく。

—

1. ブラウザの内部挙動：なぜ `:focus-visible` は「賢い」のか？

まず、CSSエンジニアとして理解しておかなければならないのは、`:focus` と `:focus-visible` の根本的なレンダリングの差だ。

従来の `:focus` は、要素がフォーカスを得たという「状態（State）」のみに反応する。マウス、タッチ、キーボード、あるいはスクリプトによる `.focus()` の呼び出し。これら全てを無差別でキャッチし、同一のスタイルを適用する。そのため、マウスユーザーにとって不要なフォーカスリングが描画され、UIの洗練度を損なってきた。

一方、`:focus-visible` は、ブラウザのヒューリスティクス（推測アルゴリズム）に基づいて動作する。User Agent（UA）の内部ステートマシンは、直前の入力デバイスの種別や、要素のセマンティクス、さらにはテキスト選択の有無などを総合的に判断し、「このフォーカスはユーザーが意図的にキーボード等のナビゲーションで行ったものか？」を判定する。

内部挙動のメカニズム

BlinkやGeckoなどのモダンなレンダリングエンジンでは、フォーカスリングを表示すべきかどうかのフラグを要素ごとに保持している。
1. キーボードによるフォーカス移動 (`Tab` キーなど) -> フラグ `ON`
2. マウスによるクリック -> フラグ `OFF` （ただし、`` などのテキスト入力系要素は、ユーザーがテキストカーソルを置く必要があるため、例外的に `ON` になることが多い）
3. プログラムによる `.focus()` -> 基本的にフラグ `OFF`

この判定をブラウザのC++層（Native層）でネイティブ処理するため、私たちがJavaScriptでイベントを拾ってDOMを書き換えるアプローチに比べ、メインスレッドのJavaScript実行コストを完全にゼロに抑えつつ、極めて高速なスイッチングを実現している。メモリ効率の観点からも、余計なイベントリスナーを持たない分、GC（ガベージコレクション）のプレッシャーを軽減できる。

—

2. 実務で直面する「非同期の競合」とフォーカストラップの罠

SPA（Single Page Application）や複雑なWebアプリケーションを構築する際、私たちはしばしばJavaScriptを用いて非同期にフォーカスを制御する。例えば、モーダルが開いた瞬間に最初の入力要素にフォーカスを当てる処理だ。

ここで問題が発生する。非同期で `.focus()` を実行した際、ブラウザのヒューリスティクスが誤作動を起こし、キーボードでモーダルを開いたにもかかわらず `:focus-visible` が発火しない、あるいはその逆の現象が起きることがある。

この「非同期の競合」を回避し、かつどのようなコンテキストからフォーカスが当てられても意図したアクセシビリティを担保するためには、CSS側でのフォールバックと、必要に応じた明示的なステート管理のハイブリッド戦略が必要になる。

堅牢なフォーカス管理のためのCSSアーキテクチャ

実務でそのまま使える、洗練されたベーススタイルのコードを見てほしい。

/
グローバルなリセットと、すべてのフォーカスのブループリント
まずはブラウザデフォルトの粗野なアウトラインを完全に殺す。
/
:focus,
:focus-visible {
outline: none;
}

/
【コア戦略】
マウス操作による不要なリングを排除しつつ、
キーボード操作やアクセシビリティツール、
あるいは明示的なプログラムフォーカスに対しては強固なインジケーターを付与する。
/
.interactive-element:focus-visible {
/ 描画パフォーマンスを考慮し、レイアウトシフトを起こさない box-shadow を活用 /
outline: 2px solid transparent; / フォールバック用 /
box-shadow: 0 0 0 3px var(–color-background), 0 0 0 5px var(–color-primary-500);
transition: box-shadow 150ms cubic-bezier(0.4, 0, 0.2, 1);
}

/
【フォールバック戦略】
もしブラウザが :focus-visible をサポートしていない太古の環境（IEや極端に古いUA）である場合、
最低限のセキュリティとして通常の :focus で担保する。
/
@supports not selector(:focus-visible) {
.interactive-element:focus {
box-shadow: 0 0 0 3px var(–color-background), 0 0 0 5px var(–color-primary-500);
}
}

このアプローチの美しさは、`outline` ではなく `box-shadow` を用いている点にある。`outline` は要素のボックスモデルの外側に描画されるため、レイアウトによってはコンテナからはみ出してスクロールバーが発生する原因になる。一方、`box-shadow` はペイントレイヤー（Paint Layer）での処理となるため、GPUアクセラレーションの恩恵を受けやすく、リフロー（Reflow）を発生させずに滑らかな描画を行える。

—

3. コンポーネント設計における `:focus-visible` の適用パターン

デザインシステムやUIライブラリ（React, Vue, Svelteなど）を設計する際、カスタムコンポーネント（例えば、独自のスタイリングを施したチェックボックスやドロップダウン）に対してどのように `:focus-visible` を適用すべきか。

多くの開発者が犯す過ちは、隠蔽されたネイティブの `` に対してスタイリングを行い、カスタム表示用の `` などをコントロールしようとして迷子になることだ。

正解は、「視覚的なフォーカスを受ける要素（LabelやWrapper）と、実際のフォーカスを持つネイティブ要素のセマンティクスを完全に一致させ、親から子へのカスケードを利用する」ことだ。

利用規約に同意する

これに対応するCSSは以下のようになる。

/ スクリーンリーダー対応の不可視化（レイアウトを破壊せず、読み上げのみ維持） /
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}

/
ネイティブinputがフォーカスを得た時、
兄弟要素である .checkbox-ui に対してスタイルを伝播させる
/
.checkbox-native:focus-visible + .checkbox-ui {
box-shadow: 0 0 0 2px var(–color-background), 0 0 0 4px var(–color-primary-600);
border-color: var(–color-primary-600);
}

/ カスタムUIの基本スタイル /
.checkbox-ui {
display: inline-block;
width: 20px;
height: 20px;
border: 2px solid var(–color-border);
border-radius: 4px;
background-color: var(–color-surface);
transition: all 120ms ease-in-out;
}

この手法の優れている点は、JavaScriptを一切書かずに、ブラウザのネイティブなフォーカス管理と `:focus-visible` の判定ロジックをそのままカスタムUIの見た目に直結させているところだ。余計なリアクティブステートを持つ必要がないため、メモリ効率も最高峰に達する。

—

4. 重大なバグの回避策：iOS SafariとWebKitの挙動差異

フロントエンドエンジニアにとって最大の悪夢は、ブラウザ間の実装差異だ。特に `:focus-visible` に関しては、AppleのWebKit（Safari, iOS Safari）が長年にわたり独自の挙動やバグを抱えてきた歴史がある。

特に古いバージョンのiOS Safariや特定の条件下では、ボタン（``）をクリックした際に `:focus-visible` が期待通りに消えず、タッチデバイスであるにもかかわらずフォーカスリングが残留し続けるという忌々しいバグが存在した。

この問題をハックではなく、堅牢なCSSアーキテクチャの範疇でいなすための知見がこれだ。

タッチデバイスにおける意図しないフォーカス残留の防衛策

/
メディアクエリを併用し、ポインティングデバイスが「粗い（タッチ操作主体のデバイス）」ことが確実な場合、
強制的にフォーカススタイルを抑制するレイヤーを挟む。
/
@media (hover: none) and (pointer: coarse) {
.interactive-element:focus-visible {
/ タッチデバイスでの不要な永続的フォーカスリングをカットする防衛コード /
box-shadow: none;
}
}

`@media (hover: none) and (pointer: coarse)` を組み合わせることで、「今、ユーザーはスマホやタブレットのタッチスクリーンで操作している」というハードウェア特性をCSSレベルで正確に捕捉できる。これにより、WebKit特有のフォーカス残留バグに怯える必要がなくなる。

さらに、JavaScriptからプログラムでフォーカスを動かす際、一部のブラウザで `:focus-visible` がトリガーされない不都合を補う必要がある場合は、次のようなカスタムプロパティ（CSS変数）と組み合わせたステート制御を最後の砦として用意しておくと完璧だ。

// どうしてもプログラム制御でフォーカスリングを強制したい場合の例外処理パターン
const element = document.getElementById(‘my-special-modal’);
element.focus();
// 必要に応じて強制的にフラグ用のカスタム属性を付与してCSS側でフックする
element.setAttribute(‘data-focus-ring’, ‘true’);

/ CSS側での拡張フック /
.interactive-element:focus-visible,
.interactive-element[data-focus-ring=”true”] {
box-shadow: 0 0 0 3px var(–color-background), 0 0 0 5px var(–color-primary-500);
}

—

5. チーフアーキテクトからの提言：アクセシビリティは「おまけ」ではない

`:focus-visible` の実装は、単に「デザインの要望通りにマウスの時だけリングを消す魔法のセレクタ」などではない。それは、「Webというプラットフォームのセマンティクスと、ユーザーの入力デバイスの文脈を、ブラウザの描画エンジンと直接対話させながら調停するための高度なアーキテクチャ」である。

JavaScriptによる重厚なイベント監視や、無駄なリアクティブステートの保持を捨て、ブラウザのネイティブな最適化を信頼してCSSに処理を委譲する。この選択の積み重ねこそが、低スペックなモバイル端末からハイエンドなデスクトップ環境まで、あらゆるユーザーにとって滑らかで堅牢なWebアプリケーションを実現する唯一の道だ。

今日からあなたのプロジェクトのグローバルCSSを見直し、すべての `:focus` を `:focus-visible` へと昇華させよう。コードの美しさとパフォーマンスのキレが、一段上のステージへと引き上げられるはずだ。