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

序章：フォーカス管理という名の「見えない戦場」

フロントエンドのアーキテクトとして大規模なWebアプリケーションのコードベースを監査していると、どうしても見過ごせない「技術的負債」の巣窟に出会う。それがアクセシビリティ（a11y）とデザインの妥協点の間で揺れ動く、無惨にハックされたフォーカス管理だ。

「とりあえず、クリックしたときに青い枠線（Outline）がカッコ悪いから消そう」

そんな安易な `outline: none;` の乱用が、どれほどキーボードユーザーを絶望の淵に突き落とし、果てはブラウザのアクセシビリティツリーを破壊しているか。あなたはその代償を考えたことがあるだろうか？

`:focus` 疑似クラスは、単なる「要素が選択されたときの見た目を変えるスイッチ」ではない。それは、DOMツリー、CSSOM、そしてブラウザのフォーカスリングというハードウェア寄りのレンダリングパイプラインを繋ぐ、極めてクリティカルなインターフェースなのだ。

今回は、この `:focus` の深層に潜り込み、ブラウザエンジンの内部挙動からメモリ効率、非同期描画の競合、そして実務で即座に使える堅牢なアーキテクチャパターンまでを徹底的に解剖していく。

—

1. ブラウザの内部挙動とレンダリング負荷：なぜ `:focus` は最適化が必要なのか

スタイル再計算（Style Recalculation）のコスト

ユーザーが Tab キーを押下し、フォーカスが移動するたびに、ブラウザのレンダリングエンジン（Blink, WebKit, Gecko）は猛烈な勢いで「スタイル再計算（Recalc Style）」のトリガーを引いている。

もし、`:focus` セレクタの指定方法が稚拙であると、DOM全体のスタイル再計算コスト（O(N)のオーダー）が跳ね上がり、60fps（あるいは120fps）の滑らかなスクロールやアニメーションがカクつく原因になる。

特に、以下のようなコストの高いプロパティを `:focus` 内でアニメーションさせたり、レイアウトを伴う変更を行ったりすることは、パフォーマンス上の自殺行為だ。

/ 【悪夢のアンチパターン】レイアウトとペイントを強制する無慈悲な指定 /
input:focus {
width: 110%; / レイアウト（Reflow）の発生：全要素の再計算を誘発 /
margin-left: -5%;
box-shadow: 0 0 20px rgba(0, 0, 0, 0.8); / 高コストなペイント（Paint） /
}

コンポジット（Composite）層だけで完結させる極意

ブラウザのメインスレッドをいかにブロックしないか。これが上級フロントエンドエンジニアの腕の見せ所だ。`:focus` 時の視覚的フィードバックは、原則としてレイアウトやペイントを引き起こさない `transform` や `opacity`、あるいはペイントコストが低い `outline` や `box-shadow`（ただしGPU支援を意識する）に限定すべきだ。

さらに、`outline` プロパティは、レイアウトを一切変更しない（Reflowを引き起こさない）という圧倒的なアドバンテージを持っている。アクセシビリティの観点からも、デザインの観点からも、フォーカスリングには `outline`（あるいは `box-shadow` による代用）を使い倒すべきなのは、こうしたブラウザの内部構造に裏付けられているからなのだ。

—

2. 非同期の競合と動的DOMにおけるフォーカス喪失問題

モダンなSPA（React, Vue, Svelteなど）の全盛期において、最大の敵は「非同期レンダリングとフォーカスのタイミングのズレ」である。

例えば、ユーザーがボタンをクリックしてモーダルを開き、その非同期データフェッチが完了してDOMが再構築された瞬間を想像してほしい。

1. ボタンクリックにより非同期処理が走る。
2. 状態が更新され、DOMツリーに新しいモーダル要素がマウントされる。
3. この時、元のボタン要素がDOMから消滅（あるいは非活性化）すると、ブラウザのフォーカスは `document.body` に強制送還される。
4. キーボードユーザーは突然迷子になり、ページの一番最初から Tab キーを押し直す羽目になる。

「フォーカストラップ」の堅牢な実装

これを防ぐためには、非同期ライフサイクルと完全に同期したフォーカス管理が必要だ。以下は、Vanilla JS / 各種フレームワークの基盤となる、競合のない堅牢なフォーカス制御のアーキテクチャパターンである。

