# 何を入力するのか分からない、あいまいなフォームのラベル Source: https://easeweb.dev/learn/descriptive-labels Topics: フォーム > フォームのラベルが、入力する内容を説明している (WCAG 2.4.6) The fix: 表示されているラベルで、何を入力するのかを伝えます。足りない言葉をラベル自体に書き込む（「受け取る人の名前」「送信日」）か、誰の情報かを示すlegendを持つfieldsetの中に短いラベルを置き、日付のようにグループで説明できない欄には、その欄のラベルで名前を付けます。足りない言葉を、スクリーンリーダーにしか届かない場所にだけ置かないでください。 Test with: screen reader References: https://www.w3.org/WAI/WCAG22/Understanding/headings-and-labels.html https://www.w3.org/WAI/WCAG22/Techniques/general/G131 https://www.w3.org/WAI/WCAG22/Techniques/html/H71 https://www.w3.org/WAI/tutorials/forms/grouping/ https://webaim.org/techniques/forms/ よくある問題を再現した学習用のサンプルです。実在のクライアントの診断結果ではありません。コードは出発点となる実装例のため、実際の製品でも確認してください。ここでは支援技術でのテスト結果は報告していません。 ## 場面 ショップのギフトカードのページは、すっきりとデザインされています。カードのプレビューがあり、その横に4つの欄が1列に並びます。ラベルは一語ずつで、「名前」「メール」「日付」「メッセージ」です。デザイナーはカードの横でフォームが軽く見えるよう、ラベルを短くしました。デザイナーにとっては、どの言葉も十分に明らかです。ギフトのフォームなので、名前は受け取る人のものです。 友人にカードを贈ろうとする人は、「名前」を読んで自分の名前を入力します。これまでに入力してきたフォームは、ほとんどが本人の名前を求めていたからです。「メール」にも自分のアドレスを入れるので、カードは友人ではなく自分の受信箱に届きます。「日付」は、送信する日にも、友人の誕生日にも、自分の生年月日にも読め、正しいのは一つだけです。フォームのどこにも、どれなのかは書かれていません。取り違えに最初に気付くのは、確認メールを見たときか、カードを受け取れなかった友人に言われたときです。 同じデザインには、もう一つの実装があります。画面には一語のラベルを残したまま、足りない言葉を、視覚的に隠したspanでスクリーンリーダーにだけ加えるものです。スクリーンリーダーの利用者には「名前（受取人）」と聞こえるようになりますが、画面を読む人には「名前」のままです。 ## 確認できる問題 WCAG 2.4.6（見出し及びラベル）は、見出しとラベルが主題や目的を説明していることを求めています。長いラベルを求めているわけではありません。Understandingのページは、適切な手がかりになるなら、一語でも、一文字でも十分な場合があるとしています。しかし、二人の人物に関わるフォームの「名前」は、どちらの手がかりにもなりません。「日付」は三つの答えに当てはまります。ラベルは存在し、欄と結び付いているので、1.3.1と3.3.2は満たしています。満たしていないのは、言葉そのものです。 隠したテキストを加えても、それは変わりません。WCAGはラベルを、コンポーネントを識別するために利用者に提示されるテキストと定義しています。画面を見る人に提示されているラベルは、「名前」のままです。2.4.6のTrusted Testerのテストは各欄のラベルと説明を確認します。画面に表示されているラベルは、やはり何を入力するのかを伝えていません。 2.4.6は見出しも対象にしています。見出しについては[大きさで選ばれ、構造と合わない見出し](/ja/learn/heading-structure)で扱っています。このガイドは、フォームのラベルについてです。 ## 利用者への影響 推測が最も難しくなるのは、フォームが二人の人物や、同じ種類の二つのものについて尋ねる場面です。ギフトカード、ほかの人のための予約、配送先と請求先の住所、緊急連絡先などです。スマートフォンでは、答えの手がかりになるカードのプレビューがフォームの上か下に押し出されるため、画像から推測できたはずの人にも見えません。 ## 自動チェックとAIの限界 どの欄にもlabel要素が結び付いているので、axe、ANDI、そのほかのラベルのチェックはすべて合格にします。「名前」がこのフォームにふさわしい言葉かどうかは、フォームが何を尋ねているかによるため、判定できるルールはありません。EaseWebの診断は、番号、日付、コードのように、一語ではほとんど足りない言葉だけをラベルにした欄と、legendで区別されずに同じラベルを持つ同じフォーム内の二つの欄を、問題としてではなく、人が読むための手がかりとして報告します。あいまいなラベルの修正をAIのコーディングツールに頼むと、`aria-label="受け取る人の名前"` や隠したテキストを加えることがあり、これは下の二つ目の修正前の例です。スクリーンリーダーには目的が伝わりますが、画面には「名前」とあるままです。 ## 修正前：デザインどおりの一語のラベル ```html
``` どの欄にもラベルがあり、どのラベルも欄と結び付いています。コードは各欄の目的を知っていて、`recipient-name`、`send-date` と書いています。利用者が読むラベルは、「名前」「日付」だけです。 ## 修正前：足りない言葉をスクリーンリーダー用に隠す ```html
``` スクリーンリーダーは「名前（受取人）、編集テキスト」と読み上げますが、画面には「名前」とあるままです。聞くのではなく読んでフォームを使う人は、推測を続けるしかありません。 ## 修正後：足りない言葉を各ラベルに書く ```html
``` 各ラベルは、どこで読まれても、それだけで何を入力するのかを伝えます。画面でも、スクリーンリーダーでも、エラーメッセージ（「受け取る人のメールアドレスを入力してください」）でも、音声操作（「受け取る人のメールアドレスをクリック」）でもです。デザインは1列のレイアウト、書体、余白をそのまま保ちます。ラベルは少し長くなりますが、スマートフォンの幅でも1行に収まります。「メッセージ」は元のままです。ギフトのフォームで、メッセージが指すものは一つしかありません。 ## 修正後：誰の情報かを示すlegendの下に短いラベル ```html
贈る相手
``` こちらは見た目が変わります。名前とメールの上に小さな見出し「贈る相手」が付き、その下の二つのラベルは一語のままです。見出しはfieldsetの `legend` なので、画面の上だけでなくコードの上でも両方の欄に属し、スクリーンリーダーは欄と一緒に読み上げます。一度だけ読むものも、欄ごとに読むものもあり、まったく読まないものはまれです。日付はグループの外にあり、どの日付かを説明できる見出しもないので、ラベルで名前を付けます。スクリーンリーダーが見出しを欄と一緒に読み上げるのは、見出しが欄を囲む `fieldset` の `legend` である間だけです。fieldsetの外に置いた、同じ見た目の見出しは、欄の上に見えていても、欄と一緒には読み上げられません。 ## どの方法を選ぶか どちらも2.4.6を満たします。言葉は各ラベルに書いてください。余分な構造なしに同じ役割を果たし、ラベルは周りから切り離されても持ち運ばれる唯一のテキストだからです。エラーの一覧、入力内容の確認ページ、音声操作は、上の見出しを含めず、欄自身のラベルだけを使います。そこでも「受け取る人のメールアドレス」は明確なままで、「メール」はそうではありません。legendは、ギフトのフォームが贈り主の名前とメールアドレスも尋ねる場合や、配送先と請求先の住所のように、同じことを二人の人物や二つの場所について尋ねるフォームで使います。すべてのラベルの前に「受け取る人の」「あなたの」と付けると、フォームが重くなるからです。その場合は、エラーメッセージと確認ページに、グループの言葉を自分で書き加えてください。どちらの方法でも、日付のように、どのグループにも説明されない欄には、その欄自身の言葉が必要です。隠したテキストと `aria-label` は、三つ目の方法ではありません。スクリーンリーダーには届きますが、画面は元のままです。 ## 実装の判断 受け取る人の欄は、フォームに入力している本人についての欄ではないので、`autocomplete="name"` や `autocomplete="email"` は付けません。付けると、ブラウザーがそこに購入者自身の情報を提案し、あいまいなラベルと同じ取り違えを起こします。1.3.5がこれらの値を求めるのは、利用者自身の情報を集める欄だけです。[自動入力が効かないフォームの入力欄](/ja/learn/autocomplete)を参照してください。 ラベルには欄が何かを書き、形式はヒントに書きます。「送信日」はどの日付かを伝えます。入力の仕方は、欄がHTML標準の日付入力でなければ、ラベルの下の一行に書き、`aria-describedby` で欄と結び付けます。プレースホルダーはどちらにも向きません。入力を始めた途端に消えるからです。 legendはその中の欄と一緒に読まれ、スクリーンリーダーによっては欄ごとに繰り返します。「贈る相手」のように数語にとどめ、説明の文にはしないでください。長い案内はグループの前の段落に書き、そこで必要なら `aria-describedby` で最初の欄と結び付けます。 共通の入力欄コンポーネントでは、ラベルはプロパティの一つで、コードレビューは中身にかかわらず通します。ラベルの言葉はコンテンツと一緒にレビューし、各欄に何を入れるかのメモをコンポーネントを使う場所の近くに残してください。次にフォームを編集する人が、ラベルがまだ合っているかを判断できます。 ## 修正の確認 1. カードのプレビューや見出しを見ずに、表示されている各ラベルを、legendがあればそれと合わせて読み、何を入力するかを書き出して、フォームが求める内容と比べる。 2. フォームの中で二つの欄が同じラベルを持っていないか確認する。ある場合は、それぞれが別のlegendを持つfieldsetの中にあるか確認する。 3. スクリーンリーダーでTabキーを押してフォームを移動し、フォーム欄の一覧も開いて、各欄が何を入力するのかが分かる言葉で読み上げられ、同じ言葉が画面にもあるか確認する。 4. フォームを見たことがない人に、架空の友人へ贈るつもりで入力してもらい、すべての値が意図した欄に入るか確認する。 OS、ブラウザーと支援技術のバージョン、ビルド、実施日、各手順の実際の結果を記録してください。欄を追加したとき、ラベルを変えたとき、フォームを翻訳したときは、再度確認します。 ## 制限 このサンプルは、どのアプリケーションでも同じ結果になることを保証するものではありません。扱っているのはラベルの言葉で、ラベルがあるか、欄と結び付いているか（[ラベルがない・表示と食い違うフォームの入力欄](/ja/learn/form-labels)）、必須項目の示し方（[色だけで示された必須項目](/ja/learn/required-fields)）、ラベルのほかに欄が必要とするヒントや形式は扱っていません。ラベルが明確かどうかは、フォームを使う人と、その人がすでに知っていることによって変わります。フォームを提供するすべての言語で、実際に使う人と一緒に確認してください。 --- このガイドをコーディングエージェントで使う: MCP https://easeweb.dev/mcp（設定は https://easeweb.dev/ja/services/developers）