お問い合わせフォームのアクセシビリティ｜ラベル・キーボード・エラーの確認

お問い合わせフォームは、マウスだけでなくキーボードや読み上げを使う人にも、何を入力し、どう修正すればよいかが伝わる必要があります。ラベル、選択肢のまとまり、フォーカス、エラーを順に確認すると、見た目だけでは気づきにくい問題を見つけられます。

この記事は制作時の基本点検をまとめたものです。ここに挙げた確認だけで、特定のアクセシビリティ基準への適合を保証するものではありません。

入力欄とラベルを関連付ける

項目名を近くに表示するだけでなく、入力欄とプログラム上でも関連付けます。例えばlabelのforと入力欄のidを一致させます。プレースホルダーは入力すると消えるため、常に見える項目名の代わりにしないようにします。

<label for="contact-email">メールアドレス（必須）</label>
<p id="email-help">返信を受け取れるアドレスをご入力ください。</p>
<input id="contact-email" name="email" type="email"
  autocomplete="email" required aria-describedby="email-help">

これは入力欄の構造例で、メール送信処理を含む完成フォームではありません。ラベルの付け方はW3CのLabeling Controlsを参照してください。

ラジオボタンには、質問のまとまりを付ける

「メール」「電話」という選択肢だけでは、何の方法を選ぶのか分かりにくい場合があります。関連する選択肢をfieldsetでまとめ、legendで「希望する連絡方法」などの質問を示します。各選択肢にもそれぞれラベルが必要です。

複数の質問で同じ「はい・いいえ」を使う場合は、特にまとまりが重要です。具体的な構造はW3CのGrouping Controlsで確認できます。装飾のために標準の選択要素を独自部品へ置き換えると、操作や状態の通知も自分で実装する範囲が増えます。

キーボードだけで完了まで進む

マウスを使わず、Tabキーで入力欄とボタンを移動します。現在の操作位置が分かる表示を残し、画面上の順序と移動順が大きく食い違わないか確認します。リンクやボタンの見た目を整える際も、フォーカスの輪郭を単純に消さないでください。

• すべての必要な入力欄とボタンへ移動できるか。
• 選択肢をキーボードで変更できるか。
• 確認画面から戻る操作ができるか。
• 固定ヘッダーやバナーが操作位置を覆わないか。
• モーダルなどの中で操作が行き詰まらないか。

エラーの場所と直し方を文章で伝える

赤い枠だけでは、どの項目がどう間違っているか十分に伝わりません。「メールアドレスを入力してください」のように対象と修正方法を示します。エラー文と入力欄の関連付けや、エラー時のフォーカス移動も設計します。

動的に追加される通知は、読み上げを使う人にも伝わる仕組みが必要です。ただし、入力のたびに長い文章を読み上げ続ける状態は避けます。W3CのUser Notificationを参考に、エラー時と完了時の通知を確認してください。

拡大表示と実際の読み上げでも確認する

ブラウザーで拡大した際に、項目名や補足文が切れていないかを確認します。画面幅を狭くした場合も、文章を読むために左右へ何度も移動しなくてよい構成を目指します。文字数の多い選択肢も試してください。

読み上げでは、項目名、必須であること、選択肢の質問、エラーの内容が把握できるかを確認します。自動検査だけでは入力の意味や操作の自然さまで判断できないため、実際に一件入力する確認を組み合わせます。

テンプレートを変更した後にも点検する

元のフォームに関連付けがあっても、項目を複製して同じidを残すと関係が崩れます。文言の変更、項目の追加、CSSの変更後は再確認しましょう。

FreelanceFormのデザイン見本を使う場合も、変更後の完成ページを点検します。デザイン全般は入力しやすいフォームの作り方、公開前の確認は納品前チェックリストと合わせて進めてください。