「とりあえずaria-label」は卒業しよう。インライン要素のアクセシビリティを極める現場の知見
フロントエンド開発の現場で、皆さんはこんなコードを書いていませんか？
「アイコンだけのボタンだし、とりあえず `aria-label` をつけておけば安心だよね」
確かに動く。スクリーンリーダーも読み上げてくれる。しかし、アクセシビリティというものは、単に「音が出る」ことではなく、「文脈を正しく伝える」ことに本質があります。特に `a` や `span` といったインライン要素は、見た目と意味の乖離が起きやすく、アクセシビリティの落とし穴になりがちです。
今日は、現場で後輩に「そこ、もう少し深掘りしようぜ」と教えるような、一歩踏み込んだインライン要素の制御術を解説します。
—
なぜインライン要素にラベルが必要なのか
HTMLには、`` や `` といった「それ自体が具体的な意味を持たない（あるいは弱い）」タグが存在します。
例えば、装飾されたアイコンボタン。`` タグの中に SVG アイコンだけが入っているケースですね。スクリーンリーダーは、その中の SVG が何者か分からない場合、リンクの URL をそのまま読み上げたり、あるいは無視したりします。これでは、視覚情報に頼らないユーザーは「どこに飛ぶのか」すら知ることができません。
ここで `aria-label` や `aria-labelledby` の出番ですが、この二つの使い分け、明確に説明できますか？
—
aria-label vs aria-labelledby：使い分けの黄金律
この二つは、役割が全く異なります。
- `aria-label`: 要素に「名前」を直書きする。
- `aria-labelledby`: 別の場所にある「テキスト」を名前として参照する。
1. aria-label：シンプルだが「翻訳」の壁に注意
最も手軽ですが、注意点があります。`aria-label` の値は固定文字列です。そのため、ブラウザの自動翻訳機能などが働いた際、ページ内のテキストは翻訳されても、`aria-label` の中身は翻訳されないという事態が発生します。
2. aria-labelledby：賢い設計の鍵
もし、ラベルにしたいテキストが既にDOM上に存在しているなら、迷わずこちらを選びましょう。`id` を参照することで、スクリーンリーダーは「そのIDのテキストをこの要素のラベルとして使う」と解釈します。
—
実践：現場で使えるベストプラクティス
では、実際のコードを見てみましょう。よくある「詳細を見る」ボタンの例です。
なぜ `aria-hidden=”true”` が重要なのか
上のコードで `svg` や `img` に `aria-hidden=”true”` を入れていることに気づきましたか？
これを忘れると、スクリーンリーダーが「画像」「リンク」という二重の情報を読み上げてしまい、ユーザーの認知負荷を無駄に高めてしまいます。「意味のない装飾要素は、スクリーンリーダーから完全に隠す」のが鉄則です。
—
ブラウザはどう処理しているのか？（裏側の話）
ブラウザの「アクセシビリティツリー」を意識したことはありますか？
ブラウザはHTMLをパースする際、DOMツリーとは別に、OSのアクセシビリティAPIへ渡すための「アクセシビリティツリー」を構築します。`aria-label` や `aria-labelledby` を付与するということは、このツリー上の `Accessible Name` というプロパティを上書きしている行為に他なりません。
もし、`aria-labelledby` を使っているのに `id` が重複していたら？ あるいは参照先が見つからなかったら？ ブラウザは混乱し、最終的に「リンク」とだけ読み上げたり、ひどい場合は無視したりします。「IDは文書内で一意であること」。この基本原則が、アクセシビリティにおいても命綱になるのです。
—
明日から意識すべき「脱・機械的な実装」
最後に、一つだけアドバイスさせてください。
アクセシビリティ対応を「チェックリストの消化」にしないでください。
「このリンクをクリックするユーザーは、今どんな文脈にいるのか？」
「このアイコンは、果たして文字で補足する必要があるのか、それとも音で聞くと逆にノイズになるのか？」
これらを自問自答することが、真のフロントエンド・スペシャリストへの第一歩です。`aria-label` を貼って終わりではなく、実際に VoiceOver などのスクリーンリーダーを起動し、自分の作った UI がどう「語りかけてくるか」を体験してみてください。
その泥臭い検証の先にこそ、誰にとっても使いやすい、美しいインターフェースが待っています。
コメント