WCAG 2.2の達成基準3.3.7「冗長な入力項目」は、同じ手続きの中で一度入力または提示された情報を、利用者にもう一度打ち直させないためのレベルA基準です。
同じ情報が再び必要になる場合は、値を自動入力するか、利用者が以前の値を選べるようにします。
基準の位置づけを先に確認したい場合は、WCAG 2.2で追加された達成基準の全体像もあわせて確認してください。
達成基準3.3.7が求めること
同一のプロセスとは、一つの目的を完了するために必要な一連の操作です。
たとえば、商品の選択から配送先、支払い、注文確定へ進む購入手続きは、一つのプロセスとして扱います。
| 区分 | 確認する内容 |
|---|---|
| 対象 | 利用者が以前に入力した情報、または利用者に提示された情報を、同一のプロセス内で再び入力させる場面 |
| 必要な対応 | 以前の値を自動入力するか、利用者が選択して再利用できるようにする |
| 例外 | 再入力が必要不可欠な場合、コンテンツのセキュリティ確保に必要な場合、以前の情報が無効になった場合 |
基準の原文に沿った日本語は、WCAG 2.2日本語訳の達成基準3.3.7で確認できます。
目的、適用範囲、事例は、W3Cの達成基準3.3.7解説書に整理されています。
対象になる場面と対象にならない場面
この基準が対象とするのは、同じ活動を完了するまでの重複入力です。
セッションを閉じた後の再訪まで、以前の情報を保存することを求める基準ではありません。
一方で、購入手続きの途中で外部の決済画面へ移る場合のように、画面やドメインが変わっても一つの活動が続いていれば、同一のプロセスとして確認します。
| 場面 | 利用者に求める操作 | 改善例 |
|---|---|---|
| 請求先住所と配送先住所が同じ | 同じ住所を再入力する | 「請求先住所を配送先にも使用する」を選べるようにする |
| 入力エラー後にフォームへ戻る | 正しかった項目まで入力し直す | 以前の値を保持し、誤りのある項目だけ修正できるようにする |
| 前のステップで会員番号が提示された | 番号を記憶して入力する | 番号を自動入力するか、画面上から選択できるようにする |
重複入力を防ぐ実装方法
実装方法は一つではありませんが、利用者が記憶と再入力に頼らずに手続きを続けられる状態を作ります。
フォーム全体の入力支援を見直す場合は、フォームの入力支援とエラー設計の基本も参考になります。
同じ情報を二度求めない
確認だけが目的なら、以前の値を表示し、必要な場合だけ編集できるようにします。
入力欄を増やす前に、再入力そのものを省けないかを検討します。
以前の値を自動入力する
前のステップで入力された値を次の入力欄へ引き継ぎ、利用者が必要に応じて変更できるようにします。
<label for="shipping-name">配送先氏名</label>
<input
id="shipping-name"
name="shipping_name"
value="{{ previous_name }}"
>
この例の値は、前のステップで受け取った情報をアプリケーション側で設定する想定です。
以前の値を選べるようにする
請求先住所を配送先住所として使う場面では、同じ情報を再入力させず、チェックボックスなどで適用できるようにします。
<label>
<input type="checkbox" name="use_billing_address" value="1">
請求先住所を配送先住所として使用する
</label>
選択肢には、何が再利用されるのかが分かるラベルを付けます。
ブラウザーの自動入力だけに依存しない
autocomplete属性は入力支援に役立ちますが、この達成基準が求めるのは、ウェブサイト側が同一プロセス内の以前の値を利用できるようにすることです。
ブラウザーが過去の入力候補を出すことだけを、達成基準3.3.7への対応にはできません。
保存方法とデータ保護
達成基準3.3.7は、セッションストレージやローカルストレージなど、特定の保存技術を指定していません。
サーバー側のセッション、アプリケーションの状態管理、ページ間の安全なデータ受け渡しなどから、構成に合う方法を選びます。
個人情報や決済情報を扱う場合は、再入力を減らすことだけで保存範囲を決めず、情報の機密性、保存期間、既存のセキュリティ方針を確認してください。
三つの例外をどう判断するか
再入力が必要不可欠な場合
以前の答えを提示すると活動そのものが成立しなくなる場合は、再入力が例外として認められます。
実装上の都合だけで再入力させる場面は、この例外に含めません。
コンテンツのセキュリティ確保に必要な場合
パスワードの確認など、情報を表示または再利用するとセキュリティ上の目的を損なう場面が該当します。
「セキュリティのため」という説明だけでフォーム全体を例外にせず、再入力が必要な項目を限定します。
以前の情報が無効になった場合
有効期限切れなどによって以前の値を使えない場合は、新しい情報の入力を求められます。
無効な値をそのまま再利用できるようにする必要はありません。
よくある失敗と改善方法
| 失敗 | 改善方法 |
|---|---|
| 同じ住所や識別番号を別のステップで再入力させる | 前の値を引き継ぐか、再利用する選択肢を設ける |
| ブラウザーの自動入力が動くことだけを確認する | サイト側で以前の値を提供できるかを確認する |
| 入力エラー後に正しい項目まで消去する | 有効な値を保持し、修正が必要な項目を明確にする |
| ローカルストレージへの保存を一律に採用する | 情報の性質と保存期間に応じて保存方法を選ぶ |
| 「セキュリティ」を広い例外として扱う | 再入力が必要な情報と理由を項目ごとに確認する |
適合を確認する手動テスト
この基準は複数画面の流れと項目同士の関係を確認するため、自動検査だけでは適合を判断できません。
- 購入、申請、登録など、確認するプロセスの開始地点と完了地点を決めます。
- 各ステップで利用者が入力する情報と、サイトから利用者へ提示される情報を一覧にします。
- 同じ情報を再び求める項目がないか、通常経路、入力エラー後、前の画面へ戻った場合を確認します。
- 再入力が必要な場合は、以前の値が自動入力されるか、利用者が選択できることを確認します。
- 選択や編集をキーボードでも行え、ラベルから再利用される情報を理解できることを確認します。
- 例外を使う項目は、必要不可欠、セキュリティ、情報の無効化のどれに当たるかを記録します。
- 外部サービスへ移動する経路も、一つの活動が続く場合はプロセスの終点まで確認します。
自動検査と手動確認の役割分担は、ウェブアクセシビリティチェックの進め方で詳しく解説しています。
実装前の確認事項
- 同一プロセス内で同じ情報を二度求めていないかを確認します。
- 再び必要な値は、自動入力または選択によって利用できるようにします。
- 入力エラーや前画面への移動があっても、有効な値を不用意に消去しません。
- 例外は項目ごとに理由を確認し、適用範囲を限定します。
- 保存技術を先に決めず、扱う情報とプロセスに合う方法を選びます。
当社では、ウェブアクセシビリティの導入と改善を支援するUUU ウェブアクセシビリティを提供しています。
フォームの重複入力や入力支援を見直したい場合は、サービスの詳細をご覧ください。
