WCAG 2.2の達成基準2.4.6「見出しとラベル」は、見出しやラベルが、その先にある内容や操作の目的を説明しているかを評価するLevel AAの基準です。
明確な文言があれば、利用者は本文をすべて読まなくてもページの構成をつかみ、必要な情報や入力欄を見つけやすくなります。
WCAG 2.2の全体像を確認したい場合は、基準の構成と実務への取り入れ方を先に押さえると理解しやすくなります。
達成基準2.4.6が評価する内容
見出しとは、直後の節で扱う話題を示す短い文言です。
ラベルとは、入力欄や選択肢などの目的を利用者に伝える文言です。
この基準が直接問うのは、配置された見出しやラベルの文言が内容や目的を説明しているかどうかです。
| 対象 | 曖昧な文言 | 内容が伝わる文言 |
|---|---|---|
| 見出し | 方法1 | 電話でのお問い合わせ |
| 見出し | セクション1 | 製品の特徴 |
| 入力欄のラベル | 入力 | メールアドレス |
短い文言でも、利用者が次の内容や求められる操作を予測できれば目的を果たせます。
内容を特定できる見出しにする
見出しだけを順に読んだときに、ページの構成が分かる文言を選びます。
「方法1」「方法2」のような番号だけの見出しでは、本文を読むまで違いが分かりません。
改善前の例
<h1>お問い合わせ</h1>
<section>
<h2>方法1</h2>
<p>電話番号はこちらです。</p>
</section>
<section>
<h2>方法2</h2>
<p>メールフォームをご利用ください。</p>
</section>改善後の例
<h1>お問い合わせ</h1>
<section>
<h2>電話でのお問い合わせ</h2>
<p>電話番号はこちらです。</p>
</section>
<section>
<h2>メールでのお問い合わせ</h2>
<p>メールフォームをご利用ください。</p>
</section>改善後は、利用者が本文を開く前に二つの問い合わせ方法を区別できます。
入力欄とラベルを正しく関連付ける
フォームでは、ラベルの文言だけでなく、そのラベルがどの入力欄を説明しているかも明確にします。
HTMLでは、見えるラベルを用意し、label要素のfor属性と入力欄のidを同じ値にする方法が基本です。
<form>
<label for="name">お名前</label>
<input type="text" id="name" name="name">
<label for="email">メールアドレス</label>
<input type="email" id="email" name="email">
<button type="submit">送信</button>
</form>この関連付けにより、支援技術は入力欄と説明を対応させやすくなり、ラベルをクリックしたときにも対応する入力欄へフォーカスを移せます。
フォーム全体の設計は、フォームの入力支援とエラー設計も併せて確認すると、入力から送信までの改善点を整理できます。
プレースホルダーだけで済ませない
placeholderは入力例や短い補足には使えますが、ラベルの代わりにはなりません。
入力を始めると文言が消えるため、利用者が入力中に目的や条件を確認しにくくなるからです。
ARIAは対象の入力欄に設定する
見えるラベルを置けない場合には、aria-labelで入力欄に名前を付ける方法があります。
<input type="search" id="site-search" name="q" aria-label="サイト内検索">aria-labelは、入力欄を囲むdiv要素ではなく、名前を付けたい入力欄そのものに設定します。
ただし、画面上に説明が必要な場面では、見えるlabel要素を優先した方が多くの利用者に目的が伝わります。
入力条件はラベルと分けて伝える
パスワードの文字数などの入力条件は、利用者が入力中にも確認できる位置へ表示します。
条件を別の要素に置く場合は、aria-describedbyで入力欄と説明を関連付けられます。
<label for="password">パスワード</label>
<input type="password" id="password" name="password" aria-describedby="password-help">
<p id="password-help">8文字以上で入力してください。</p>ラベルは入力欄の目的を示し、補足文は入力条件を示すため、二つの役割を区別できます。
よくある失敗と修正方法
| 失敗 | 起きる問題 | 修正方法 |
|---|---|---|
| 「詳細」「項目1」などの見出し | 見出しだけでは内容を予測できない | 節の話題を具体的に書く |
| プレースホルダーだけの入力欄 | 入力後に目的や条件を確認しにくい | 見えるラベルを入力欄に関連付ける |
周囲の要素にだけaria-labelを設定 |
入力欄自体の名前にならない | 対象の入力欄に設定する |
| 見出しと本文の内容が一致しない | 利用者の予測と実際の情報がずれる | 本文の主題に合わせて見出しを直す |
見出しとラベルのテスト方法
人が文脈を確認する
- 見出しだけを一覧にし、各節の内容を予測できるか確認します。
- 入力欄や選択肢ごとに、目的を説明するラベルが見えるか確認します。
- ラベルと入力欄の対応が一意になっているか確認します。
- 入力条件や形式が、入力中にも確認できるか確認します。
支援技術で読み上げを確認する
スクリーンリーダーで見出し間を移動し、見出しだけでもページ内の位置を判断できるか確認します。
フォームでは各入力欄へ移動し、目的を表すラベルと必要な補足が読み上げられるか確認します。
読み上げ環境の基本は、スクリーンリーダーの仕組みと実装ポイントで解説しています。
自動テストは確認範囲を分ける
AxeやWAVEなどの自動テストツールは、ラベルの欠落や関連付けの問題を見つける補助になります。
一方で、見出しやラベルの文言が本文の内容を適切に説明しているかは、文脈を読んだ人が判断する必要があります。
実装時のチェックリスト
- 見出しだけを読んでも各節の話題が分かる
- 同じ階層の見出しが、同程度の具体性で書かれている
- 入力欄と選択肢に目的の分かるラベルがある
labelのforと入力欄のidが一致している- プレースホルダーだけに目的や入力条件を任せていない
- ARIA属性が、説明したい要素そのものに設定されている
- 自動テストに加えて、目視と支援技術で確認している
達成基準2.4.6への対応では、短さだけを求めず、見出しやラベルを読んだ利用者が次の内容や操作を予測できるかを基準に文言を決めます。
Webアクセシビリティの導入や改善を検討している方は、当社のUUU ウェブアクセシビリティもご覧ください。