WCAG 2.2の達成基準3.3.4「エラー回避（法的、金融、データ）」は、取り返しにくい操作のミスを、確定前または確定後に修正できるようにする基準です。
法的な約束、金融取引、利用者が管理するデータの変更や削除、試験の解答送信が対象となり、レベルAAに位置付けられています。
対応の中心は、入力欄を増やすことではなく、利用者が誤りに気付き、確定を止め、内容を直せる流れを設けることです。
達成基準3.3.4が対象とする操作
WCAG 2.2の達成基準3.3.4は、次のいずれかを行うウェブページを対象にしています。
- 法的な約束：契約への同意など、利用者に法的な義務や利益が生じる操作です。
- 金融取引：商品の購入や送金など、金銭に関わる取引を確定する操作です。
- 利用者が管理するデータ：利用者自身が閲覧し、変更または削除できる保存済みデータを更新する操作です。
- 試験の解答：採点対象となる解答を送信する操作です。
「データ」は、あらゆる入力内容を指すわけではありません。
たとえば、アカウントの住所変更や保存済み記録の削除は対象になり得ますが、利用者が閲覧も操作もできないアクセスログは「利用者が管理するデータ」には含まれません。
毎回の保存操作に確認画面が必要という意味でもなく、誤操作による重大な結果を避けることが基準の目的です。
求められる三つの対応方法
対象となる操作には、次の三つのうち少なくとも一つを用意します。
| 対応方法 | 利用者ができること | 実装例 |
|---|---|---|
| 取り消せる | 送信後に操作を取り消し、元の状態へ戻せる | 注文のキャンセル、削除した記録の復元 |
| 誤りを確認できる | システムが入力エラーを検出し、確定前に修正できる | 必須項目や入力形式を確認し、該当欄へ戻して修正できる |
| 見直して確定できる | 送信内容を確認し、必要なら修正してから確定できる | 注文内容の確認画面から入力画面へ戻れる |
一つを満たせば基準への対応方法になりますが、結果が大きい操作では、確認画面と取り消し機能のように複数の仕組みを組み合わせると、誤りを防ぐ機会を増やせます。
確認画面で見直しと修正を可能にする
確認画面は、送信内容を並べるだけではなく、確定前に誤りを発見して直せる画面として設計します。
購入手続きなら、商品、数量、配送先、支払方法など、結果に影響する項目を読みやすい順序で表示します。
利用者が誤りを見つけたときに、ブラウザーの「戻る」操作へ頼らず修正画面へ移動でき、入力済みの値が保たれることも必要です。
確定ボタンには「送信」ではなく、「注文を確定する」のように結果が分かる名前を付けます。
- 利用者が必要事項を入力する。
- システムが検出できる入力エラーを示し、修正の機会を提供する。
- 確認画面に、結果へ影響する項目を表示する。
- 利用者が内容を修正するか、明確な確定ボタンで操作を完了する。
入力エラーを特定し、直し方まで伝える
入力値を確認する方法を選ぶ場合は、エラーのある項目を特定し、利用者が修正できる状態にします。
「入力内容に誤りがあります」だけでは、どこをどう直すのか分かりません。
「有効期限を月2桁、年2桁で入力してください」のように、対象と修正方法をテキストで示します。
ただし、システムが検出できるのは、未入力や形式違反など、判定条件を定められる誤りです。
形式として正しい別の住所や数量の取り違えは検出できないことがあるため、確認画面や取り消し機能が補います。
フォーム全体の入力支援とエラー設計では、ラベル、説明、エラー表示を含む設計の基本を確認できます。
取り消しと復元で送信後の誤りに備える
操作を取り消せる設計では、利用者が期限や手順を理解でき、実際に元の状態へ戻せることが必要です。
データ削除なら、一定の仕組みの中で復元できる領域へ移す方法や、削除前に対象を明示して確認する方法があります。
金融取引や法的な手続きには、サービスの規約や業務上の制約によって取り消せないものもあります。
その場合は、確定前の確認と修正を提供し、取り消せるように見せる表現は避けます。
補助機能と基準への対応を区別する
リアルタイムの入力案内、自動保存、確認用チェックボックスは、入力体験を整える手段ですが、設置しただけで達成基準3.3.4を満たすとは限りません。
- リアルタイムの入力案内：誤りの早期発見を助けますが、検出した誤りを修正できることまで確認します。
- 自動保存：再入力の負担を減らしますが、送信の取り消し、入力エラーの確認、確定前の見直しの代わりにはなりません。
- 確認用チェックボックス：「確認しました」だけでは確認対象が曖昧になるため、対象となる操作と結果を具体的に示します。
補助機能を追加する前に、「取り消せる」「誤りを確認して直せる」「見直してから確定できる」のどれで対応するのかを決めると、実装と試験の範囲が明確になります。
エラー情報を支援技術へ伝える
エラーメッセージは色だけで区別せず、項目名、原因、修正方法をテキストで示します。
入力欄と説明文やエラーメッセージを関連付ける場合は、状況に応じてaria-describedbyを使います。
送信後に追加されるエラー概要を読み上げ環境へ通知する必要がある場合は、aria-liveなどの仕組みを検討します。
ただし、ARIA属性は誤りを取り消したり修正したりする機能を作るものではなく、画面上の情報や状態を支援技術へ伝えるための補助です。
エラー発生後は、キーボード操作だけでもエラー概要と各入力欄へ移動でき、修正後に同じ手順で送信を再開できるか確認します。
実装前後のチェックリスト
- 対象の操作が、法的な約束、金融取引、利用者が管理するデータの変更や削除、試験解答の送信に当たるか。
- 三つの対応方法のうち、どれで誤操作を防ぐかを決めているか。
- 確認画面に、結果へ影響する項目が分かりやすく表示されているか。
- 確認画面から入力内容を修正でき、入力済みの値が失われないか。
- エラーの対象、原因、修正方法をテキストで示しているか。
- ボタン名から、押した後に何が確定するか分かるか。
- マウスを使わずに確認、修正、確定、取り消しを操作できるか。
- 画面拡大や読み上げ環境でも、エラーと確認内容を順序どおり把握できるか。
対応の要点
達成基準3.3.4への対応では、対象となる操作を特定し、取り消し、入力エラーの確認と修正、確定前の見直しのうち、少なくとも一つを実際の操作手順に組み込みます。
確認画面、明確なエラーメッセージ、入力値の保持、キーボード操作、支援技術への通知を一つの流れとして試験すると、利用者が誤りから回復できるかを判断しやすくなります。
当社では、ウェブアクセシビリティ対応を支援するUUU ウェブアクセシビリティウィジェットツールを提供しています。
ウェブサイトのアクセシビリティ向上を検討している方は、サービスの詳細をご覧ください。