インライン要素のアクセシビリティを極める：aria-labelとaria-labelledbyの「正しい」使い所
フロントエンド開発の現場で、HTMLのセマンティクスを意識しているエンジニアは多いはずです。しかし、「ボタンの中にアイコンしかない」「複雑なラベルを持つリンク」といったUIに直面したとき、`aria-label` や `aria-labelledby` をなんとなく使って解決させてはいないでしょうか？
今回は、インライン要素（`a`, `span`, `strong` など）におけるアクセシビリティのアクセントとして、これらARIA属性を「どう使うのが正解か」、そして「ブラウザの裏側で何が起きているのか」を深掘りします。
なぜ `aria-label` は「最後の手段」なのか
まず大前提として、「HTMLは可能な限りテキストで語らせる」のが鉄則です。スクリーンリーダーは、その要素が持つ「名前（Accessible Name）」を読み上げます。`aria-label` はその名前を強制的に上書きするプロパティであり、言わば「禁じ手」に近い側面があります。
もし、`a` タグの中にアイコンフォントだけが配置されている場合、以下のように書くのが一般的ですが、これには落とし穴があります。
これだと、スクリーンリーダーには「リンク」としか伝わりません。ここで `aria-label` の出番です。
ここで重要なのは、`i` タグに `aria-hidden=”true”` を入れている点です。これを忘れると、スクリーンリーダーの種類によっては「設定画面へ移動、設定アイコン、リンク」のように、冗長な読み上げが発生してしまいます。
`aria-labelledby` で「つながり」を定義する
次に、`aria-labelledby` です。これは「特定のIDを持つ要素をラベルとして参照する」属性です。`aria-label` が「自己完結型」なら、こちらは「参照型」です。
例えば、記事一覧のカードUIで、タイトルがリンクになっているようなケースを想像してください。
モダンCSSの設計手法
…
このコードの何が賢いかというと、スクリーンリーダーはリンクにフォーカスした際、「続きを読む、モダンCSSの設計手法」と連結して読み上げてくれます。ユーザーは「何について書かれた記事を読もうとしているのか」を即座に理解できるわけです。
ブラウザの裏側：アクセシビリティツリーの視点
ブラウザはHTMLをパースする際、DOMツリーとは別に「アクセシビリティツリー」を構築します。
`aria-label` や `aria-labelledby` を指定すると、ブラウザはその要素の「Accessible Name」プロパティを書き換えます。
注意すべきは、「`aria-labelledby` は `aria-label` よりも優先順位が高い」という仕様です。同じ要素に両方記述しても、ブラウザは `aria-labelledby` を採用します。この優先順位を理解していないと、デバッグ時に「なぜかラベルが反映されない！」という泥沼にはまることになります。
実務で役立つ「コピペ可能な」パターン集
最後に、現場でよくある「少し工夫が必要なパターン」をまとめました。
1. 複数の情報を統合するリンク
(オンライン)
2. タイムスタンプに補足を入れる（time要素）
`time` 要素はそれ自体がセマンティックですが、スクリーンリーダーには「日付の読み上げ形式」が曖昧な場合があります。
結論：アクセシビリティは「想像力」
アクセシビリティ対応は、単なる仕様の遵守ではありません。「目が見えないユーザーが、このUIに触れたときに迷わないか？」という想像力の勝負です。
- `aria-label` は、どうしても名前が付けられない時の「最終手段」。
- `aria-labelledby` は、画面上の既存テキストを活用して「文脈」を補完する「スマートな手段」。
これらを使い分けるだけで、あなたの書くHTMLは、機械的なタグの羅列から、誰にでも優しい「対話的なインターフェース」へと進化します。まずは今開発しているコンポーネントで、スクリーンリーダーの読み上げを一度試してみてください。その「気付き」こそが、シニアエンジニアへの第一歩です。
コメント