WCAGの達成基準4.1.2「名前、役割、値」は、ボタン、リンク、フォーム部品などの情報と状態を、ブラウザーや支援技術がプログラムから判別できるようにするための基準です。
画面にボタンが見えていても、コードから名称や用途を判別できなければ、スクリーンリーダーの利用者は何を操作する部品なのか判断できません。
実装では標準のHTML要素を仕様どおりに使い、HTMLだけでは必要な情報を表せない場合にARIAで補います。
「名前、役割、値」が表す情報
ブラウザーはHTMLを解釈し、操作部品の情報を支援技術へ渡します。
このとき支援技術が必要とする情報を、名前、役割、状態や値に分けると理解しやすくなります。
- 名前(accessible name):利用者が操作部品を識別するための名称です。ボタンの「送信」や、入力欄に関連付けた「メールアドレス」などが該当します。HTMLの
name属性とは別の概念です。 - 役割(role):その部品がボタン、リンク、チェックボックスなどのどの種類に当たるかを示す情報です。
- 状態や値(state and value):チェックの有無、開閉状態、スライダーの現在値など、操作によって変わる情報です。
| 画面上の部品 | 名前 | 役割 | 状態や値 |
|---|---|---|---|
| 送信ボタン | 送信 | ボタン | 通常はなし |
| 同意チェックボックス | 利用規約に同意する | チェックボックス | 選択済み、未選択 |
| 音量スライダー | 音量 | スライダー | 現在の音量 |
WCAG 4.1.2が求めること
達成基準4.1.2では、利用者が操作するインターフェース部品について、名前と役割をプログラムで判別できることが求められます。
利用者が変更できる状態、プロパティ、値はプログラムから設定でき、その変化をブラウザーや支援技術が受け取れる必要があります。
これにより、スクリーンリーダーは「送信、ボタン」「利用規約に同意する、チェックなし」のように、部品の名称、種類、現在の状態を利用者へ伝えられます。
基準の位置付けや適合条件は、WCAG 2.2の達成基準4.1.2の詳しい解説で確認できます。
実装は標準HTMLから始める
標準HTMLのボタンやフォーム部品には、役割と操作方法があらかじめ備わっています。
独自の要素をARIAでボタンらしく見せる前に、目的に合うHTML要素がないか確認します。
利用者に伝わる名前を付ける
文字を表示できるボタンには、機能を表すテキストをそのまま置く方法が明確です。
<button type='submit'>送信</button>
アイコンだけのボタンでは、アイコンから目的を推測させず、aria-labelで名前を補います。
<button type='button' aria-label='検索'>
<span aria-hidden='true'>🔍</span>
</button>
aria-labelは支援技術へ伝わる名前を上書きするため、画面に見えるラベルがある場合は、その文言と食い違わないようにします。
役割に合うHTML要素を選ぶ
別のページや場所へ移動する部品には<a>、処理を実行する部品には<button>を使います。
<a href='/help/'>ヘルプを見る</a>
<button type='button'>メニューを開く</button>
role='button'を付けても、要素にフォーカス移動やキーボード操作が自動で追加されるわけではありません。
独自部品を作る場合は、名前と役割だけでなく、フォーカス、EnterキーやSpaceキーによる操作、状態の更新まで実装する必要があります。
ARIAを使う判断や避けたい実装は、ARIAの正しい使い方でも整理しています。
状態や値を実際の表示と同期させる
標準のチェックボックスでは、ブラウザーが選択状態を支援技術へ伝えるため、aria-checkedを重ねて指定する必要はありません。
<input id='agreement' name='agreement' type='checkbox'>
<label for='agreement'>利用規約に同意する</label>
開閉ボタンのようにHTMLだけでは状態を十分に表せない部品では、aria-expandedなどの属性を使います。
<button type='button'
aria-expanded='false'
aria-controls='details'>
詳細を表示
</button>
<div id='details' hidden>詳細情報</div>
開閉処理では、表示の切り替えと同時にaria-expandedをtrueまたはfalseへ更新します。
画面では開いているのに属性がfalseのままだと、見た目と支援技術へ伝わる状態が一致しません。
aria-liveが必要な場面
aria-liveは、チェックボックスやスイッチの状態を表すために一律で付ける属性ではありません。
操作後に検索結果件数や保存完了メッセージなどが別の場所へ追加され、フォーカスを移さずに変化を伝えたい場合にライブリージョンを検討します。
<p id='search-status' aria-live='polite'></p>
広い範囲へaria-liveを付けると、関係のない更新まで読み上げられる可能性があるため、通知文が入る小さな要素に限定します。
実装時に起こりやすい不一致
- 名前がない:アイコンだけのボタンにテキストも代替の名前もなく、目的を判別できません。
- 役割と動作が違う:リンクにボタンの役割だけを付け、ボタンに必要なキーボード操作を実装していません。
- 状態が更新されない:見た目は変化しても、
aria-expandedやaria-checkedが初期値のまま残っています。 - ARIAが重複している:標準HTMLが持つ役割や状態をARIAで重ね、修正箇所を増やしています。
- 通知範囲が広すぎる:ページの大きな領域に
aria-liveを付け、不要な読み上げを発生させています。
確認は名前、役割、状態の順で行う
- キーボードで対象の操作部品へ移動し、意図した操作を実行できるか確認します。
- ブラウザーの開発者ツールで、アクセシブルな名前と役割が意図どおりに計算されているか確認します。
- チェック、開閉、選択などの操作後に、コード上の状態や値も更新されるか確認します。
- スクリーンリーダーで、名前、役割、状態が理解できる順序で伝わるか確認します。
標準HTMLで表現できる部品は標準HTMLを使い、不足する情報だけをARIAで補うと、見た目、操作、支援技術へ伝わる情報を一致させやすくなります。
当社では、ウェブアクセシビリティ対応を支援するUUU ウェブアクセシビリティウィジェットツールを提供しています。機能や導入方法はサービスページでご確認ください。

