この記事でわかること

  • 申し込みなど段階のある手続きで、同じ情報を二度聞かないことを求めるWCAGの達成基準3.3.7
  • 前の段階の情報を「入れておく」作り方と「選べるようにする」作り方
  • もう一度入れてもらってよい例外と、ブラウザの自動入力では足りない理由
  • 請求先を「お届け先と同じ」で入れる例と、作業PCのブラウザで試した結果

お届け先の住所を入れた後に、請求先の欄で同じ住所をまた打ち込ませるフォームがあります。前に何を入れたかを覚えておくことが難しい人には、これが大きな負担になります。この記事では、すでに受け取った情報を利用者にもう一度入力させない作り方を整理します。

基準と技法の説明は、W3CのWCAG 2.2の本文、Understanding、技法G221を、2026年10月26日にそれぞれ原文で読んで書きました。HTMLの例は作業PCのブラウザで開き、キーボードで操作して入力欄の値を確かめました。

先に結論: 前の段階で受け取った情報は、入れておくか選べるようにする

先に結論を書くと、同じ手続きの中で、前に入れてもらった情報をもう一度求めるときは、その値を最初から入れておくか、利用者が選べるようにします。 入れた値は、利用者があとから直せる形にしておきます。W3Cの資料に出てくる場面と作り方は、次の表のとおりです。

場面 作り方
請求先と配送先 「同じ」のチェックで入れる
確認の段階 前のIDを入れて直せる
入力エラーの後 送った値を消さない
検索の結果 検索語を入れておく
前の段階で出た番号 次の段階に入れておく
パスワードの確認 例外にできる

同じ情報の再入力に関わるアクセシビリティの基準

WCAG 2.2の達成基準3.3.7(Redundant Entry)は、レベルAの基準で、WCAG 2.2で新しく加わりました。同じ手続きの中で、利用者が前に入れた情報や利用者に示した情報を、もう一度入れてもらう必要があるときは、自動で入れておくか、利用者が選べるようにすることを求めています。

ここでいう手続き(process)は、WCAGの用語の定義で、1つの作業を終えるために、どれも欠かせない一連の操作とされています。たとえば、商品を選び、注文を送り、配送先と支払いの情報を入れる、といった一続きの流れです。

W3Cの解説では、この基準のねらいを、段階のある手続きを最後までやり遂げられるようにすることだとしています。前に入れた情報を思い出させると、途中であきらめたり、同じ情報をまちがえて入れ直したりすることがあるとしています。スイッチや音声で入力する人にとっても、打つ文字が減ることが助けになると書かれています。

「入れておく」と「選べるようにする」の違い

自動で入れておく(auto-populated)のは、前の段階の値を、入力欄にあらかじめ入れた状態で出す作り方です。W3Cの解説の例では、パソコンを買う手続きの最初の段階で社員のIDを入れてもらい、3つ目の段階では、そのIDを入れた状態で確かめてもらいます。IDは変えることもできます。

選べるようにする(available for the user to select)は、利用者の操作で値を入れられる形です。W3Cの解説では、決まったやり方は定めていないとしたうえで、次のような例を挙げています。

  • ドロップダウンなどから選んで、欄に入れられるようにする
  • ページに出ている文字を選んで、入力欄に写せるようにする
  • チェックボックスで、前に入れたのと同じ値を入れる(請求先の住所は配送先と同じ、など)

選べるようにする情報は、同じページにある必要があります。W3Cの解説では、最初から見えていて、その値を使う入力欄の近くにあるのが望ましいとしています。

ブラウザの自動入力では足りない

入力欄にautocomplete属性を付けると、ブラウザが保存した値を提案できます。ただし、W3Cの解説では、この基準にはブラウザの自動入力では足りないとしています。前に入れた情報を出すか、同じことを聞かないようにするのは、Webサイトの側の役目だからです。autocompleteの付け方は、Webデザインで入力フォームにautocompleteを付ける方法で紹介しています。

一方で、この基準は、セッションをまたいで情報を保存することまでは求めていません。セッションを閉じてから戻った場合や、別のページへ移って戻った場合には当てはまりません。ただし、手続きは別のドメインにまたがることがあり、買い物の手続きの中に外部の決済サービスが入る場合も対象になるとしています。

もう一度入れてもらってよい例外

達成基準3.3.7には、3つの例外があります。

  • 入れ直すこと自体が欠かせない場合: 前の答えが出てしまうと成り立たない、記憶のゲームなど
  • コンテンツのセキュリティを守るために必要な場合: パスワードの文字列を見せない、写させない、など
  • 前に入れた情報が、もう有効でない場合: そのときは、もう一度入れてもらってかまいません

パスワードについては、W3Cの解説で、表示されないパスワードを利用者に自分で作ってもらう場合に、確かめるためにもう一度入れてもらうことは例外として認められるとしています。

書き方の例: 請求先を「お届け先と同じ」で入れる

次のHTMLは、技法G221の例1(請求先の住所をもとに配送先の住所を入れるチェックボックス)を、日本のネットショップでよくある「お届け先」と「ご請求先」の形にして書いたものです。チェックを入れると、お届け先の名前と住所が、ご請求先の欄に入ります。入った値は、そのまま書き直せます。

