フォームを送信しても同じ画面が表示されるだけでは、利用者は送信に失敗したことも、直すべき入力欄も判断できません。
エラーの特定とは、システムが入力エラーを検出したときに、どの項目に何の問題があるのかをテキストで伝えることです。
赤い枠やアイコンは手掛かりになりますが、それだけでは色を判別しにくい人やスクリーンリーダーの利用者に情報が届かない場合があります。
この記事では、WCAGの達成基準を実装へ落とし込む順序と、公開前に確認したい項目を具体例とともに整理します。
WCAGが求める「エラーの特定」
WCAG 2.2の達成基準3.3.1「エラーの特定」は、自動的に検出した入力エラーについて、該当する項目を特定し、エラーの内容をテキストで説明することを求めています。
ここでいう入力エラーには、必須項目の未入力や、指定された形式または許容値に合わない入力が含まれます。
エラーを画面上部に一覧表示するか、各入力欄の近くに表示するかといった見せ方は一つに決められていません。
フォームの長さや画面遷移の有無に合わせ、利用者がエラーの発生と場所を把握できる方法を選びます。
| 達成基準 | 利用者に伝える内容 | メッセージ例 |
|---|---|---|
| 3.3.1 エラーの特定（レベルA） | どの項目に、何のエラーがあるか | 「メールアドレスが未入力です」 |
| 3.3.3 エラー修正の提案（レベルAA） | 修正方法が分かる場合は、その方法 | 「name@example.com の形式で入力してください」 |
達成基準3.3.3「エラー修正の提案」は、修正方法が分かる場合に、その方法を示す基準です。
実務では「メールアドレスは name@example.com の形式で入力してください」のように、項目、問題、直し方を一文にすると、両方の目的を満たしやすくなります。
フォーム全体を設計するときは、関連記事のWCAG 2.2で考える入力支援とエラー設計も参照してください。
利用者に伝わりにくいエラー表示
エラーメッセージが存在していても、必要な情報が欠けていれば修正にはつながりません。
- 入力欄の枠線を赤くするだけで、テキストによる説明がない
- 「入力内容に誤りがあります」とだけ表示し、該当する項目を示さない
- エラーメッセージが入力欄から離れ、両者の関係が見た目でもプログラム上でも分からない
- 画面を再読み込みせずにエラーを追加したものの、その変化を支援技術へ通知していない
- 入力例をプレースホルダーだけで示し、入力を始めると確認できなくなる
これらの問題は、利用者にエラー箇所を探させたり、入力条件を推測させたりします。
メッセージの文面、表示位置、入力欄との関連付け、通知方法を分けて点検すると、修正すべき箇所を特定しやすくなります。
エラーを伝える実装の手順
1. 項目名、問題、直し方を具体的に書く
「入力エラー」だけでは、利用者は何を直せばよいか分かりません。
メッセージには、対象の項目名と受け付けられなかった理由を含め、修正方法が分かる場合はその方法も示します。
- 伝わりにくい例：「入力内容に誤りがあります」
- 改善例：「メールアドレスは name@example.com の形式で入力してください」
- 必須項目の例：「お名前が未入力です。お名前を入力してください」
「正しく入力してください」のような表現は、何が正しいのかを利用者が判断できない場合があります。
文字数、日付形式、選択可能な値など、実際の入力条件に合わせて説明します。
2. エラーメッセージを入力欄と関連付ける
エラーメッセージは該当する入力欄の近くに置き、HTML上でも関係を示します。
aria-invalid='true'は入力値が無効な状態であることを示し、aria-describedbyは入力欄と説明文を関連付けます。
<label for='email'>メールアドレス</label>
<input
id='email'
name='email'
type='email'
aria-invalid='true'
aria-describedby='email-error'>
<p id='email-error'>
メールアドレスは name@example.com の形式で入力してください。
</p>エラーを修正した後は、表示を消すだけでなく、入力欄のエラー状態と関連付けも現在の状態に合わせて更新します。
ARIA属性の役割やHTMLとの使い分けは、WAI-ARIAの基本と使い方で詳しく解説しています。
3. 複数のエラーは概要から各項目へ移動できるようにする
長いフォームで複数のエラーが発生した場合は、フォームの前にエラーの件数と一覧を置くと、全体を把握しやすくなります。
一覧の各メッセージを該当する入力欄へのページ内リンクにすれば、キーボードでも修正箇所へ移動できます。
<div role='alert' aria-labelledby='error-heading'>
<h2 id='error-heading'>入力内容を2件確認してください</h2>
<ul>
<li><a href='#name'>お名前が未入力です</a></li>
<li><a href='#email'>メールアドレスの形式を確認してください</a></li>
</ul>
</div>送信後は、エラー概要または最初のエラー項目へフォーカスを移す方法を検討します。
どこへ移すかはフォームの構成に合わせ、移動後にエラーの内容と次の操作が理解できることを実機で確認します。
4. 動的に追加したメッセージを支援技術へ通知する
画面遷移なしでエラーメッセージを追加する場合は、role='alert'やaria-liveを使う方法があります。
aria-live='polite'は現在の読み上げを遮りにくく、即時性の高い通知にはassertiveが使われることがあります。
すべてのメッセージを強い通知にすると操作中の読み上げを中断し得るため、エラーの重要度と表示のタイミングに合わせて選びます。
5. 色だけに頼らず、テキストと形でも示す
WCAG 2.2の達成基準1.4.1「色の使用」は、色を情報伝達の唯一の視覚的手段にしないことを求めています。
赤い枠線を使う場合も、「エラー」というテキスト、具体的なメッセージ、枠線やアイコンなどを組み合わせます。
アイコンだけを置くのではなく、その意味がテキストでも伝わるようにします。
6. 入力前の説明を見える場所に残す
エラーを減らすには、必須か任意か、受け付ける形式、入力例などを送信前に確認できるようにします。
プレースホルダーは入力を始めると消えるため、ラベルの代わりには使わず、補助的な例として扱います。
入力中も必要になる条件は、ラベルの近くに残る説明として表示し、必要に応じてaria-describedbyで入力欄と関連付けます。
公開前の確認項目
実装後は、見た目だけでなく、エラーを発見して修正する一連の操作を確認します。
- 必須項目を空欄にした場合と、形式の異なる値を入れた場合を試す
- 各メッセージから、対象項目とエラーの理由を判断できるか確認する
- 修正方法が分かるエラーでは、その方法が具体的に示されているか確認する
- 色を手掛かりにしなくても、エラーの有無と場所が分かるか確認する
- キーボードだけでエラー概要から各入力欄へ移動できるか確認する
- スクリーンリーダーで、動的な通知と入力欄に関連付いた説明を確認する
- エラー修正後に、古いメッセージやエラー状態が残っていないか確認する
- サーバー側で検証した場合にも、同じ水準の説明が表示されるか確認する
ブラウザーや支援技術によって通知の挙動が異なる場合があるため、属性を追加しただけで完了とせず、実際の操作で確かめます。
分かりやすいエラー表示が支えるもの
エラーの場所と直し方が分かれば、利用者はフォームを最初から見直す必要がなくなり、目的の手続きを続けやすくなります。
これは障害のある利用者だけに向けた配慮ではありません。
入力項目が多い手続き、慣れない形式、モバイル端末での操作など、誰にでも起こり得る迷いを減らします。
ただし、エラー表示を整えただけでコンバージョン率の向上が保証されるわけではありません。
完了率や離脱箇所を継続して確認し、ラベル、入力条件、エラーメッセージを一体として改善します。
ウェブアクセシビリティ対応を進めるために
自社サイトのアクセシビリティ改善を進める際は、個々のエラー表示だけでなく、フォーム全体の構造や操作の流れも確認する必要があります。
UUU ウェブアクセシビリティウィジェットツールの情報も、サイト改善を検討する際の参考としてご覧ください。