autocomplete属性はformの必須入力を決めるのでなく各fieldの用途を示す

autocomplete属性は、問い合わせformの必須入力を決める属性ではありません。browserがfieldの用途を理解し、自動入力に使える情報を示すための属性です。入力欄の見出しを伝えるlabel、送信dataの名前を決めるname、入力が必要かを決めるrequired、server側の入力確認は、それぞれ別の役割を持ちます。

formで起きる問題を、属性だけで片付けようとしないことです。入力が面倒なら、最初に本当に必要なfieldかを考えます。何を書く欄か分からないなら、labelを直します。受信後に値を使うなら、server側で確認します。autocompleteは、そのうちbrowserへfieldの用途を伝える役割を持つものです。ほかの判断を省くものではありません。

HTML 5.1 Candidate Recommendationは、form controlの自動入力についてautocomplete属性を定めています。自動入力の仕組みは、この時点でat-risk featureにも含まれています。attributeを付けても、すべてのbrowserで同じ動作になるとは決めつけず、対象browserで入力と送信を確認します。

fieldの用途と入力条件を混同しない

問い合わせformでは、似たような属性を同じ目的で使いがちです。まず、利用者に何を入力してほしいかと、browserやserverへ何を伝えるかを分けます。fieldに何を置くか、画面でどう示すか、送信後にどう扱うかは、順番に決めます。

たとえば、表示上は「ご連絡先」とだけ書かれたfieldへautocomplete="email"を付けても、利用者が電話番号を入れるのかメールアドレスを入れるのか迷います。最初にfieldを分けるか、どちらを求めるか決めます。その後で、label、name、input type、autocompleteを対応させます。

会社名、担当者名、住所のようなfieldも、必要な理由を一つずつ決めます。返信に使わない住所を、名刺情報を自動入力できるからという理由で受け取る必要はありません。個人情報を集めるfieldが増えるほど、利用者は入力の理由を考え、受信する側は保管と確認の責任を持ちます。自動入力を使いやすくする前に、不要なfieldを増やしていないかを確認します。

一つのfieldへ複数の意味を持たせると、入力、受信、返信のどこかで困ります。「ご連絡先」に電話番号とemail addressのどちらでも入れられるようにすれば、受信した人はどちらの方法で返すか判断しにくくなります。必要なら電話とemailを別のfieldにし、片方だけを必須にするなど、受付の流れを先に決めます。autocompleteは決めた用途へ対応させます。

問い合わせformでは同じ意味のfieldを対応させる

名前、メールアドレス、電話番号を別に受け取るformなら、それぞれのfieldが何を示すかをそろえます。

<p>
  <label>お名前
    <input name="name" autocomplete="name">
  </label>
</p>
<p>
  <label>メールアドレス
    <input name="email" type="email" autocomplete="email">
  </label>
</p>
<p>
  <label>電話番号
    <input name="tel" type="tel" autocomplete="tel">
  </label>
</p>

この例は、fieldの用途を対応させるための仮例です。実際に必要な項目は、返信や受付に必要な情報から決めます。資料請求で住所が必要ないなら、auto-fillできるからという理由だけで住所欄を増やしません。入力項目が増えるほど、利用者がどこまで書くべきかを考える負担も増えます。

labelは、画面を読む人へ何を書く欄かを伝えます。nameは、送信したdataを受ける側が区別するために使います。input typeは、emailやtelephoneのように入力内容に合う形を示します。autocompleteは、browserの自動入力にfieldの用途を示します。requiredは、空欄のまま送信しようとしたときにbrowser側で確認します。それぞれが正しくても、受信後の内容が事業者にとって使えるかは、server側の処理と受信画面で別に確認します。

formを外部serviceやpluginが出力している場合も、この対応は必要です。画面上のlabelだけを変え、送信dataの名前や受信メールの項目名が古いままなら、対応する人が内容を読み違えます。外部の設定画面でautocompleteを選べても、fieldの追加、必須設定、受信先の変更を同じ意味だと思わないことです。実際の公開formと、受信する画面を両方開きます。

browserの補助と受付処理を別に確認する

autocompleteを加えた後は、入力が速くなることだけで完成にしません。browserが提案する値、画面に表示する項目、送信後に事業者が受け取る内容を確認します。

1. 問い合わせへ本当に必要な情報を決める。
2. fieldごとにlabel、name、input type、autocompleteを対応させる。
3. 必須項目にはrequiredを使い、server側でも受信dataを確認する。
4. 対象browserで入力し、項目の意味と送信結果を確認する。
5. 受信メールまたは管理画面で、項目名と入力内容が分かるか確認する。
6. 項目を変えた日と、formの承認者を記録する。

対象browserで試すときは、空欄のform、既に入力したform、browserが候補を出すformを分けて見ます。候補が出るかどうかだけでなく、候補を選んだ後にlabelと違う内容が入っていないか、送信後に項目が抜けていないかを確認します。auto-fillの動作はbrowserによって異なる可能性があるため、入力補助がなくてもformの意味と送信が成立するように作ります。

form制作を外部へ頼む場合も、入力項目の必要性、受信先、保存するdata、確認担当は事業者側で決めます。autocompleteの設定を任せることと、どの情報を受け取るかの判断を渡すことは別です。変更を依頼するときは、対象field、期待する入力、受信画面の確認方法を一緒に渡します。設定が終わった後は、依頼した人だけでなく実際に受信する人も内容を確認します。

最初の一手は、現在の問い合わせformで「返信に使うfield」を一つずつ書き出すことです。用途の決まらないfieldを減らしてから、残ったfieldへautocompleteを対応させます。browserの補助を加える前に、利用者が何を入力し、事業者が何を受け取り、誰が返信するかを一続きで確認します。