WCAG 3.3.2: ラベルまたは説明文

WCAG 3.3.2 は、コンテンツがユーザー入力を必要とする場合にはラベルまたは指示を提供することを求めており、能力に関わらずすべてのユーザーがフォームデータを送信する前に、自分に何が求められているかを理解できるようにしています。フォームフィールドにラベルを付けないことは、ウェブ上で最も一般的で影響の大きいアクセシビリティ上の障壁の1つです。

このルールの意味

WCAG 達成基準 3.3.2 — ラベルまたは説明（レベル A）では、「コンテンツがユーザー入力を必要とする場合、ラベルまたは説明が提供されている。」と定められています。実務的には、ユーザーに情報の入力や選択を求めるあらゆるフォームフィールド、入力コントロール、テキストエリア、select 要素には、ユーザーが操作する前にそのフィールドの目的が明確になるような、目に見える意味のあるラベル、または一連の説明が必要です。

この達成基準は意図的に広い範囲を対象としています。ユーザーがデータを提供するあらゆる仕組みが対象であり、すべてのタイプの <input> 要素（text、email、password、number、date、checkbox、radio、file upload）、複数行テキスト用の <textarea> 要素、<select> ドロップダウンが含まれます。また、role='combobox' や role='listbox' のような ARIA ロールで構築されたカスタムインタラクティブコントロールにも適用されます。

ラベルは、この達成基準を満たすいくつかの方法で提供できます。最も堅牢なのは、視覚的に表示され、対応する for/id の組み合わせでコントロールと関連付けられた、プログラム的に関連付けられた <label> 要素です。別の方法として、既存の要素を参照する aria-labelledby を使って可視のラベルテキストを関連付けたり、aria-describedby で補足的な説明を結び付けることもできます。重要な要件は、ラベルまたは説明が提供されていること、つまりユーザーが知覚できる形で存在していることです。プレースホルダーテキストだけでは、この達成基準を満たしません。なぜなら、ユーザーが入力を始めるとすぐに消えてしまい、すべての支援技術が永続的なラベルとして確実に伝達してくれるわけではないからです。

適合（pass）とみなされるには、各入力に、目に見える（少なくともプログラム的に判別可能な）ラベルがあり、ユーザーがそのフィールドの入力を始める前に存在していて、どのようなデータが求められているかを伝えるのに十分な説明性がある必要があります。不適合（fail）となるのは、フィールドにラベルがまったくない場合、プレースホルダー属性だけが唯一のラベルである場合、ラベルが視覚的には存在するがプログラム的に関連付けられていない場合、または（「日付を DD/MM/YYYY 形式で入力してください」のような）必須の形式に関する説明がまったくない場合です。

WCAG では、狭い例外も示しています。フォームに単一の明らかに分かりやすいフィールドしかない場合 — たとえば、すぐ隣に明確にラベル付けされた送信ボタンがあるサイト全体の検索バーなど — は、そのコンテキスト自体が十分な説明を提供しているとみなされることがあります。ただし、この例外は非常に限定的であり、複数フィールドのフォームでラベルを省略する一般的な根拠として用いるべきではありません。

なぜ重要か

フォームラベルは、幅広いユーザーにとって最も影響力の大きいアクセシビリティ機能です。ラベルがないと、多くの人にとって取引の完了、サービスへの登録、組織への連絡が不可能になるような障壁が生じます。

スクリーンリーダーに依存する視覚障害およびロービジョンのユーザーにとって、ラベルのないフィールドは「編集テキスト」や「空白」といった形でしか読み上げられず、文脈がありません。ユーザーはそこに氏名、メールアドレス、クレジットカード番号のどれを入力すべきか知る手がかりを持てません。世界保健機関（WHO）によると、世界で約 22 億人が何らかの視覚障害を抱えており、そのうち何百万人もの人がウェブとの主なインタラクション手段としてスクリーンリーダーを利用しています。

認知・学習障害（ディスレクシア、ADHD、記憶に関連する障害など）のあるユーザーにとって、プレースホルダーテキストは特に有害です。プレースホルダーはフォーカスや入力時に消えてしまうため、フォーム入力の途中で一息ついたユーザーは、すでに入力を始めたフィールドに何が求められていたのかを参照できません。そのため、説明を読み直すためにフィールドをクリアしなければならず、混乱とフラストレーションを招きます。永続的で可視のラベルは、この認知的負担を完全に取り除きます。

