インライン要素のフォーカス制御：アクセシビリティの「詰め」が甘いコードを卒業する
フロントエンドの現場で、「とりあえず動けばいい」と``に`onclick`を詰め込んでいませんか？
かつての僕もそうでした。「クリックできるんだから、ユーザーは使えるはずだ」と高を括っていたのです。しかし、キーボードだけでブラウジングするユーザーや、スクリーンリーダーを使うユーザーにとって、そうした実装は「迷路」でしかありません。
今日は、HTMLのインライン要素（`span`, `a`, `button`など）におけるフォーカス管理の深淵を覗き、明日から使える「プロの作法」を共有します。
—
1. なぜ「インライン要素のフォーカス」が重要なのか
ブラウザは本来、``や`
これを無理やり直そうとして`tabindex=”0″`を適当に振るエンジニアがいますが、実はこれだけでは片手落ちです。「フォーカスが当たったことを視覚的に伝える」ことと、「キー入力によるアクションの発火」という、泥臭い手当が必要になるのです。
—
2. 実装のベストプラクティス：`focus-visible`を使い倒す
かつては`outline: none`を消すのがモダンとされた時期もありましたが、今は違います。`focus-visible`擬似クラスの登場により、「マウス操作時は目立たず、キーボード操作時だけ枠線を表示する」という、UXとアクセシビリティのいいとこ取りが可能になりました。
実践：キーボード対応したカスタム・ボタンのサンプル
以下は、``要素をボタンとして機能させる際の、現場でそのまま使えるテンプレートです。
—
3. ブラウザが裏側で行っていること
ブラウザはDOMツリーを走査する際、`tabindex`が正の数ならその順序に従い、`0`ならDOM構造の出現順にフォーカスを回します。
ここで重要なのは、「フォーカスが当たっている」という状態が、OSレベルのアクセシビリティAPIに正しく伝わっているかです。`role=”button”`を付与することで、ブラウザは「これはボタンとして振る舞うべき要素だ」と認識し、スクリーンリーダーに対して「ボタンですよ」という情報を流します。
もしあなたが`role`を忘れると、スクリーンリーダー利用者は「これはボタンなのか、ただのテキストなのか？」と混乱することになります。
—
4. シニアからのアドバイス：本当に``である必要があるか？
ここまで技術的な実装論を語りましたが、最後に一つだけ。
「可能であれば、最初から`
HTMLには、最初からキーボードイベントやフォーカス制御が組み込まれた「最強のタグ」が用意されています。わざわざ``に`tabindex`を振るという行為は、HTMLが本来持っている恩恵を捨てて、自転車をゼロから自作するようなものです。
どうしてもデザイン上の制約で``を使わざるを得ない場合のみ、今回紹介したテクニックを適用してください。「コードの簡潔さ」は「保守性の高さ」とイコールです。
—
まとめ
- `tabindex=”0″`で要素をフォーカス可能にする。
- `role=”button”`で役割をブラウザに教える。
- `keydown`イベントでEnter/Spaceを補足する。
- `:focus-visible`で、キーボードユーザーにだけ親切なガイドを出す。
フロントエンド開発は、こうした「目に見えない細部」の積み重ねが、プロダクトの品格を決めます。ぜひ、次のプルリクエストで意識してみてください。自信を持って書かれたコードは、必ず誰かに伝わります。
コメント