ウェブアクセシビリティに配慮したフォームの作り方！ Web制作者が最低限チェックすべき9つのポイント

“お問い合わせ” “資料請求” “お申し込み”…
フォームはユーザーが情報を入力し、サービスや企業と繋がるための重要な接点です。

しかし、フォームの設計や実装にアクセシビリティへの配慮が欠けていると、スクリーンリーダー（テキストを読み上げる機能）などの支援技術を利用して閲覧しているユーザーが利用できないだけでなく、「入力しづらい」「エラーが分かりにくい」といった “使いづらいフォーム” になってしまいます。
その結果、せっかくフォームに辿り着いたのに途中で入力を諦めて離脱してしまう可能性が高まってしまいます。

これではコンバージョンに悪影響を及ぼすほか、顧客が離れてしまう原因にもなり、企業やサービスにとって機会損失にもなりかねません。

そこで今回はウェブアクセシビリティに配慮したフォームを作る際に、最低限チェックすべき9つのポイントを整理し、実務で役立つ知識を紹介していきます！

最低限チェックすべき9つのポイント

①ラベルと入力フィールドの関連付け

フォームの入力フィールドには、必ず「何を入力するためのフィールドなのか」を示すラベルの設置が必要です。
ラベルと入力フィールドを正しく関連付けることで、視覚的に分かりやすいだけでなく、スクリーンリーダーなどの支援技術にも情報が正しく伝えられるようになります。

❌ NG例

<!-- ❌ NG例：ラベルがなくプレースホルダーだけ -->
<input type="text" name="name" placeholder="お名前を入力してください">

✅ OK例

<!-- ✅ OK例：ラベルを明示し、入力フィールドと関連付け -->
<label for="name">お名前</label>
<input id="name" type="text" name="name" placeholder="例：山田太郎">

②プレースホルダーをラベル代わりに使用しない

先述のラベルに関する補足になりますが、ラベルは使用せず、プレースホルダーで代用することは控えましょう。プレースホルダーはあくまでも入力例や入力フィールドに対する補助的なヒントを提示するための仕組みであり、ラベルの代わりにはなりません。

プレースホルダーをラベルとして使用してしまうと、入力中に消えて見えなくなってしまったり、スクリーンリーダーで適切に読み上げられなかったりと、ユーザーに混乱を与える原因になります。
また、プレースホルダーの文字色は一般的に薄く表示されるため、背景とのコントラスト比が不足し、視認性が大きく低下する場合もあります。

そのため、プレースホルダーはあくまで「補助的な情報の提示」として活用し、入力フィールドの内容を伝えるラベルを必ず別に設置することが重要です。

③必須項目の明示

入力フィールドが必須項目なのか任意項目なのか、ユーザーに明確に伝えることが非常に重要です。
NG例として最も多く散見されるのが必須項目を赤色の「※」などマークだけで示しているものです。

単に色分けしただけでは一目で必須項目だと分からないので見落とされる可能性があったり、色の違いが識別しにくいユーザーには区別がつきません。

また、スクリーンリーダーでは「※」が記号として読み上げられるだけで、それが必須項目であることが正しく伝わらないという問題もあります。

そのため、required属性（入力フィールドが必須項目であることをブラウザに伝える）などを用いてプログラム的にも必須項目であることを示し、あわせてテキストでも「必須」などと明記することが大切です。

❌ NG例

<!-- ❌ NG例：赤色や※マークだけで必須を表現 -->
<label for="email">メールアドレス<span style="color:red;">※</span></label>
<input id="email" type="email" name="email">

✅ OK例

<!-- ✅ OK例：required属性とテキストで必須を明示 -->
<label for="email">メールアドレス（必須）</label>
<input id="email" type="email" name="email" required>

④エラーメッセージの適切な提示

必須項目の明示と同様、ユーザーが入力を間違えたときに入力フィールドの色を変えるだけでは、多くの人にとって何が問題になっているのか分かりにくく、支援技術を使うユーザーにも伝わりません。

入力エラーの場合は「どこが間違っているのか」「どう直せばいいのか」をテキストで具体的に提示して入力フィールドと関連付ける必要があります。

⑤ラジオボタン / チェックボックスのグループ化

ラジオボタンやチェックボックスのように複数の選択肢がある場合、それらをひとまとまりの質問として示すことが重要です。単なるdivタグやpタグでinputタグを囲むだけでは、支援技術を使用しているユーザーにはどの設問に対する選択肢なのか伝わりません。

fieldsetタグやlegendタグ（複数の入力フィールドをひとつの質問としてグループ化するためのHTMLタグ）を正しく使うことで、選択肢がどんな設問に属しているのかを明確に示すことができます。

❌ NG例

<!-- ❌ NG例：divタグで囲んでいるだけ -->
<div>
  <p>好きなフルーツを選んでください</p>
  <input type="checkbox" id="apple" name="fruit" value="apple">
  <label for="apple">りんご</label>
  <input type="checkbox" id="orange" name="fruit" value="orange">
  <label for="orange">オレンジ</label>
  <input type="checkbox" id="banana" name="fruit" value="banana">
  <label for="banana">バナナ</label>
