インライン要素に `role` を足す前に：セマンティクスをハックする技術と「禁じ手」
フロントエンド開発の現場で、ふと立ち止まる瞬間がある。「この ``、クリックできるなら `role=”button”` を付ければいいんじゃないか？」と。
結論から言えば、それは「最後の手段」であるべきです。
今日は、HTMLのインライン要素における `role` 属性の付与と、ブラウザのアクセシビリティツリー（AOM）が裏側でどう動いているのか、そして私たちが守るべき「セマンティクスの優先順位」について、現場の知見を交えて掘り下げます。
—
1. なぜブラウザは「role」というメタデータを欲しがるのか
私たちが `
そこで登場するのが `role` 属性です。`role` は、HTMLのデフォルトのセマンティクス（意味付け）を上書きする、いわば「強制的な身分証明」です。
しかし、ここで重要な原則があります。
「HTMLのネイティブ要素に備わっている役割を、わざわざ `role` で上書きしてはいけない」 というルールです。
例えば、`
—
2. 実践：適切なセマンティクスの拡張と「泥臭い」落とし穴
では、インライン要素に `role` を付与してセマンティクスを拡張すべきケースはどこでしょうか。最も典型的なのは、「見た目はリンクやボタンだが、構造上 `` や `
NGパターン：ただroleを付けるだけ
アクション実行
これをしてしまうと、スクリーンリーダーユーザーには「これはボタンだ」と伝わるのに、キーボードの `Tab` キーでフォーカスできず、`Enter` キーも反応しないという「不完全なインターフェース」が爆誕します。これがアクセシビリティ地獄の入り口です。
ベストプラクティス：機能まで模倣する
もし `` でボタンを作るなら、以下の要素をすべて自前で実装する必要があります。
詳細を見る
解説：
1. `tabindex=”0″`: これがないとキーボードでフォーカスが当たりません。
2. `onkeydown`: `button` タグの標準動作である「キーボードによる押下」をJavaScriptで再現する必要があります。
3. `aria-label`: `span` の中身が簡素な場合、読み上げの文脈を補足します。
—
3. なぜ「HTMLネイティブ」が至高なのか
ブラウザのアクセシビリティツリーを覗くと、`role` を無理やり当てた要素は、しばしば「不完全な実装」として判定されます。
ブラウザのエンジン（BlinkやWebKit）は、ネイティブ要素に対してはOSレベルのアクセシビリティAPIと直接連携する最適化を行っています。例えば、`
一方、`role` を付与した要素は、これらすべてを自分たちで「再発明」しなければなりません。これこそが、私たちが可能な限り `
—
4. 現場で使えるスマートな使い分けの指針
もしインライン要素を装飾・拡張する場合、以下の優先順位で検討してください。
1. 第一選択： `
現場のTips：`time` 要素の正しい活用
意外と忘れられがちですが、`
これは `role` をいじるよりも遥かに健全で、SEOやアクセシビリティのスコアを確実に押し上げます。
—
最後に：コードは「対話」である
私が新人の頃、先輩に言われた言葉が今でも胸に残っています。
「コードはブラウザに対して書くんじゃない、その先でそれを使う人間に対して書くんだ」
`role` 属性は強力なツールですが、魔法の杖ではありません。HTMLのセマンティクスをハックする前に、一度立ち止まって考えてみてください。「これは本当に `` である必要があるのか？ それとも、自分のCSSの力不足を `role` で誤魔化そうとしているだけではないか？」と。
ネイティブなHTMLを愛し、どうしても必要な時だけ賢く拡張する。それこそが、シニアエンジニアが持つべき「矜持」だと私は信じています。
この記事が、あなたの次のマークアップの一助となれば幸いです。また現場でお会いしましょう。
コメント