WAI-ARIA（Web Accessibility Initiative – Accessible Rich Internet Applications）は、HTMLだけでは伝えきれないUIの役割、状態、関係を支援技術に伝えるための仕様です。
スクリーンリーダーなどの支援技術は、画面に見えている形だけでなく、要素の意味や現在の状態を手がかりにして利用者へ情報を伝えます。
そのため、JavaScriptで動くメニュー、展開パネル、スライダー、通知メッセージなどを作るときは、見た目だけでなく「何の部品か」「いま開いているのか」「どの説明と結び付くのか」を正しく伝える設計が必要です。
ただし、WAI-ARIAはHTMLの代わりではありません。
<button>、<nav>、<main>のように、標準HTMLで意味を表せる場合は、まずHTMLの意味をそのまま使うほうが安定します。
WAI-ARIAが必要になる場面
WAI-ARIAが役立つのは、画面上の動きや独自UIの意味が、HTMLだけでは支援技術へ十分に伝わらない場面です。
- 動的コンテンツ：JavaScriptで表示内容が変わる領域に、更新されたことを伝える必要がある。
- カスタムUIコンポーネント：独自に作ったボタン、タブ、スライダーなどに、部品の種類や状態を伝える必要がある。
- 状態が変わる操作部品：開閉、選択、押下状態などを、見た目だけでなく支援技術にも伝える必要がある。
- 説明やラベルの関連付け：入力欄、ボタン、エラーメッセージなどを、読み上げ時にも結び付けて理解できるようにする必要がある。
Webアクセシビリティ全体の考え方から確認したい場合は、Webアクセシビリティとは何かを整理した実務向けの記事も参考になります。
役割、プロパティ、状態の違い
WAI-ARIAでは、要素の意味を伝えるために、主にロール、プロパティ、状態を使います。
| 種類 | 伝える内容 | 例 |
|---|---|---|
| ロール | その要素が何の部品かを伝える。 | navigation、button、slider |
| プロパティ | 要素の名前、説明、ほかの要素との関係を伝える。 | aria-labelledby、aria-describedby |
| 状態 | 要素の現在の状態を伝える。 | aria-checked、aria-expanded、aria-pressed |
| ライブリージョン | 画面上で更新された内容を支援技術へ通知する。 | aria-live |
ロールは「これは何か」を示し、プロパティは「何と関係しているか」を補い、状態は「いまどうなっているか」を伝えます。
この区別をあいまいにすると、見た目は動いていても、支援技術では意図と違う情報として伝わることがあります。
HTMLを優先してからARIAで補う
WAI-ARIAを使う前に確認したいのは、標準HTMLで同じ意味を表せないかどうかです。
たとえば通常のボタンであれば、role="button"を追加しなくても、<button>要素そのものがボタンとしての意味を持っています。
<button aria-pressed="false">表示を切り替える</button>この例では、ボタンであることはHTMLが伝え、押された状態かどうかだけをaria-pressedで補っています。
同じように、ナビゲーション領域にはまず<nav>を使い、複数のナビゲーションがある場合はaria-labelなどで区別します。
<nav aria-label="主要メニュー">
<!-- ナビゲーションメニュー -->
</nav>HTMLで意味を表せる場所に不要なARIAを重ねると、読み上げや操作の解釈をかえって複雑にする場合があります。
カスタムUIでARIAを使う例
独自に作ったUIでは、HTMLの意味だけでは足りないことがあります。
たとえばスライダーのような部品を標準のフォーム部品ではなく独自要素で作る場合、支援技術が値の範囲と現在値を理解できるように情報を補います。
<div role="slider"
tabindex="0"
aria-label="音量"
aria-valuemin="0"
aria-valuemax="100"
aria-valuenow="50"></div>この例では、role="slider"で部品の種類を示し、aria-valuemin、aria-valuemax、aria-valuenowで値の範囲と現在値を伝えています。
実装では、表示上の値が変わるたびにaria-valuenowも更新する必要があります。
スクリーンリーダーでの伝わり方を詳しく確認したい場合は、スクリーンリーダーの基本を解説した記事が役立ちます。
ライブリージョンで更新を伝える
ライブリージョンは、画面の一部が自動的に変わったとき、その更新を支援技術へ伝えるために使います。
たとえばフォームの保存結果、検索結果の件数、エラーメッセージなどは、画面を見ている人には変化が分かっても、支援技術の利用者には気付きにくい場合があります。
<div aria-live="polite">保存しました。</div>aria-liveを使うと、更新されたテキストを支援技術が通知しやすくなります。
ただし、頻繁に変わる内容すべてを通知すると、利用者の操作を妨げることがあります。
通知するのは、利用者が次の判断をするために必要な情報に絞るのが実務上扱いやすい方法です。
実装時に避けたい使い方
WAI-ARIAは、正しく使えばアクセシビリティを補えますが、誤った指定は支援技術の理解を妨げます。
- 標準HTMLで表せる部品に、不要なロールを重ねる。
- 画面上の開閉状態だけを変え、
aria-expandedなどの状態を更新しない。 - ラベルや説明の参照先を間違え、支援技術が関係のない文を読み上げる。
- 見た目の動作だけで確認し、キーボード操作やスクリーンリーダーで確認しない。
とくにカスタムUIでは、ロール、状態、キーボード操作、フォーカス移動がそろって初めて使いやすくなります。
ARIA属性を追加するだけで操作体験まで整うわけではありません。
確認リスト
実装前後では、次の順番で確認すると判断しやすくなります。
- 標準HTMLで表せる要素は、まず標準HTMLで実装する。
- 独自UIにする場合は、必要なロール、プロパティ、状態を明確にする。
- 画面上の状態変化とARIAの状態値がずれないようにする。
- 通知が必要な更新だけをライブリージョンで伝える。
- キーボード操作とスクリーンリーダーで実際の挙動を確認する。
公開後の確認や改善まで含めて考える場合は、Webアクセシビリティ運用の記事もあわせて確認すると、テストと改善の流れを整理しやすくなります。
WAI-ARIAを使うときの考え方
WAI-ARIAは、複雑なUIを支援技術へ伝えるための有効な補助線です。
一方で、HTMLの意味、キーボード操作、フォーカス管理、実機での確認を置き換えるものではありません。
標準HTMLで土台を作り、HTMLだけでは伝わらない役割や状態をWAI-ARIAで補うと、見た目だけでなく操作の意味も伝わるUIに近づきます。
当社では、ウェブアクセシビリティを導入しやすくするUUU ウェブアクセシビリティウィジェットツールを提供しています。
アクセシビリティ向上に関心がある方は、詳細をご覧ください。