キーボード、スイッチデバイス、音声コントロールで操作する運動障害のあるユーザーにとって、ラベルは追加の役割も果たします。Dragon NaturallySpeaking のような音声コントロールソフトウェアでフィールドを起動する際に使う発話テキストを提供するのです。可視ラベルテキストがプログラム的なアクセシブルネームと一致していない場合、音声コマンドは何のエラーもなく失敗します。

具体的な現実のシナリオを考えてみましょう。ロービジョンのユーザーが、トルコの公的機関ポータルで政府給付の申請を行っています。このフォームはラベルの代わりにプレースホルダーテキストを使用しています。ユーザーが画面を 200% に拡大して読むと、プレースホルダーは読み終える前に消えてしまいます。ユーザーは推測でフィールドを埋めて送信しますが、どのフィールドが間違っているのか示されない一般的なエラーメッセージしか受け取りません。このシナリオは、重要な公共サービスからの排除につながりますが、完全に防ぐことが可能です。

アクセシビリティの観点だけでなく、ラベル付きフォームはSEOの向上にもつながります。検索エンジンのクローラーがフォームの目的をよりよく理解できるようになるためです。また、すべてのユーザーのユーザビリティも向上します。特にモバイルデバイスでは、小さなタッチターゲットに対して、関連する入力のアクティベーション領域を広げるタップ可能なラベル領域が役立ちます。

テスト方法

axe DevTools または Lighthouse による自動スキャン: Chrome または Firefox でフォームを含むページを開きます。axe DevTools ブラウザー拡張機能を実行し、label、select-name、textarea-label のルールで結果をフィルタリングします。フラグが立ったすべての要素を記録します。二次チェックとして Google Lighthouse（アクセシビリティ監査）を実行します。すべての違反をエクスポートするかスクリーンショットを保存します。自動レポートがクリーンであっても適合が保証されるわけではないことを念頭に置き、手動ステップに進んでください。
目視による確認: 支援技術を使わずに、ページ上のすべてのフォームフィールドを確認します。各フィールドに、プレースホルダーだけでなく、目に見える静的なラベルがあり、フィールドの近く（通常は上または左）に明確に配置されていることを確認します。「パスワードは 8 文字以上である必要があります」のような形式要件が、送信失敗後だけでなく、入力前または入力時に表示されていることを確認します。必須フィールドが色だけで識別されていないことも確認します。
キーボードナビゲーションテスト: Tab キーでフォームのすべてのフィールドを移動します。各フィールドにフォーカスが当たったとき、その目的が可視ラベルから即座に分かることを確認します。キーボードで到達できるのに、その時点で隣接する永続的なラベルが見えないフィールドがあってはなりません。
NVDA と Firefox を用いたスクリーンリーダーテスト: NVDA を起動した状態でフォームを開きます。Tab キーで各インタラクティブコントロールを移動します。NVDA はラベル、ロール（例：「編集」「コンボボックス」）、状態（例：「必須」）を読み上げる必要があります。ロールと状態だけでラベルを読み上げない場合、そのフィールドは不適合です。NVDA のフォームモード（インタラクティブ要素で自動的に起動）を使って、現実的なユーザーのナビゲーションをシミュレートします。
VoiceOver と Safari（macOS/iOS）を用いたスクリーンリーダーテスト: VoiceOver を有効にします（Mac では Command + F5）。Tab キーまたはスワイプで各フォームフィールドに移動します。VoiceOver はロールの前にラベルを読み上げる必要があります。iOS では、各フィールドをタップし、キーボードが表示される前にラベルが読み上げられることを確認します。プレースホルダーのみのフィールドは、最初のフォーカス時にはプレースホルダーが読み上げられますが、テキストが入力されると無音になることが一般的です。
JAWS と Chrome を用いたスクリーンリーダーテスト: JAWS を起動し、Tab キーでフォームを移動します。JAWS のフォームモードを使用します。各フィールドの読み上げられる名前が可視ラベルと正確に一致していることを確認します。JAWS の Insert + F1（フィールドヘルプ）を使って、aria-describedby による追加説明があるかを確認します。
Dragon NaturallySpeaking を用いた音声コントロールテスト: Dragon を起動し、可視ラベルを発話して各フィールドを操作できるか試します。発話したラベルがプログラム的なアクセシブルネームと一致していない場合、そのフィールドは音声コマンドに反応せず、3.3.2 および関連する達成基準の不適合を示します。

