WCAG 2.2の達成基準3.3.3「エラーの修正提案」は、フォームなどで入力エラーを自動検出し、直し方が分かっている場合に、その方法を利用者へ伝えることを求めるレベルAAの基準です。
エラーがあると知らせるだけでは、利用者は次に何を入力すればよいか判断できません。
エラー箇所、受け付けられなかった理由、修正方法を一続きで理解できるメッセージが必要です。
3.3.3「エラーの修正提案」が求めること
入力エラーとは、利用者が入力したものの、システムに受け付けられなかった情報を指します。
必須項目の未入力、指定形式と異なる入力、許容範囲から外れた値などが該当します。
達成基準3.3.3が適用される条件は、次の三つです。
- 入力エラーが自動的に検出されている。
- 受け付けられる入力や修正方法が分かっている。
- 修正提案を示しても、コンテンツのセキュリティや目的を損なわない。
三つ目の条件に当てはまらない場合は、分かっている修正方法を利用者へ提示します。
反対に、修正提案によってセキュリティやコンテンツの目的が損なわれる場合は、提案を省略できます。
エラーの特定と修正提案の違い
達成基準3.3.1「エラーの特定」は、誤りのある項目を特定し、何が問題なのかをテキストで説明する基準です。
達成基準3.3.3は、その説明に加えて、分かっている直し方を伝える役割を担います。
| 伝える内容 | メッセージ例 |
|---|---|
| エラーの特定 | 「メールアドレスの形式が正しくありません」 |
| 修正提案 | 「@を含むメールアドレスを入力してください。例：name@example.com」 |
「入力に問題があります」だけでは、どの項目をどう直すのか分かりません。
項目名と原因を示したうえで、形式、範囲、選択肢などの具体的な手掛かりを添えます。
修正提案が役立つ入力エラー
| 入力エラー | 不足している情報 | 修正提案の例 |
|---|---|---|
| 必須項目が空欄 | 入力が必要だと分からない | 「氏名を入力してください」 |
| 形式が異なる | 受け付ける形式が分からない | 「日付は年4桁、月2桁、日2桁をスラッシュで区切って入力してください。例：2000/01/31」 |
| 許容値から外れている | 入力できる範囲が分からない | 「年齢は1から100までの数値で入力してください」 |
| 選択肢にない値 | 選べる値が分からない | 「都道府県は一覧から選択してください」 |
修正提案は、答えを推測して自動入力することではありません。
システムが受け付ける条件を示し、利用者が自分で正しい内容に直せるようにする説明です。
伝わるエラーメッセージの組み立て方
エラーメッセージは「どこが」「なぜ」「どう直すか」の順に組み立てると、次の操作が明確になります。
- どこが：項目名を示す。
- なぜ：未入力、形式違い、範囲外などの原因を示す。
- どう直すか：受け付ける形式、範囲、選択肢、入力例を示す。
たとえば「日付が無効です」だけでは、利用者は区切り文字や桁数を判断できません。
「利用日は2000/01/31の形式で入力してください」と示せば、直し方まで伝わります。
HTMLでエラーと入力欄を関連付ける
修正提案は画面に表示するだけでなく、該当する入力欄とプログラム上でも関連付けます。
次の例は、検証後にエラーとなった入力欄の状態を示したものです。
<label for="start-date">利用日（必須）</label>
<input id="start-date"
name="start-date"
type="text"
inputmode="numeric"
aria-invalid="true"
aria-describedby="start-date-error">
<p id="start-date-error">
利用日は「2000/01/31」の形式で入力してください。
</p>label要素で入力欄の名前を表示する。- 検証でエラーになったときに
aria-invalid="true"を設定し、修正後は解除する。 aria-describedbyで入力欄とエラーメッセージを関連付ける。- 色だけに頼らず、原因と修正方法をテキストで示す。
ラベル、補足説明、aria-describedbyの役割は、フォームのラベルと説明を正しく実装する方法で詳しく解説しています。
複数のエラーを伝える方法
送信後に複数の項目でエラーが見つかった場合は、フォームの先頭にエラー概要を置き、各入力欄の近くにも個別のメッセージを表示すると位置を把握しやすくなります。
- エラー件数と対象項目を概要で知らせる。
- 概要から該当する入力欄へ移動できるようにする。
- 入力済みの値は、修正に不要な再入力を避けられるよう保持する。
- 表示後のフォーカス位置と読み上げ順を確認する。
画面を見ていない利用者にも更新を伝える設計は、WCAG 2.2「4.1.3 ステータスメッセージ」も参考になります。
よくある失敗と改善方法
| 失敗 | 問題 | 改善 |
|---|---|---|
| 「入力エラーがあります」とだけ表示する | 対象項目も直し方も分からない | 項目名、原因、修正方法を示す |
| 赤い枠やアイコンだけで示す | 色や見た目を認識できないと伝わらない | テキストを併記し、入力欄と関連付ける |
| 正しい形式を送信後まで示さない | 利用者が試行錯誤を繰り返す | 入力前の説明と、エラー後の具体例を用意する |
| 自動テストの結果だけで判断する | 文章が実際に修正へ導くか確認できない | 手動操作と支援技術でメッセージの内容と伝わり方を確認する |
手動テストの手順
エラー修正提案の品質は、メッセージの意味と一連の操作を含めて確認します。
- 未入力、形式違い、範囲外など、想定するエラー条件を整理する。
- キーボードだけで入力し、送信する。
- エラーのある項目、原因、修正方法がテキストで分かるか確認する。
- エラー概要や個別メッセージへ無理なく移動できるか確認する。
- スクリーンリーダーを使い、入力欄の名前、エラー状態、修正提案が理解できる順序で読み上げられるか確認する。
- 提案に従って修正し、エラー状態が適切に解除されるか確認する。
- セキュリティやコンテンツの目的を理由に提案を省略した箇所は、その判断が必要な範囲に限られているか確認する。
AxeやWAVEなどの自動テストツールは、HTMLや一部のARIA属性の問題を見つける補助になります。
ただし、メッセージが業務ルールに合っているか、利用者が読んで直せるかまでは自動判定できないため、手動テストを省略する根拠にはなりません。
フォーム全体の入力支援とエラー設計を整理したい場合は、WCAG 2.2で押さえる入力支援とエラー設計の基本もあわせてご覧ください。
実装前の確認項目
- 入力エラーを自動検出する条件が定義されている。
- 項目名とエラーの原因をテキストで特定できる。
- 分かっている修正方法を、形式、範囲、選択肢、入力例で具体化している。
- 入力欄とエラーメッセージがプログラム上で関連付いている。
- 色やアイコンだけに依存していない。
- キーボードとスクリーンリーダーで一連の修正操作を確認している。
- 自動テストと手動テストの役割を分けている。
利用者が次の操作を判断できる説明へ
達成基準3.3.3を満たすために必要なのは、エラーの存在を知らせることだけではありません。
利用者が「どこを、どのように直せばよいか」を判断できる提案を、該当する入力欄と結び付けて伝えます。
実装後は、想定したエラー条件を一つずつ発生させ、表示、キーボード操作、読み上げ、修正後の状態まで確認してください。
Webアクセシビリティの導入や改善を検討している方は、当社のUUU ウェブアクセシビリティもご覧ください。