なぜその「ただのspan」がアクセシビリティを殺すのか —— インライン要素とARIAの正しい関係
現場でコードレビューをしていると、未だに「とりあえずspanで囲んでクリックイベントを貼る」という実装によく出くわします。「動けばいい」というフェーズなら否定はしませんが、それがプロダクトの信頼性を支える一線級のコードかと言われると、答えはNOです。
HTMLには、ブラウザが解釈するための「セマンティクス（意味論）」という強固な土台があります。インライン要素（`a`, `span`, `strong`, `em`, `code`, `time` など）を扱う際、その土台をARIAロールで無理やり書き換える前に、一度立ち止まって考えてみましょう。
1. セマンティクスの優先順位：ARIAは「最後の手段」
大原則を叩き込んでください。「ネイティブ要素（HTMLタグ）で表現できるなら、ARIAロールは使うな」です。
例えば、`span`に`role=”button”`を付与してクリックイベントを実装するなら、素直に`
しかし、既存のUIライブラリや複雑な装飾、あるいは動的なコンポーネントの中で、どうしても「意味付け」を補強しなければならない場面は確実にあります。その時のための「正しい作法」を解説します。
2. インライン要素とARIAの現場的ベストプラクティス
アクセシビリティを担保するためには、ブラウザがアクセシビリティツリーをどう構築しているかを想像するのが近道です。
case 1: `time`要素の補完
`time`要素は、マシンリーダブルな日時データを提供しますが、スクリーンリーダーが読み上げる際に少し工夫が必要です。
case 2: `a`タグによるトリガー操作
リンクではないのにページ遷移を伴わない操作を`a`タグで行う場合（SPAのルーターなど）、`role=”button”`を付与することで、ブラウザに「これはリンクではなくボタンとして振る舞う」と宣言できます。
3. 実践：カスタムコンポーネントのアクセシビリティ向上
では、これらを統合した「実務で使える」パターンを見てみましょう。例えば、コードスニペットのコピーボタンや、ステータスを示す装飾タグなどによくあるケースです。
ここで重要なのは以下の3点です。
- `tabindex=”0″`: キーボードで操作可能にするための必須属性。
- `aria-hidden=”true”`: 装飾要素がスクリーンリーダーの読み上げを邪魔しないようにする。
- キーボードイベント: `click`だけでなく、`Enter`や`Space`キーへの対応を忘れない。
4. まとめ：なぜ私たちは「正しいマークアップ」を目指すのか
結局のところ、ARIAロールは「HTMLの不足を補うための絆創膏」です。過剰なARIAは、かえってスクリーンリーダーの挙動を複雑にし、ユーザーを混乱させます。
1. まずはHTMLタグの選択を見直す（`button`, `a`, `article` など）。
2. 意味が不足している場合のみ、必要最小限のARIAを付与する。
3. ブラウザのアクセシビリティツリーをデベロッパーツールで確認する。
フロントエンドの仕事は、コードを書くことそのものではなく、「ユーザーがその情報を正しく受け取れる環境を整えること」です。技術の泥臭い部分こそが、ユーザーにとっての「使いやすさ」に直結します。ぜひ、次回のプルリクから「この`span`に`role`は本当に必要か？」と自問してみてください。そこからが、真のプロフェッショナルなフロントエンド開発の始まりです。
コメント