「エラー防止（すべて）」は、情報を送信する場面で、入力や操作の誤りに気づき、訂正または取消ができるようにするためのWebアクセシビリティ基準です。
対象は重要な契約や支払いに限らず、ユーザーが情報を送信するWebページ全般です。
WCAG 2.2の達成基準3.3.6「Error Prevention (All)」では、適合レベルAAAとして、送信の取消、入力エラーの確認と訂正、送信前の確認と訂正のうち、少なくとも一つを利用できるようにすることを求めています。
単に入力を拒否するのではなく、ユーザーが何を直せばよいかを理解し、自分で修正できることが要点です。
「エラー防止（すべて）」が求める3つの方法
達成基準3.3.6では、すべての方法を同時に実装する必要はありません。
サービスの性質に合わせて、次のいずれかを確実に提供します。
| 方法 | ユーザーができること | 実装例 |
|---|---|---|
| 取消可能 | 送信後に操作を取り消せる | 送信の取消、削除データの復元、処理のキャンセル |
| チェック済み | 入力エラーを確認し、送信前に訂正できる | 誤りのある項目を特定し、理由と修正方法を示す |
| 確認済み | 確定前に内容を見直し、必要なら編集画面へ戻れる | 入力内容の確認画面と「修正する」導線を用意する |
例えば問い合わせフォームなら、入力エラーを具体的に示して訂正できる方法が考えられます。
申込みや予約のように確認すべき項目が多い場合は、確定前に内容を一覧表示し、各項目を修正できる流れが適しています。
「法的、財務、データ」との違い
WCAGには、達成基準3.3.4「エラー防止（法的、財務、データ）」もあります。
こちらは、契約、支払い、ユーザーが管理できるデータの変更や削除など、結果の重い操作を対象にする基準です。
一方、3.3.6「エラー防止（すべて）」は、情報の送信を必要とするWebページ全般へ対象を広げています。
重要な操作に絞った設計は、法務、財務、データに関するエラー防止の解説もあわせて確認してください。
訂正しやすいフォームを設計する手順
1. 入力前に条件を伝える
ラベル、必須か任意か、入力形式、文字数などの条件は、入力欄を操作する前に確認できる位置へ置きます。
プレースホルダーは入力を始めると消えるため、ラベルの代わりにはしません。
<label>と入力欄の関連付けを含む基本は、フォームラベルの付け方で詳しく解説しています。
2. エラーの場所、理由、直し方を示す
エラーメッセージは「入力に誤りがあります」だけで終わらせず、どの項目に問題があり、なぜ受け付けられず、どう直せばよいかを伝えます。
送信後も正しく入力された値を残しておけば、ユーザーは誤りのある項目だけを修正できます。
入力欄とエラーメッセージは、aria-describedbyなどで関連付けます。
エラーが確認された入力欄にはaria-invalid="true"を設定し、訂正されたら状態を戻します。
<label for="email">メールアドレス</label>
<input
id="email"
name="email"
type="email"
value="example@"
aria-invalid="true"
aria-describedby="email-error"
>
<p id="email-error">
@の後にドメイン名を入力してください。例：name@example.com
</p>複数のエラーがある場合は、フォームの先頭に一覧を置き、各メッセージから該当項目へ移動できるようにすると修正箇所を把握しやすくなります。
動的に表示する通知は、スクリーンリーダーでも変化を確認できるか実機で確かめます。
メッセージと読み上げの設計は、フォームの入力エラーを分かりやすく伝える方法も参考になります。
3. 確認画面から編集へ戻れるようにする
確認画面では「内容をご確認ください」という案内だけでなく、確定される情報を読みやすい順序で表示します。
「送信する」と「修正する」を明確に分け、修正画面へ戻っても入力済みの内容が失われないようにします。
項目が多い場合は、住所、連絡先、申込内容などのまとまりごとに見出しを付けます。
どの情報を確定しようとしているのかが視覚的にも支援技術にも伝わる構造にします。
4. 送信後に取り消せる仕組みを用意する
送信前の確認が利用の流れを複雑にする場合は、送信後の取消や復元を選べる設計もあります。
ただし、取消ボタンを置くだけではなく、対象の操作、取り消せる状態、実行後の結果を分かる言葉で示します。
処理が完了したときは、完了した内容と次にできる操作を画面上で知らせます。
取消に期限や条件があるサービスでは、その条件を操作前に確認できるようにします。
不十分になりやすい実装
- 内容を表示しない確認：「入力内容を確認してください」という警告だけでは、ユーザーは誤りを見つけられません。
- 修正方法のない入力チェック：形式が違うことだけを知らせても、受け付けられる形式が分からなければ訂正できません。
- プレースホルダーだけの説明：入力後に条件を見直せず、入力欄の名前も支援技術へ正しく伝わらない場合があります。
- 戻ると入力が消える確認画面：訂正のために最初から入力し直す設計は、エラー回復の負担を増やします。
- 常に表示されるエラー通知：まだ検証していない項目をエラーとして扱うと、現在の状態が分かりにくくなります。
実装後の確認項目
- キーボードだけで入力、エラー確認、訂正、送信、取消まで操作できるか
- エラーのある項目とメッセージの関係を視覚的に理解できるか
- スクリーンリーダーで項目名、エラー内容、修正方法を確認できるか
- エラー後も正しく入力した値が保持されるか
- 確認画面から編集へ戻り、再確認できるか
- 取消や復元を実行した結果が明確に伝わるか
- 拡大表示してもメッセージや操作ボタンが見失われないか
自動チェックはHTMLの属性や一部の状態を検出できますが、確認内容の分かりやすさや訂正のしやすさまでは判断できません。
実際の利用手順に沿ったキーボード操作と読み上げ確認を組み合わせます。
エラーを防ぐ設計の要点
「エラー防止（すべて）」への対応は、送信を止める機能を増やすことではありません。
ユーザーが内容を確認し、誤りを直し、必要なら操作を取り消せる流れを整えることです。
まず、現在のフォームが取消、入力チェックと訂正、送信前の確認のどれを提供しているかを整理します。
そのうえで、ラベル、エラーメッセージ、入力内容の保持、キーボード操作、読み上げまでを一つの手順としてテストしてください。
当社では、Webサイトのアクセシビリティ向上を支援するUUU ウェブアクセシビリティウィジェットツールを提供しています。
導入や運用に関心のある方は、サービスの詳細をご覧ください。