`aria-describedby`でアクセシビリティの「解像度」を上げる：脱・初心者アクセシビリティの処方箋
フロントエンドの現場で、「とりあえず`aria-label`を振っておけば大丈夫」と安易に考えていないだろうか？ 確かにそれも一つの手だが、それだけでは救えないユーザーがいる。特に、`a`タグや`button`といったインタラクティブな要素に対して、その補足情報をどう伝えるかは、UIの完成度を分ける「最後のひと押し」だ。
今回は、インライン要素にさらなる文脈を付与する最強の武器、`aria-describedby`について深掘りしていこう。
1. なぜ `aria-label` だけでは不十分なのか？
`aria-label`は要素の「名前」を定義する。つまり、スクリーンリーダーに対して「このボタンは『削除』です」と伝えるものだ。しかし、これだけでは「何が削除されるのか？」「削除した後に何が起きるのか？」という、UXに直結する「説明」を補完できない。
そこで登場するのが`aria-describedby`だ。これは、「その要素を補足する別の要素」と紐付けるためのid参照である。
2. ブラウザの裏側で何が起きているのか
スクリーンリーダーが`aria-describedby`を見つけると、ブラウザのアクセシビリティツリー上で、指定されたidを持つ要素の「テキスト内容」を、対象要素の「説明文（Description）」として連結させる。
重要なのは、`aria-label`が「名前（Name）」を置き換えるのに対し、`aria-describedby`は「説明（Description）」を追加するという点だ。ユーザーがそのリンクにフォーカスした際、スクリーンリーダーは「リンク名」を読み上げた直後に、「説明文」を続けて読み上げる。これにより、視覚情報がなくても、ユーザーは文脈を完璧に理解できる。
3. 実践：現場で使えるベストプラクティス
よくあるケースとして、「詳細を見る」といった汎用的なリンクが並ぶUIを想像してほしい。これだけでは、スクリーンリーダーユーザーには何の詳細なのか全く伝わらない。
以下のコードは、`aria-describedby`を使って、具体的なドキュメント名と関連付けるスマートな実装例だ。
さらに踏み込んだテクニック：`span`での隠し補足
デザイン上、画面には表示させたくないが、スクリーンリーダーには伝えたい情報がある場合がある。そんな時は、`sr-only`（スクリーンリーダー専用クラス）を組み合わせるのが常套手段だ。
/ 視覚的には隠すが、スクリーンリーダーには読み上げさせる鉄板CSS /
.sr-only {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
border: 0;
}
購入する
価格は5,000円です。クリックすると決済画面へ移動します。
4. 注意すべき落とし穴
`aria-describedby`を使う際に、シニアとして忠告したいのが「やりすぎ」の回避だ。
- idの重複は厳禁: `aria-describedby`はidを参照するため、ページ内に同じidが存在すると挙動が壊れる。コンポーネント指向で開発しているなら、`useId`（React等の場合）などを使って、確実にユニークなIDを生成すること。
- 過剰な読み上げ: あまりに長い文章を紐付けると、ユーザーは「名前」にたどり着くまでに時間がかかり、ストレスになる。あくまで「補足」にとどめるのが正解だ。
まとめ：アクセシビリティは「思いやり」のコード化である
`aria-describedby`は、単なるWAI-ARIAの仕様ではない。そのボタンやリンクが置かれている「文脈」を、全てのユーザーに公平に届けるための架け橋だ。
仕様書をなぞるだけなら誰でもできるが、ユーザーがその情報をどう受け取るかまで想像してIDを振るのが、我々フロントエンドエンジニアの矜持というものだ。今日のコードから、ぜひ一つ、この「文脈の継承」を取り入れてみてほしい。現場のプロダクトが、一段上の信頼性を獲得できるはずだ。
コメント