「なんとなく実装」は卒業しよう。``タグのキーボード操作とフォーカス管理の深淵
フロントエンドエンジニアなら、一度は「``タグに `tabindex` を当てるべきか否か」で迷ったことがあるはずだ。
「とりあえず動けばいい」という実装を繰り返していると、いつの間にかアクセシビリティの負債が積み上がり、キーボードユーザーがサイトを回遊できなくなるという致命的な状況に陥る。今回は、ブラウザが裏側でどうやってフォーカスを追いかけているのかという「仕組み」から、明日から使える「現場のベストプラクティス」までを深掘りしていく。
ブラウザの裏側：フォーカス管理の正体
ブラウザは、HTMLドキュメントをパースする際、DOMツリーを上から順に辿り、「フォーカス可能（Focusable）」な要素をリストアップする。
具体的には、``タグのように `href` 属性を持つものや、`
ここで中級エンジニアが意識すべきなのは、ブラウザが「どの要素にフォーカスを当てるべきか」を決定するアルゴリズムだ。`tabindex` を不用意に指定すると、このブラウザの賢いデフォルトの挙動を破壊し、予期せぬ順序でフォーカスが飛ぶ「フォーカス迷子」を引き起こすことになる。
`:focus` と `:focus-visible`：デザイナーとエンジニアの妥協点
「`outline: none` を外すとダサい」とデザイナーに言われた経験は誰にでもあるだろう。だが、`outline` を全消去するのはアクセシビリティの観点からは自殺行為だ。
ここで救世主となるのが `:focus-visible` 擬似クラスだ。これは「今、その要素がキーボードで操作されているか？」を判定し、必要な時だけフォーカスリングを表示してくれる、現代の救世主だ。
/ 現場で即採用すべきベストプラクティス /
a {
/ デフォルトのブラウザの outline は消す /
outline: none;
}
a:focus-visible {
/ キーボードで操作された時だけ、目立つスタイルを当てる /
outline: 3px solid #007bff;
outline-offset: 2px;
border-radius: 4px;
}
この実装を行うだけで、「マウス操作の時はスッキリと、キーボード操作の時は迷わず」というプロフェッショナルな挙動が手に入る。
`tabindex` は「魔法の杖」ではなく「最後の手段」
`tabindex` は制御が難しい。特に `tabindex=”0″` を使えばどんな要素でもフォーカス可能になるが、やりすぎるとDOM構造とフォーカス順序が乖離し、ユーザーは混乱する。
基本は「HTMLの構造順序を正しく保つこと」。これが最もクリーンで、読み上げソフトにとっても優しい。どうしても順序を制御したい場合は、以下のコードのように、要素の役割を明確にした上で適用するのが鉄則だ。
チームへの提言：アクセシビリティは「おまけ」ではない
最後に一つ。キーボード操作の最適化を「後回し」にするのはやめよう。
もし君がチームの技術選定に関わる立場なら、実装の定義（DoD: Definition of Done）に「Tabキーで全てのインタラクティブ要素へ到達でき、かつ現在のフォーカス位置が視覚的に明確であること」を組み込むべきだ。
ブラウザの仕様を理解し、`:focus-visible` を使いこなし、DOM構造を綺麗に保つ。これら一つひとつの積み重ねが、君が作るサイトを「ただ動くサイト」から「世界中の誰もが快適に使えるプロダクト」へと昇華させる。
現場で迷ったら、まずは「キーボードだけでこのページを完走できるか」を試してみてほしい。その泥臭いテストこそが、最高峰のフロントエンドへの第一歩だ。
コメント