「エラーの識別」とは、フォームで入力ミスが検出されたときに、誤りのある項目と問題の内容をテキストで伝えることです。
ユーザーが「どこを、なぜ、どう直せばよいか」を判断できる状態まで示す必要があります。
WCAG 2.2の基礎解説で紹介しているとおり、WCAGはウェブコンテンツを利用しやすくするためのガイドラインです。
エラーの識別は、視覚的な表示だけでなく、スクリーンリーダーなどの支援技術にも情報が届くように設計します。
エラーの識別で伝える三つの情報
「入力エラーがあります」だけでは、利用者は修正に進めません。
エラーメッセージには、次の三つの情報を含めます。
| 伝える情報 | 利用者が知りたいこと | 例 |
|---|---|---|
| 項目 | どこに問題があるか | メールアドレス |
| 原因 | 何が条件に合っていないか | 未入力になっている |
| 直し方 | どのように修正するか | メールアドレスを入力する |
たとえば「入力内容に誤りがあります」ではなく、「メールアドレスを入力してください」と書けば、項目、原因、直し方を短い文で伝えられます。
日付の形式が違う場合は、「日付はYYYY/MM/DD形式で入力してください」のように、必要な形式も示します。
分かりにくいエラー表示が操作を止める理由
- エラー箇所が分からない：入力欄が複数あると、利用者はフォーム全体を見直すことになります。
- 原因が分からない：「無効な値です」だけでは、未入力なのか形式の違いなのかを判断できません。
- 色でしか示されない：赤い枠線だけでは、色の違いを認識しにくい利用者や、画面を見ずに操作する利用者へ情報が届きません。
- 読み上げで通知されない：画面上のメッセージだけが変化すると、スクリーンリーダーの利用者が変更に気付けないことがあります。
これらは別々の問題です。
見た目を強調するだけでは、メッセージの内容や支援技術への通知までは改善できません。
入力欄とエラーメッセージを関連付ける
次の例は、メールアドレスが未入力だったときの表示状態です。
ラベル、入力欄、エラーメッセージを一つのまとまりとして実装します。
<div class="field field--error">
<label for="email">メールアドレス</label>
<input
type="email"
id="email"
name="email"
required
aria-invalid="true"
aria-describedby="error-email"
>
<p id="error-email" class="error-message" role="alert">
エラー：メールアドレスを入力してください。
</p>
</div>labelと入力欄のidを対応させ、項目名を明確にします。aria-invalid="true"で、入力欄がエラー状態であることを支援技術へ伝えます。aria-describedbyにメッセージのidを指定し、入力欄と説明を関連付けます。role="alert"は、検証後にメッセージを動的に追加または更新する場合の通知に使います。
role="alert"は即時性の高い通知として扱われるため、同じ内容を繰り返し読み上げない設計も必要です。
ページを読み込んだ時点から表示されている説明は、aria-describedbyによる関連付けで確認できるようにします。
スクリーンリーダーとライブリージョンの仕組みは、スクリーンリーダーと読み上げ環境のアクセシビリティ解説も参照してください。
色だけに頼らずエラーを強調する
色や枠線はエラー箇所を見つける手掛かりになりますが、それだけで状態を伝えることはできません。
上のHTML例のように「エラー」というテキストと具体的な説明を表示したうえで、CSSを視覚的な補助として使います。
.field--error input {
border: 2px solid #b00020;
}
.error-message {
color: #b00020;
font-weight: 700;
}元の入力欄そのものを枠線で強調し、すぐ近くにエラーメッセージを置くと、視線を移動する量を抑えられます。
色を見分けにくい状況でも、テキストを読めば状態と修正方法が分かります。
エラーメッセージの書き方
専門用語やシステム内部の表現を避け、利用者が次の操作を選べる文にします。
| 分かりにくい表現 | 修正しやすい表現 |
|---|---|
| 入力エラーです | メールアドレスを入力してください |
| 形式が不正です | 日付はYYYY/MM/DD形式で入力してください |
| 必須項目が未入力です | お名前を入力してください |
エラーの原因と修正方法が同じ文で伝わる場合は、説明を増やす必要はありません。
入力条件が複数ある場合は、エラーが起きる前にも入力欄の近くで条件を示します。
フォーム全体のラベルや入力支援も含めて見直す場合は、フォームの入力支援とエラー設計の基本で確認項目を整理しています。
実装後の確認項目
メッセージの内容
- エラーのある項目名が分かるか
- 問題の原因を具体的な言葉で示しているか
- 分かっている修正方法や入力形式を示しているか
- 複数のエラーを一つの曖昧な文にまとめていないか
見た目と配置
- 色だけでエラー状態を伝えていないか
- 入力欄の近くにテキストのメッセージがあるか
- 拡大表示しても入力欄とメッセージの関係が分かるか
操作と読み上げ
- キーボードだけでエラー箇所へ移動し、修正できるか
- 入力欄のラベルとエラーメッセージがスクリーンリーダーで確認できるか
- 動的に表示したメッセージが一度だけ適切に通知されるか
- エラー修正後に古いメッセージやエラー状態が残っていないか
コードの属性だけを確認しても、実際の読み上げ順や操作のしやすさまでは判断できません。
キーボード操作とスクリーンリーダーを使い、エラーの発生から修正、再送信までを一連の流れで試します。
利用者が自分で修正できる表示を目指す
エラーの識別では、赤い枠線を付けるだけでなく、誤りのある項目、原因、直し方をテキストで伝えます。
入力欄との関連付けと動的な通知を整えれば、画面を見ている利用者にも、支援技術を使う利用者にも同じ判断材料を届けられます。
ウェブアクセシビリティ対応を進めるために
当社では、ウェブアクセシビリティへの対応を支援するUUU ウェブアクセシビリティウィジェットツールを提供しています。
サイトのアクセシビリティ改善を検討している方は、サービスの詳細をご覧ください。