WCAG 2.2の達成基準3.3.1「エラー識別」（Level A）は、フォームなどで入力エラーを自動的に検出したとき、問題のある入力項目を特定し、エラーの内容をテキストで伝えることを求めています。
「エラーがあります」という表示や色の変化だけでは、利用者は直す場所や理由を判断できません。
この記事では、達成基準の意味からエラーメッセージの例、HTMLでの関連付け、テスト方法までを順に説明します。
達成基準3.3.1「エラー識別」が求めること
入力エラーとは、利用者が入力した情報のうち、ページが受け付けない状態を指します。
必須項目の未入力も入力エラーに含まれます。
達成基準3.3.1が求める内容は、次の二つです。
- どの入力項目にエラーがあるかを特定する。
- 何が誤っているかをテキストで説明する。
色、枠線、アイコンを補助として使うことはできますが、テキストによる説明を置き換えるものではありません。
WCAG 2.2の全体像とWebアクセシビリティの基本も確認すると、この達成基準の位置づけを理解しやすくなります。
対象となる入力エラー
| エラーの種類 | 曖昧な表示 | 内容が伝わる表示 |
|---|---|---|
| 必須項目の未入力 | 入力に誤りがあります。 | 名前を入力してください。 |
| 指定形式と異なる入力 | 形式が正しくありません。 | メールアドレスをname@example.comの形式で入力してください。 |
| 許容範囲を外れた値 | 範囲外です。 | 年齢は1から100の範囲で入力してください。 |
エラーがある項目名と理由を一緒に書くと、利用者は確認すべき場所を絞れます。
エラーメッセージの組み立て方
エラーメッセージには、項目名、受け付けられなかった理由、必要に応じて受け付けられる形式を含めます。
- 項目を特定する：「名前」「メールアドレス」のように、エラーがある入力欄を示します。
- 理由を説明する：未入力、形式の不一致、範囲外など、受け付けられなかった理由を示します。
- 直し方を具体化する：受け付けられる形式や範囲が分かる場合は、短い例を添えます。
達成基準3.3.1の中心は、エラーがある項目と内容を伝えることです。
修正方法の提案は達成基準3.3.3で扱われる内容ですが、形式や範囲が分かっている場合は、同じメッセージで直し方まで示すと修正しやすくなります。
詳しい考え方は、関連記事のフォームの入力エラーを分かりやすく伝える方法で確認できます。
HTMLで入力欄とエラー文を関連付ける
達成基準3.3.1は特定の表示方法やARIAの使用を必須にしていませんが、次の関連付けは支援技術にエラー状態と説明を伝える実装例になります。
次のコードは、検証後にメールアドレス欄がエラーになった状態を示す例です。
<label for="email">メールアドレス（必須）</label>
<input
id="email"
name="email"
type="email"
aria-required="true"
aria-invalid="true"
aria-describedby="email-error">
<p id="email-error">
メールアドレスをname@example.comの形式で入力してください。
</p>aria-invalid="true"は、その入力欄が検証に失敗した状態であることを示します。
aria-describedbyは、入力欄とエラーメッセージを関連付けます。
エラーが解消したときはメッセージを非表示にし、aria-invalidを削除するか値をfalseに戻します。
これらの属性を付けても、画面上の具体的なエラーテキストは必要です。
フォーム全体のラベル、入力支援、エラー表示をまとめて設計する場合は、フォームの入力支援とエラー設計の基本も参考になります。
よくある失敗と改善方法
エラーがあることだけを表示する
「入力内容を確認してください」という文だけでは、エラーのある項目と理由が分かりません。
「メールアドレスをname@example.comの形式で入力してください」のように、項目名と受け付けられる形式を示します。
色だけでエラーを示す
枠線を赤くするだけでは、色の違いを認識しにくい利用者や、画面を見ずに操作する利用者にエラーの内容が伝わりません。
色やアイコンを使う場合も、項目の近くやエラー一覧にテキストを表示します。
エラー文と入力欄の関係が分からない
エラー文をページ上部に並べるだけでは、対応する入力欄を探しにくくなることがあります。
エラー文に項目名を含め、入力欄の近くにも表示し、必要に応じてプログラム上でも関連付けます。
検証前からエラー状態を付ける
入力をまだ検証していない段階でaria-invalid="true"を付けると、実際には確定していないエラー状態を伝えてしまいます。
検証によってエラーを確認した時点で付け、修正後に解除します。
手動テストと自動チェック
必須項目、入力形式、値の範囲を一つずつ変え、各エラーが想定どおりに伝わるかを確認します。
- 未入力や不正な値のまま送信し、エラーが表示されることを確認します。
- エラー文だけを読んで、対象の項目と理由が分かるか確認します。
- 色やアイコンを見なくても、エラーの内容が分かるか確認します。
- キーボードだけでエラー項目を見つけ、入力を修正できるか確認します。
- スクリーンリーダーで、入力欄の名前、エラー状態、説明の関係が分かるか確認します。
- 修正後にエラーメッセージとエラー状態が解除されるか確認します。
axeやWAVEなどの自動チェックツールは、マークアップ上の問題を見つける補助になります。
ただし、メッセージの文面が利用者にとって具体的かどうかは、実際の操作を含む手動テストでも確認します。
実装時に確認する要点
- 自動検出したエラーについて、対象の入力項目を特定できる。
- エラーの理由を具体的なテキストで説明している。
- 色やアイコンだけに情報を依存していない。
- 入力欄とエラーメッセージを見た目で対応付け、必要に応じてプログラム上でも関連付けている。
- エラーの発生から修正、解除までを手動でテストしている。
達成基準3.3.1への対応では、エラーの存在だけでなく、利用者が「どこを」「なぜ」直すのかを判断できる表示に整える必要があります。
Webアクセシビリティの実装や継続的な確認を進めたい方は、UUU ウェブアクセシビリティの詳細をご覧ください。