<form method="post" action="/order">
  <fieldset>
    <legend>お届け先</legend>
    <label>お名前 <input id="ship-name"></label>
    <label>住所 <input id="ship-addr"></label>
  </fieldset>
  <fieldset>
    <legend>ご請求先</legend>
    <input id="same" type="checkbox">
    <label for="same">お届け先と同じ</label>
    <label>お名前 <input id="bill-name"></label>
    <label>住所 <input id="bill-addr"></label>
  </fieldset>
  <button type="submit">次へ</button>
</form>
<script>
  document.getElementById("same").addEventListener("change", (event) => {
    if (!event.target.checked) return;
    for (const key of ["name", "addr"]) {
      document.getElementById("bill-" + key).value =
        document.getElementById("ship-" + key).value;
    }
  });
</script>

チェックを外したときは、入った値を消さずに残しています。書き直した内容を失わないようにするためです。段階が別のページなら、前のページで受け取った値を、サーバー側で次のページの入力欄に入れておく形でも同じことができます。

手順: 段階ごとに同じ質問がないかを確かめる

技法G221の確かめ方に、W3Cの解説の例を加えた手順です。

  1. 段階を書き出す: 手続きの最初から最後まで、それぞれの段階で入力を求める欄を並べます
  2. 前に聞いていないかを見る: 欄ごとに、同じ情報を前の段階で求めていないか、利用者に示していないかを確かめます
  3. 入っているかを見る: 前に求めた情報なら、その値が欄に入っているか、同じページに表示されて選べるかを確かめます
  4. 直せるかを見る: 入っている値を、利用者が書き直せるかを確かめます
  5. まちがえて送る: わざと誤った値で送信し、エラーの後も、入れた値が消えずに残っているかを確かめます
  6. 例外を分ける: もう一度入れてもらう欄が残ったら、3つの例外のどれにあたるかを説明できるかを確かめます

試した結果

上のHTMLの例を、作業PCのChrome(ヘッドレス)で開き、キーボードの操作を送って、入力欄の値を読み取りました。お届け先には、架空の名前と住所を打ち込んでいます。

  • チェックを入れる前は、ご請求先の2つの欄は空でした
  • Tabキーでチェックボックスへ移り、スペースキーでチェックを入れると、ご請求先の2つの欄に、お届け先と同じ値が入りました
  • ご請求先の住所の欄を書き直すと、その欄だけが変わり、お届け先の住所はそのままでした
  • チェックを外しても、ご請求先の欄の値は消えずに残りました

あわせて、つまずきの書き方も試しました。ご請求先の欄にreadonlyを付けた形では、値は入りましたが、キーボードで打ち込んでも値は変わらず、書き直せませんでした。チェックボックスにlabelを付けず、文字だけを横に置いた形では、チェックボックスに名前が付かず、文字をクリックしてもチェックは入りませんでした。

使ったブラウザは、Mac の作業PCにある Google Chrome 155 を、画面を出さない形で動かしたものです。ブラウザの自動入力、画面読み上げソフト、ほかのブラウザでは試していません。

個人情報の扱いで気をつけること

W3Cの解説では、この基準は、プライバシーや個人を特定できる情報について、特別な決まりや例外を設けていないとしています。そのうえで、値を入れておく作り方をするときは、手続きの間に一時的に情報を持つ場合でも、データを守るよう求めています。作り方がよくないと、かえって個人情報がもれる原因になりうるとも書かれています。

どの情報をどこに、どれだけの間持つかは、運営する側が決めることです。法律で何が求められるかは、この記事の範囲の外とします。

自分で直すか、相談するかの判断

判断の目安は、「その値を、同じページの中で前の欄から写せるか」です。請求先と配送先のように、同じページにある欄どうしなら、上の例のようにチェックボックスと短いスクリプトで作れます。

段階が別のページに分かれている場合や、外部の決済サービスへ値を渡す場合は、情報の持ち方まで決める必要があります。そうした作りを変えるときは、サイトを作った人や講師と相談して進めます。

つまずきやすいところ

  • ブラウザの自動入力に任せる: autocompleteを付けても、この基準はサイトの側で値を出すことを求めています
  • 入れた値を直せなくする: readonlyなどで固めると、内容が違うときに利用者が困ります。W3Cの解説の例でも、入れたIDは変えられます
  • チェックボックスにラベルを付けない: 「お届け先と同じ」の文字は、label要素でチェックボックスと結びつけます。付け方は、Webデザインで入力フォームのラベルと説明を分かりやすくする方法で紹介しています
  • エラーの後に入力を消す: W3Cの解説の例では、カード番号をまちがえて送ってエラーが出ても、送った情報は消さずに残しています。エラーの伝え方は、Webデザインで入力エラーを分かりやすく伝える方法にまとめています
  • 例外を広く取りすぎる: もう一度入れてもらってよいのは、欠かせない場合・セキュリティに必要な場合・前の情報が有効でない場合の3つです

まとめ

  • WCAGの達成基準3.3.7は、同じ手続きの中で前に受け取った情報を、自動で入れておくか、選べるようにすることを求めています
  • 選べるようにする情報は同じページに置き、入れた値は利用者が直せる形にします
  • ブラウザの自動入力だけでは足りず、セッションをまたいだ保存までは求められていません
  • 欠かせない場合・セキュリティ・情報が有効でない場合は、もう一度入れてもらえます