修正方法

テキスト入力にラベルがない — 不適切な例

<!-- ラベルが提供されておらず、プレースホルダーだけが手がかり -->
<input type='text' name='email' placeholder='Email address' />

テキスト入力にラベルがない — 適切な例

<!-- 可視の <label> を for/id の組み合わせで関連付ける。
     プレースホルダーは補足的なヒントとして使用してもよいが、
     ラベルが主要で永続的な識別子となる。 -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

ラベルのない select ドロップダウン — 不適切な例

<!-- ラベルがないため、スクリーンリーダーは選択中のオプション値だけを読み上げる -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

ラベルのない select ドロップダウン — 適切な例

<!-- プログラム的に関連付けられたラベルにより、
     ユーザーがドロップダウンを開く前にフィールドの目的が明確になる。 -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

ラベルのない textarea — 不適切な例

<!-- textarea にラベルがない。周囲の段落テキストは
     プログラム的に関連付けられておらず、スクリーンリーダーは
     それをフィールドのラベルとして読み上げない。 -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

ラベルのない textarea — 適切な例

<!-- aria-labelledby を使って既存の可視見出しを
     textarea と関連付けるか、あるいは <label> 要素で囲む。 -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

日付フィールドに形式の説明がない — 不適切な例

<!-- ラベルはあるが期待される日付形式の説明がない。
     ユーザーは 01/06/2025 と入力すべきか 2025-06-01 と入力すべきか推測するしかない。 -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

日付フィールドに形式の説明がある — 適切な例

<!-- 形式の説明が可視であり、aria-describedby で関連付けられているため、
     フィールドにフォーカスが当たるとスクリーンリーダーが説明を読み上げる。 -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

よくある間違い

placeholder を唯一のラベルとして使うこと: プレースホルダーテキストは入力時に消え、すべてのスクリーンリーダーがラベルとして確実に読み上げるわけではなく、参照テキストを必要とする認知障害のあるユーザーにとって不利になります。プレースホルダーに加えて、必ず可視の <label> を提供してください。
プログラム的な関連付けなしに、ラベルをフィールドの近くに視覚的に配置するだけにすること: 入力の上に配置された <p> や <span> は、晴眼者にはラベルのように見えますが、スクリーンリーダーには無視されます。<label for='id'>、aria-labelledby を使用するか、入力を <label> 要素内にラップしてください。
可視ラベルと一致しないテキストで aria-label を使用すること: プログラム的なアクセシブルネームが可視テキストと異なる場合、音声コントロールユーザーは画面上で読んだテキストを発話してもフィールドを起動できず、SC 2.5.3（Label in Name）に違反するだけでなく、スクリーンリーダーユーザーにも混乱を招きます。
ラジオボタンのグループにラベルを付けても、グループの legend を省略すること: 個々のラジオボタンにはオプションテキストでラベルが付いていても、「支払い方法」のような全体の質問が <fieldset> と <legend> で提供されていない場合、キーボードでナビゲートするユーザーは、何を選択しているのか分からないまま各オプションを個別に聞くことになります。
必須フィールドを色やアスタリスクだけで識別すること: ラベルの横のアスタリスク（*）は、その意味が説明されていない限り（例：「* が付いているフィールドは必須です」とフォーム上部に記載する）、スクリーンリーダーユーザーには何も伝えません。また、必須フィールドには required または aria-required='true' 属性も付与する必要があります。
送信失敗後まで形式の説明を表示しないこと: パスワードのルールや日付形式の要件を送信後のエラーメッセージでのみ表示すると、ユーザーは何が期待されているかを知る前に必ず一度は間違えなければならなくなります。説明は、ユーザーがフィールドを操作する前または操作時に提示されなければなりません。
display:none や visibility:hidden を使ってラベルを非表示にすること: これらの CSS プロパティは、ラベルをアクセシビリティツリーから完全に削除します。ラベルを視覚的に非表示にする必要がある場合（ミニマルなデザインなど）、要素をアクセシビリティツリーに残したまま画面外に移動させる「視覚的非表示」用の CSS クラスを使用してください。
title 属性だけをラベルとして使い、それで十分だと考えること: axe-core は title のみのラベルにフラグを立てないかもしれませんが、title 属性はホバー時のツールチップとしてのみ表示され、キーボードユーザーやモバイルユーザーにはアクセスできません。title は補足的な説明として使用し、主要なラベルとして使うべきではありません。
コンテナの <div> に単一の aria-label を適用し、それが子入力をラベル付けすると期待すること: コンテナ要素に付与された ARIA ラベルは、その子フォームコントロールには継承されません。各インタラクティブコントロールは個別にラベル付けする必要があります。
動的コンテンツ更新後にラベルの関連付けをやり直さないこと: JavaScript でフォームフィールドを動的に挿入する場合（例：住所行の追加）、開発者が可視ラベルテキストだけを兄弟要素として追加し、適切な for/id のバインディングを行わないために、新しく挿入された入力にラベルが関連付けられていないことがよくあります。