</div>

✅ OK例

<!-- ✅ OK例：fieldset と legend でグループ化 -->
<fieldset>
  <legend>好きなフルーツを選んでください</legend>
  <input type="checkbox" id="apple-ok" name="fruit" value="apple">
  <label for="apple-ok">りんご</label>
  <input type="checkbox" id="orange-ok" name="fruit" value="orange">
  <label for="orange-ok">オレンジ</label>
  <input type="checkbox" id="banana-ok" name="fruit" value="banana">
  <label for="banana-ok">バナナ</label>
</fieldset>

⑥キーボードから利用できるようにする

マウス操作だけでなく、キーボードだけを使う場合でもスムーズに操作できるように配慮する必要があります。
目の不自由なユーザーや、病気や怪我によって一時的にマウス操作が難しいユーザーにとって、キーボード操作が唯一の手段となることもあるからです。
Tabキーでの項目移動が容易で、EnterやSpaceでボタンを押せるようにすることが基本になってくるのでセマンティックなコーディングを心がけましょう。
また、tabindexを乱用してキーボード操作の移動順を無理に制御すると、画面上の表示順と実際の移動順が一致せず、ユーザーに混乱を与えてしまいます。
そのため、不自然な制御は避け、マークアップの順序通りに移動できるようにすることが大切です。

❌ NG例

<!-- ❌ NG例：tabindexを誤用し、divでボタンを作成 -->
<label for="name">名前</label>
<input type="text" id="name" name="name" tabindex="2">
<label for="email">メールアドレス</label>
<input type="email" id="email" name="email" tabindex="1">
<div class="btn">送信</div>
<!-- 入力順序が逆になり、送信ボタンはTab移動やEnter/Spaceで操作できない -->

✅ OK例

<!-- ✅ OK例：自然な順序に従い、button要素を使用 -->
<label for="name-ok">名前</label>
<input type="text" id="name-ok" name="name">
<label for="email-ok">メールアドレス</label>
<input type="email" id="email-ok" name="email">
<button type="submit">送信</button>
<!-- 順序通りにTab移動でき、送信ボタンもEnterやSpaceで操作可能 -->

⑦フォーカスの可視化

キーボード操作でフォームを利用する際は、どの入力フィールドにフォーカスされているのか視覚的に分からなければ、ユーザーは今いる位置が分からず入力を続けることができません。
フォーカス状態は必ず見えるように保ち、カスタマイズする場合は十分なコントラストを確保しましょう。

⑧コントラスト比の確保

フォームにおけるテキスト（ラベル・入力値・エラーメッセージなど）は、背景とのコントラスト比を十分に確保する必要があり、その達成基準は適合レベルごとに異なります。

【Aレベル】
コントラスト比の条件無し

【AAレベル】
・大きな文字
太字ではない18pt以上（日本語の場合は22pt）、または太字で14pt以上（日本語の場合は18pt）のテキストの場合 = 3:1 以上のコントラスト比を確保する

・小さな文字
大きな文字以外の場合（本文など）= 4.5:1 以上のコントラスト比を確保する

【AAAレベル】
・大きな文字
太字ではない18pt以上（日本語の場合は22pt）、または太字で14pt以上（日本語の場合は18pt）のテキストの場合 = 4.5:1 以上 のコントラスト比を確保する

・小さな文字
大きな文字以外の場合（本文など）= 7:1 以上のコントラスト比を確保する

現在のコントラスト比の状態を確認するには、無料公開されているContrast CheckerやGoogle ChromeのDevToolsの”スタイル”パネルから簡単にコントラスト比のチェックが可能です。

コントラスト比が低いと、色の識別が困難なユーザーだけでなく、視認性が悪くなり入力ミスや離脱の原因になります。
そのため、イーコーディングではフォームの文字色と背景色はAAレベル以上の基準を満たすことを推奨しています。

⑨確認・送信完了画面

フォームを送信した後、入力内容が正しく送信されたのかどうかが分からなければ、ユーザーは不安やストレスを感じます。
そのため、フォーム実装を行う際は最低でも「送信が完了しました」といった送信が成功したことがわかるような明確なメッセージを表示させるか、完了画面を設けるようにしましょう。

また、確認画面は入力ミスや誤送信を防ぐ効果があり、ユーザービリティにも影響するため要件に合わせて実装を検討してください。
もし確認画面を設けない場合は、送信前に入力内容の確認を促すメッセージを表示すると、誤送信防止に役立ちます。

まとめ

アクセシビリティを欠いたフォームは、支援技術を使用するユーザーに限らず、誰にとっても不便なフォームになってしまい、最終的には離脱につながってしまいます。

今回、ご紹介したポイントを押さえることで、利用しやすいフォームになり、機会損失の軽減や予防になります。既に自社サイトや自分のフォームを持っている方は作成したフォームをキーボードだけで操作してみたり、送信後の挙動を確認するなど、身近なところからチェックしてみてください！

ウェブアクセシビリティは小さな改善が重要であり、その積み重ねが大きな成果につながります！