WCAG 2.2の達成基準4.1.2「名前、役割、値」は、フォーム、リンク、ボタンなどのUIコンポーネントを、ブラウザや支援技術がコードから把握できるようにする基準です。
達成レベルはAであり、カスタムUIを含む画面を設計するときの基礎になります。
対応の出発点は、見た目に合わせて属性を増やすことではありません。
標準HTMLを正しく使い、HTMLだけでは表せない意味や状態をWAI-ARIAで補います。
達成基準4.1.2が求めること
この基準は、UIコンポーネントについて次の三点を求めています。
- 名前と役割をプログラムで判定できること。
- 利用者が変更できる状態、プロパティ、値をプログラムから設定できること。
- それらが変わったとき、ブラウザなどのユーザーエージェントや支援技術が変更を受け取れること。
ここでいう「プログラムで判定できる」とは、見た目を推測しなくても、コードやアクセシビリティAPIを通じて意味を取得できることです。
スクリーンリーダーは、その情報を使って「閉じる、ボタン」「通知音、押されています」のように操作対象を利用者へ伝えます。
名前、役割、値の違い
似た言葉を分けて理解すると、実装時に何を直すべきか判断しやすくなります。
| 項目 | 意味 | 例 |
|---|---|---|
| 名前 | ソフトウェアがコンポーネントを利用者に示すための名称 | 「検索」「閉じる」「ユーザー名」 |
| 役割 | コンポーネントが何として働くか | ボタン、リンク、チェックボックス |
| 状態、プロパティ、値 | 現在の状態や利用者が設定した内容 | 押されている、展開されている、入力された文字列 |
名前は、HTMLのname属性そのものを指す用語ではありません。
画面に見えるラベルと同じ場合もあれば、アイコンボタンのように支援技術へだけ伝える名前の場合もあります。
標準HTMLを優先する
標準のHTML要素には、役割やキーボード操作があらかじめ備わっています。
独自の要素をボタンらしく作り替える前に、button、a、inputなど目的に合う要素を選びます。
入力欄には見えるラベルを関連付ける
label要素のfor属性と入力欄のidを一致させると、「ユーザー名」が入力欄の名前として関連付けられます。
<label for="username">ユーザー名</label>
<input type="text" id="username" name="username">リンクはリンクとして実装する
別のページへ移動する操作には、href属性を持つa要素を使います。
次の例では、リンク文言が名前になり、a要素からリンクという役割が伝わります。
<a href="/contact">お問い合わせ</a>切り替えボタンは状態も伝える
通知音のオンとオフを切り替えるようなボタンでは、ボタンという役割だけでなく、現在の押下状態も必要です。
aria-pressedは切り替えボタンの状態を表すため、操作に合わせてtrueとfalseを更新します。
<button type="button" aria-pressed="false">通知音</button>WAI-ARIAの役割、状態、プロパティを詳しく確認したい場合は、WAI-ARIAの役割と使い方も参照してください。
支援技術に伝わる名前を付ける
名前の付け方は、画面にラベルを表示できるかどうかで選びます。
入力欄では、利用者全員が確認できるlabel要素を基本にします。
閉じるアイコンのように記号だけを表示するボタンでは、aria-labelで目的を補えます。
<button type="button" aria-label="ダイアログを閉じる">×</button>見出しなど、画面上にある別のテキストを名前として使う場合は、aria-labelledbyでその要素のidを参照します。
同じ目的の属性を重ねるのではなく、表示内容と実装に合う方法を一つ選びます。
カスタムUIで起きやすい失敗
divにrole="button"を加えても、標準ボタンと同じ動作にはなりません。
roleが伝えるのは意味であり、フォーカス移動やEnterキーとSpaceキーによる操作は別に実装する必要があります。
通常は、独自のdivを調整するよりbutton要素へ置き換える方が簡潔です。
独自コンポーネントが必要な場合は、名前と役割だけでなく、フォーカス、キーボード操作、状態の更新まで一体として設計します。
| 失敗 | 改善方法 |
|---|---|
| 入力欄に名前がない | labelを入力欄へ関連付ける |
| アイコンボタンの目的が伝わらない | 見えるテキストを置くか、aria-labelで名前を付ける |
divをクリックできるだけでボタンとして使う |
標準のbuttonへ置き換える |
| 見た目だけが押下状態に変わる | 動作と同時にaria-pressedなど該当する状態を更新する |
キーボードで操作できること自体は、4.1.2だけで完結する確認ではありません。
実装全体を点検するときは、WCAG 2.2「2.1.1 キーボード操作」の実装とテストも確認します。
実装後のテスト手順
自動検査だけで終わらせず、操作したときの変化まで手動で確認します。
- 名前と役割を確認する：スクリーンリーダーで、入力欄、リンク、ボタンの名前と役割を聞き取ります。
- キーボードで操作する：Tabキーで対象へ移動し、ボタンをEnterキーとSpaceキーで操作します。
- 状態の変化を確認する：切り替えボタンや開閉部品を操作し、変更後の状態が読み上げられるか確かめます。
- コードと表示を照合する：見た目の変化と
aria-pressedなどの値が一致しているか確認します。 - 自動検査を組み合わせる：axeやWAVEで検出された候補を確認し、手動テストの対象漏れを減らします。
実装時の確認ポイント
- 目的に合う標準HTML要素を最初に選ぶ。
- 各UIコンポーネントに、目的を説明できる名前と正しい役割を持たせる。
- 利用者が変えられる状態や値をコードにも反映し、その変更を支援技術へ伝える。
- カスタムUIは、マウス、キーボード、スクリーンリーダーで実際に操作して確かめる。
4.1.2への対応は、ARIA属性を一律に追加する作業ではありません。
標準HTMLの意味と動作を土台にし、不足する情報だけを補うことが、読み上げと操作のずれを防ぎます。
当社では、ウェブアクセシビリティを導入しやすくするUUU ウェブアクセシビリティを提供しています。
サイトのアクセシビリティ改善を検討している方は、サービスの詳細をご覧ください。