トルコのアクセシビリティ規制との関係

トルコの大統領通達 2025/10は、2025 年 6 月 21 日付官報第 32933 号で公布され、WCAG 2.2 に整合した必須のウェブアクセシビリティ要件を定めています。WCAG 達成基準 3.3.2 — ラベルまたは説明はレベル Aの要件であり、適合のベースラインに位置し、この通達の下で最も厳格に適用される規定の一つです。

この通達は幅広い主体を対象としており、遵守期限はセクターによって異なります。公的機関（省庁、自治体、国家機関、公的資金による組織を含む）は、通達の公布から1 年以内にレベル A の完全な適合を達成しなければなりません。対象となる民間部門の事業者は、2 年以内に遵守する必要があります。明示的に対象とされている民間事業者には、e コマースプラットフォーム、銀行および金融機関、病院および民間医療提供者、20 万人以上の加入者を持つ通信会社、旅行代理店、民間交通事業者、国民教育省（MoNE）に認可された私立学校が含まれます。

これらすべての主体にとって、フォームフィールドにラベルを付けないことは単なるユーザビリティの問題ではなく、直接的な規制違反にあたります。フォームは、対象となるすべてのデジタルサービスに広く存在します。市民は政府ポータルで申請を行い、患者は病院のウェブサイトで予約を取り、顧客は e コマースプラットフォームで購入手続きを完了し、学生は学校ポータルから登録します。これらすべての利用経路はフォームに依存しており、そのフォーム内のラベルのないあらゆるフィールドは、監査人が文書化し報告できる明確な WCAG 3.3.2 違反となります。

通達の対象となる組織は、SC 3.3.2 への適合を、あらゆるアクセシビリティ監査や認証プロセスの前提条件として扱うべきです。これはレベル A の達成基準であるため、免除や先送りは認められません。レベル A 項目を除外した部分的な適合主張は認められないのです。公開されているすべてのフォームでラベル付き入力を示せない主体は、規制上の指摘、公表される不適合報告、そしてインクルーシブデザインとますます結び付けられているデジタルトラストの観点から評判リスクを負うことになります。

実務的な観点から見ると、3.3.2 への適合を達成することは、組織が取り得る施策の中でも最小の労力で最大の効果をもたらすものの一つです。既存のフォームコントロールにラベルを関連付けるには、通常、わずかな HTML の変更だけで済み、正しく実装すればビジュアルデザインには影響しません。Accsible のオーバーレイ SDK を利用している組織であれば、ラベル欠如の自動検出により、定期的なスキャンの中でこれらの違反を表面化させ、規制期限が到来する前に開発チームに実行可能な是正ガイダンスを提供できます。

出典と参考資料

AWCAG 1.1.1: 非テキストコンテンツ AWCAG 1.2.1: 音声のみおよび映像のみ（事前録画）AWCAG 1.2.2: キャプション（事前録画）