WCAG 3.3.7: 冗長な入力

このルールの意味

WCAG 3.3.7 Redundant Entry（冗長な入力）は、WCAG 2.2 で新たに導入されたレベル A の達成基準です。そこでは次のように定義されています。「同一のプロセス内で再度入力することが求められる、ユーザーが以前に入力した、またはユーザーに提供された情報は、自動入力されるか、ユーザーが選択できる形で提供される。」 平たく言えば、ユーザーがセッション中に一度メールアドレス、配送先住所、生年月日、その他の情報を入力したのであれば、同じプロセスやフローの中で再度それを入力させてはならない、ということです。

この達成基準は、複数ステップのフォーム、チェックアウトプロセス、登録ウィザード、予約フローなど、あるステップで収集したデータが後続のステップで再度必要になるあらゆるシーケンスに広く適用されます。対象となる挙動には、テキスト入力、ドロップダウン、チェックボックス、ラジオボタン、その他ユーザーがデータを入力するあらゆるフォームコントロールが含まれます。同じ情報が再度必要になる場合、そのフィールドは以前に提供された値で自動的に事前入力されるか、ユーザーが再入力ではなく確認できるように選択肢として提示されなければなりません。

この達成基準に適合している例としては、前の画面でユーザーが入力した配送先住所で請求先住所フォームが事前入力されているケースや、確認ステップでユーザーが以前入力したメールアドレスが読み取り専用フィールドとして表示されるケースが挙げられます。もう一つの適合パターンは、「請求先住所は配送先住所と同じです」とラベル付けされたチェックボックスで、チェックすると値が自動的にコピーされるものです。不適合の例としては、ステップ 1 でメールアドレスを尋ね、ステップ 3 でも事前入力なしで再度メールアドレスを求める複数ステップの登録フローや、請求者の氏名と証券番号を複数の画面で繰り返し入力させる保険金請求フォーム（自動入力がない場合）などがあります。

WCAG 3.3.7 には公式な例外が 2 つ定義されています。1 つ目の例外は、情報を再入力することがプロセスにとって本質的である場合に適用されます。たとえば、「新しいパスワードを確認」フィールドは、タイプミスを防ぐために意図的に同じパスワードを 2 回入力させるものであり、本質的なセキュリティチェックと見なされます。2 つ目の例外は、以前入力された情報がもはや有効ではない場合に適用されます。たとえば、セッションが期限切れになった、あるいは商品が在庫切れになり、ユーザーが新しいデータでプロセスをやり直さなければならない場合などです。これらの例外に該当しない限り、冗長な入力は適合違反となります。

なぜ重要か

冗長な入力は、入力が遅い、痛みを伴う、ミスが多い、あるいは認知的に負担が大きいユーザーに不釣り合いな負担を強います。誰が影響を受けるのかを理解することで、開発者やデザイナーはこの達成基準が単なる利便性の問題ではなく、多くの人にとって実際の障壁であることを認識できます。

運動障害のあるユーザー（振戦、脊髄損傷、ALS や多発性硬化症などの疾患を持つ人など）は、スイッチアクセス、マウススティック、視線追跡ソフトウェア、音声コントロールなどに頼ってテキストを入力している場合があります。こうしたユーザーにとって、短い住所であっても入力には数分と大きな身体的負担がかかることがあります。その入力を繰り返すことを求めるのは、単に迷惑というレベルではなく、身体的な痛みを引き起こしたり、1 回のセッションでは事実上タスクの完了を不可能にしたりすることがあります。

認知障害のあるユーザー（ディスレクシア、注意欠如障害、外傷性脳損傷、認知症関連の状態など）は、3 ステップ前に何を入力したかを覚えておくことが難しい場合があります。記憶や紙の書類から同じ情報を何度も正確に書き写すことは、エラー率と離脱率を大幅に高めます。世界保健機関によると、世界で 10 億人以上が何らかの障害とともに生活しており、その中でも認知障害はアクセシビリティ計画において最大かつ最も支援が行き届いていないセグメントの一つです。

上肢に差異のあるユーザー（先天的または後天的に上肢に差異のある人など）は、入力速度が非常に遅く、代替入力デバイスを使用している場合があります。必要なキー入力が 1 回増えるごとに、これらのユーザーへの負担は何倍にもなります。

現実のシナリオを考えてみましょう。関節リウマチのあるユーザーが、病院のオンラインポータルで診療予約を行っています。画面 1 では、国民 ID 番号、氏名、生年月日、連絡先電話番号を入力します。画面 3 でポータルは、患者記録を確認するために再度氏名と生年月日を求めます。このユーザーは、わずか 2 画面前に提供した情報を苦労して再入力しなければならず、記録の不一致を招くタイプミスのリスクを負い、不要な身体的負担を強いられます。これらのフィールドを単純に事前入力または自動入力するだけで、この障壁は完全に取り除くことができます。