/

  • モーダルなどのコンテナ内へフォーカスを安全に閉じ込める（フォーカストラップ）
  • @param {HTMLElement} container – フォーカスを巡回させる親要素

/
export function trapFocus(container) {
// フォーカス可能な要素を動的にセレクト
const focusableElements = container.querySelectorAll(
‘a[href], area[href], input:not([disabled]), select:not([disabled]), textarea:not([disabled]), button:not([disabled]), tabindex=”0″‘
);

const firstElement = focusableElements[0];
const lastElement = focusableElements[focusableElements.length – 1];

// 次のTick（マイクロタスク）で確実にフォーカスを当てることで、非同期レンダリングの競合を防ぐ
queueMicrotask(() => {
if (firstElement) {
firstElement.focus({ preventScroll: true }); // スパイク的な画面ジャンプを防ぐ
}
});

container.addEventListener(‘keydown’, (e) => {
if (e.key !== ‘Tab’) return;

if (e.shiftKey) {
// Shift + Tab の場合：最初の要素から最後の要素へ逆流させる
if (document.activeElement === firstElement) {
lastElement.focus();
e.preventDefault();
}
} else {
// Tab の場合：最後の要素から最初の要素へ循環させる
if (document.activeElement === lastElement) {
firstElement.focus();
e.preventDefault();
}
}
});
}

ここで注目してほしいのは `preventScroll: true` というオプションだ。`element.focus()` を呼び出した際、ブラウザが勝手にその要素までスクロールさせてしまい、ユーザーの視点を強制移動させる「大きなお世話」な挙動を完全に制御している。この細やかな配慮が、アプリケーションの品質を一段上のステージへと引き上げる。

—

3. 次世代CSSにおける `:focus-visible` との共存アーキテクチャ

`:focus` を語る上で避けて通れないのが、現代のCSSにおける最大の革命の一つ、`:focus-visible` との関係性だ。

伝統的な `:focus` は、マウスでクリックした瞬間にも発火してしまう。結果として、ボタンをクリックした後に「青い枠線が残ったままになる」という、デザイナーにとって悪夢のようなUIが生まれていた。これを回避するために、昔のエンジニアは `blur()` を呼ぶ汚いJavaScriptハックや、イベントリスナーによるクラス付与（`.is-focused`）を行っていた。

しかし、現在は `:focus-visible` がある。

/ 【モダン・アーキテクチャ】

  • キーボード操作（アクセシビリティが必要な場合）のみにフォーカスリングを表示し、
  • マウス操作時には無駄な枠線を排除する、究極のスマートスタイル

/
.interactive-element {
outline: none; / デフォルトの野暮ったい枠線を一旦リセット /
}

.interactive-element:focus-visible {
outline: 3px solid var(–color-primary-focus);
outline-offset: 2px;
/ GPU負荷を考慮した変形やシャドウの付与 /
box-shadow: 0 0 0 4px rgba(var(–color-primary-rgb), 0.3);
}

設計上の注意：フォールバックの担保

`:focus-visible` は非常に強力だが、レガシーブラウザ（一部の古いWebView等）をターゲットに含める必要がある大規模案件では、フォールバック戦略が不可欠だ。

/ 1. まずすべてのフォーカスに対して安全な最低限のスタイルを担保 /
.interactive-element:focus {
outline: 2px solid currentColor;
}

/ 2. :focus-visibleをサポートしているモダン環境では、より洗練されたスタイルで上書きする /
@supports selector(:focus-visible) {
.interactive-element:focus {
outline: none;
}
.interactive-element:focus-visible {
outline: 3px solid var(–color-primary-focus);
outline-offset: 2px;
}
}

この二段構えのCSSアーキテクチャにより、いかなる実行環境であってもアクセシビリティと美観の双方向を完全にハックし、破綻のない堅牢性を実現できる。

—

4. 実務で遭遇する「重大なバグ」の回避策

最後に、現場で実際に遭遇し、原因特定に何時間も費やしたくなるような `:focus` 関連のトラップをいくつか共有しておこう。

トラップ1：SVG要素におけるフォーカスの挙動の差異

SVG内部の要素（`` や ``、さらには `` 自体）にフォーカスを当てようとした際、ブラウザによって `tabindex` の解釈やフォーカスリングの描画挙動がバラバラであるという問題がある。

解決策:
SVG自体を直接フォーカス対象にするのは避け、必ず外部の `

スポンサーリンク

コメント

タイトルとURLをコピーしました