WCAG 2.2の達成基準3.3.4「エラー防止（法的、財務、データ）」は、契約や決済、重要なデータの変更、試験回答の送信など、間違えると深刻な結果につながる操作を対象とするLevel AAの達成基準です。
対象となるページでは、送信後に取り消せること、入力エラーを検出して訂正できること、確定前に内容を見直して修正できることのうち、少なくとも一つを提供します。単に確認メッセージを表示するのではなく、利用者が間違いに気付き、確定前後に訂正できる流れを設計する必要があります。
達成基準3.3.4が対象にする操作
W3Cの達成基準3.3.4は、次のいずれかに該当するウェブページを対象としています。
- 利用者に法的な義務や権利が生じる操作
- 購入や送金などの金銭取引
- データ保存システムにある、利用者が管理できるデータの変更または削除
- 試験やテストの回答送信
利用者が管理できるデータとは、利用者自身が閲覧し、意図的な操作によって変更または削除できるデータです。たとえば、アカウントの住所変更や保存済み記録の削除が該当します。一方、通常の文書編集で保存するたびに確認を求めることまで、この達成基準が一律に要求しているわけではありません。
達成基準3.3.4は、結果の重い操作に対象を絞っています。すべての情報送信で同様のエラー防止を扱うLevel AAAの基準については、達成基準3.3.6「エラー防止（すべて）」の解説で確認できます。
要件を満たす三つの方法
三つの方法は、どれか一つを採用すれば達成基準3.3.4の要件を満たせる構成です。操作の影響やシステムの性質に応じて、複数の方法を組み合わせても構いません。
| 方法 | 利用者ができること | 実装例 |
|---|---|---|
| 取消可能 | 確定した送信を後から取り消す | 注文の取消期間を設ける、削除したデータを復元できるようにする |
| 入力チェック | 入力エラーを確認し、送信前に訂正する | 未入力や受け付けられない値を示し、該当欄を修正できるようにする |
| 確定前の確認 | 送信内容を見直し、確認し、必要なら修正する | 確認画面から入力画面へ戻り、内容を直してから確定する |
ここでいう入力エラーは、必須情報の未入力や、ページが受け付けない形式または値の入力を指します。エラーを検出するだけでは足りません。どこを直す必要があるかを利用者に伝え、訂正する機会を提供します。
購入や契約の確認フロー
購入や契約では、最終操作の前に内容を一覧で確認できるページを設ける方法がわかりやすいでしょう。確認画面は、入力内容を表示するだけでなく、修正と確定の二つの経路を区別します。
- 利用者が必要な情報を入力または選択する。
- 確認画面で、取引の対象、数量、金額、送付先など、確定する内容をまとめて示す。
- 誤りがあれば入力画面へ戻り、内容を修正できるようにする。
- 「この内容で注文を確定する」のように、結果が分かるボタン名で最終送信する。
「内容を確認しました」というチェックボックスだけを置いても、確認すべき情報が近くに表示されず、修正する経路もなければ、利用者は間違いを直せません。確認、訂正、確定を一つの流れとして設計します。
データ削除の確認と復元
データ削除では、削除後に元へ戻せる仕組みがあれば「取消可能」の方法を使えます。ごみ箱へ移して復元できるようにする場合は、復元できる対象と期間を利用者が理解できるように示します。
復元できない削除では、確定前の確認を使う方法があります。確認画面やダイアログには、削除する対象と、削除後に元へ戻せないことを具体的に示します。利用者が中止できる選択肢を用意し、確認操作を初期選択にしないことも誤操作の防止につながります。
元記事のような「本当に削除しますか」という短いメッセージだけでは、複数のデータを扱う画面で対象を見分けにくい場合があります。「顧客記録3件を完全に削除します」のように、操作の対象と結果を確認できる文にします。
試験回答を送信する前の見直し
試験やテストでは、回答を送信する前に、全体を見直して修正できる画面を用意します。回答済みと未回答の設問を区別し、確認画面から各設問へ戻れる構成にすると、利用者は誤りを探しやすくなります。
修正のために前の画面へ戻ったときは、それまでの回答を保持します。確認画面へ戻った後も修正内容が反映されていることを確かめ、最終送信の直前まで訂正できるようにします。
よくある実装上の不足
- 確認内容が不足している：金額だけを表示し、数量や対象、送付先などの確定内容を確認できない。
- 修正経路がない：確認画面はあるものの、入力画面へ戻る方法が分からない。
- 操作の結果が曖昧である：「実行しますか」だけでは、何が確定または削除されるのか判断できない。
- 入力内容が失われる：修正のために戻ると入力済みの内容が消え、最初から入力し直す必要がある。
- 外観だけで判断している：確認画面が表示されることだけを確認し、キーボード操作や支援技術で修正と確定を区別できるかを検証していない。
フォーム全体の案内、エラー表示、ラベルの考え方は、フォームの入力支援とエラー設計の基本も参考になります。
達成基準3.3.4のテスト方法
達成基準3.3.4は、画面のHTMLだけでなく、入力から確定、訂正または取消までの操作全体を確認します。
- 契約、決済、重要データの変更または削除、試験回答の送信に該当する操作を洗い出す。
- 各操作で、取消可能、入力チェック、確定前の確認のどれを提供しているかを記録する。
- 意図的に入力ミスや選択ミスを作り、エラーの場所と内容が分かり、修正できるかを確認する。
- 確認画面から入力内容を修正し、修正後の内容で確定できるかを確認する。
- 取消可能な設計では、確定後に実際に取り消しまたは復元できるかを確認する。
- キーボード操作や支援技術でも、確認、修正、中止、確定の各操作を区別して実行できるかを確認する。
自動チェックツールは、フォーム部品の一部の問題を見つける補助として使えます。ただし、対象となる取引かどうか、確認内容が十分か、取消や復元が業務上正しく機能するかは、実際の操作フローを使った手動確認が必要です。検証計画の立て方は、ウェブアクセシビリティチェックの進め方で詳しく解説しています。
実装と検証のチェックリスト
- 対象となる重要な操作を一覧にしたか。
- 各操作で採用するエラー防止方法を決めたか。
- 確認画面に、確定する内容と結果を具体的に示したか。
- 確認画面から入力内容を修正できるか。
- 修正の前後で入力済みデータが保持されるか。
- 削除や送信を中止できるか。取消可能な設計では、実際に復元できるか。
- 自動チェックだけで終えず、操作全体を手動で検証したか。
W3Cの参考資料
仕様本文は適合要件を示し、W3Cの解説文書は目的、対象範囲、実装技法を理解するための補助資料です。実装を判断するときは、両者の役割を分けて参照します。
実装で押さえる要点
達成基準3.3.4への対応では、対象となる重要な操作を先に特定し、その操作に合うエラー防止方法を選びます。
- 送信後に取り消せるようにする。
- 入力エラーを検出し、利用者が訂正できるようにする。
- 確定前に内容を見直し、確認し、修正できるようにする。
確認画面を一枚追加すること自体が目的ではありません。利用者が操作の対象と結果を理解し、間違いに気付いたときに修正または取消できることを、実際の操作で検証します。
当社では、ウェブアクセシビリティを導入しやすくするUUU ウェブアクセシビリティを提供しています。アクセシビリティ改善を検討している方は、サービスの詳細をご覧ください。