アクセシビリティの観点だけでなく、冗長な入力を排除することは、コンバージョン率の向上、フォーム離脱の減少、データ入力ミスに起因するサポート問い合わせの削減にもつながり、インクルーシブデザインと同時に測定可能なビジネス価値をもたらします。

関連する Axe-core のルール

WCAG 3.3.7 は手動テストを必要とする達成基準です。現在、冗長な入力の違反を確実に検出できる自動 axe-core ルールは存在しません。これは、自動ツールが、動的なプロセスにおいて複数のステップやページにわたって入力されたデータ同士の意味的な関係を理解できないためです。ツールは、前のステップでどの情報が収集されたか、現在のステップでどの情報が求められているか、そしてそれら 2 つの情報が論理的に同一かどうかを認識できません。同じデータが事前入力なしに 2 回要求されているかどうかを観察・評価できるのは、完全なフローを実際にたどる人間のテスターだけです。

• 手動テストが必要（WCAG 2.2 の新項目）: axe-core やその他の自動アクセシビリティスキャナーは、一度に 1 つのページ状態の DOM を解析します。これらのツールは、複数のページロードやフォームステップにわたるユーザー入力値を追跡できず、ステップ間でフィールドラベルを比較して意味的な重複を特定することもできず、事前入力メカニズムが正しく機能しているかどうかを評価することもできません。テスターは複数ステップのプロセスを手動でたどり、各ステップで入力したデータを記録し、後続の各ステップで、以前提供したデータが自動入力されているか、または選択可能になっているかを確認する必要があります。3.3.7 の違反を自動的に検出できると主張するツールは、極めて高い偽陰性率を生むことになり、唯一のテスト手段として頼るべきではありません。

テスト方法

1. 出発点としての自動スキャン: 複数ステッププロセスの各ステップごとに、axe DevTools、Lighthouse、または Accsible auditor を実行します。これらのツールは 3.3.7 の違反を直接は検出しませんが、autocomplete 属性の欠如、ラベルのないフォームフィールド、その他しばしば同時に発生する 3.3.x の達成基準の問題など、関連する課題を洗い出します。各ステップで見つかったすべてのフォームフィールドを記録します。
2. ステップ間のデータ要件をマッピングする: 手動テストの前に、プロセスの各ステップと、そのステップで収集するすべてのデータフィールドを一覧にした簡単な表やスプレッドシートを作成します。そのうえで、複数のステップに現れるフィールドラベルやデータタイプを特定します。このマッピング作業により、ブラウザを開く前から候補となる違反箇所を洗い出すことができます。
3. 手動ウォークスルー — デスクトップ: 標準的なマウスとキーボードを使って、複数ステッププロセス全体（例: チェックアウト、登録、請求の送信）を完了します。すべてのフィールドに現実的な値を入力します。マッピングで重複フィールドとして挙がっているステップに到達したら、そのフィールドが以前の入力で事前入力されているか、以前の入力を提示する選択肢が用意されているかを確認します。どちらもない場合は不適合として記録します。さらに、スクリーンリーダー（Firefox + NVDA、Chrome + JAWS、Safari + VoiceOver）を使って同じテストを繰り返し、事前入力された値が正しく読み上げられること、以前入力した値を選択するためのコントロールにキーボードで到達できることを確認します。
4. 手動ウォークスルー — モバイル: iOS（VoiceOver + Safari）と Android（TalkBack + Chrome）で同じフローを完了します。アプリケーションがネイティブの autocomplete や自動入力機能を抑制していないかに注意してください。これらが抑制されていると、開発者が autocomplete で支援する意図があっても、結果的に冗長な入力の障壁を生む可能性があります。
5. 例外のテスト: 意図的に重複入力を求めているフィールド（例: パスワード確認、メールアドレスの再入力）を特定します。これらが WCAG の例外における本質的なセキュリティまたは検証チェックに該当するかを確認し、単に削除または事前入力すべき冗長なフィールドではないことを検証します。
6. autocomplete を無効にした状態でのテスト: 一部のユーザーはプライバシー上の理由からブラウザの autocomplete を無効にしています。ブラウザの autocomplete をオフにした状態でも、アプリケーション独自の事前入力メカニズム（サーバーサイドまたは JavaScript 駆動）が正しく機能し、ブラウザの挙動に依存せずに達成基準を満たしていることを確認します。

修正方法

複数ステップのチェックアウト — 2 画面で同じ住所が必要 — 不適切な例

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

複数ステップのチェックアウト — 2 画面で同じ住所が必要 — 適切な例

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

登録ウィザードが正当な理由なくメールアドレスを 2 回尋ねる — 不適切な例

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

登録ウィザード — セッションデータからメールアドレスを事前入力 — 適切な例

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

予約フォーム — サマリーステップで再度患者情報を尋ねる — 不適切な例

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

予約フォーム — 生年月日を読み取り専用の確認として表示 — 適切な例

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

よくある間違い

• 複数ステップのフォームを、セッション状態を共有しない独立したページとして構築してしまい、前のステップで入力された値を引き継ぐ仕組みが存在しないこと。これは 3.3.7 の不適合を招く最も根本的なアーキテクチャ上の誤りです。
• 「配送先と同じ」チェックボックスを用意しているにもかかわらず、チェックされても実際には請求先フィールドを自動入力しないために、ユーザーが一致させる意思を示した後でも住所を手入力しなければならないこと。
• ページ読み込み時にフィールドを事前入力しておきながら、バリデーションエラー時にそれらをクリアしてしまうことで、後続ステップでミスをしたユーザーが修正のために戻った際、以前提供したすべてのデータを再入力しなければならなくなること。
• セッションデータを安全でない方法で保存してしまい、そのセキュリティ問題を修正する代わりにセッション保存自体を無効化してしまうことで、事前入力の体験が壊れ、結果として 3.3.7 の不適合となること。
• パスワード確認の例外を口実にして、ユーザーにメールアドレスを再入力させることを正当化してしまうこと。メールアドレスの確認は本質的なセキュリティチェックではなく、WCAG の例外には該当しません。
• サーバーサイドレンダリングされたフォームで、引き継いだ値を hidden input で送信しないために、ユーザーがブラウザの戻る・進むボタンでステップ間を移動した際に事前入力された値が失われてしまうこと。
• この達成基準を満たす手段としてブラウザの自動入力機能だけに頼り、アプリケーションレベルの事前入力を実装しないこと。プライバシー上の理由で自動入力を無効にしているユーザーには、その場合適合した経路が存在しなくなります。
• フィールドを事前入力しておきながら、readonly ではなく disabled を設定してしまうことで、多くのブラウザでその値がフォーム送信から除外され、プロセスが壊れ、再入力を強いる可能性があること。
• Dragon NaturallySpeaking のような音声入力ソフトを使うユーザーとともに、エンドツーエンドのフローをテストしないこと。冗長なフィールドがあると、同じ音声ディクテーションコマンドを何度も繰り返す必要が生じ、開発者テストでは見落とされがちな大きな負担となります。
• この達成基準を住所フィールドにのみ適用されるものとみなしてしまうこと。実際には、氏名、電話番号、国民 ID 番号、証券番号、日付、その他同一プロセス内で 2 回以上求められるあらゆるユーザー提供情報に等しく適用されます。

トルコのアクセシビリティ規制との関係

トルコの大統領通達 2025/10 は、2025 年 6 月 21 日付官報（No. 32933）で公布され、トルコで事業を行う幅広い公的・民間主体に対してウェブアクセシビリティ適合を義務付けています。WCAG 3.3.7 Redundant Entry は WCAG 2.2 におけるレベル A の達成基準であり、この通達の下ではレベル A の適合が必須のベースラインとされています。これは、対象となるあらゆる主体が運営するウェブサイト、ウェブアプリケーション、デジタルサービスにおいて、同一プロセス内でユーザーにすでに提供した情報の再入力を求めてはならないことを意味し、例外は認められません。違反した場合は不適合のリスクを負うことになります。

この通達では段階的な実施スケジュールが定められており、公的機関は通達の公布から1 年以内に適合を達成しなければならず、対象となるカテゴリの民間企業には2 年の猶予が与えられています。

通達の対象となる主体の種類は広範で、電子商取引プラットフォームおよびマーケットプレイス、すべての公的機関および政府機関、銀行および金融サービス提供者、公立・私立の病院およびヘルスケアポータル、20 万人以上の加入者を持つ通信会社、認可を受けた旅行代理店、民間の交通事業者、国民教育省（MoNE）に認可された私立学校などが含まれます。これらすべての主体において、複数ステップのデジタルプロセス — たとえば EC サイトのチェックアウトフロー、病院ポータルでの患者登録、銀行プラットフォームでの口座開設、学校ウェブサイトでの入学申込フォームなど — は、冗長な入力が一切存在しないよう監査・修正されなければなりません。

実務上、この規制により、トルコのデジタル経済全体で、調達、プロダクト、法務チームのスコープに WCAG 3.3.7 への適合が明確に含まれることになります。たとえば、複数ステップのチェックアウトを提供しているトルコの EC プラットフォームが、ある画面で配送先住所を、次の画面で請求先住所を求めながら、事前入力やコピーのオプションを提供していない場合、これは WCAG 2.2 レベル A と大統領通達の双方に対する明確な違反です。同様に、患者に対して複数の画面で身分証番号や生年月日の再入力を求める国立病院の予約ポータルも不適合となります。通達の対象となる組織は、適合ロードマップの一環として、すべての複数ステッププロセスのエンドツーエンドの監査を優先し、冗長な入力の排除を任意の改善ではなく必須のエンジニアリングタスクとして扱うべきです。