textareaとselectのautocomplete属性は入力内容でなくfieldの目的を示す

問い合わせformや配送先入力でautocomplete属性を使うときは、browserへ「このfieldにはどんな種類の情報が入るか」を示します。入力欄を必須にする属性でも、入力値を検査する属性でもありません。住所を一つの複数行fieldへ入れるならtextareaへ住所の目的を示し、都道府県や国を選ばせるならselectへ選択の目的を示します。自由記入の相談内容や、担当者だけが読む確認事項まで、住所や氏名と同じように自動入力させる対象として扱わないことが大切です。

Chromium Blogは3月21日、Chrome 66 Betaでtextarea要素とselect要素がautocomplete属性をsupportすると案内しました。HTML 5.2は、autocomplete属性をbrowserがform入力を補助するためのhintとして定義し、input、select、textareaへfieldの目的を示せるようにしています。たとえば住所全体にはstreet-address、郵便番号にはpostal-code、都道府県のような広い行政区分にはaddress-level1というfield nameがあります。 W3C HTML 5.2

必須入力と入力補助は同じ設定ではない

formには似た役割の属性があるため、先に仕事を分けます。requiredは、送信前に入力を求めるfieldを決めます。typeは、emailやtelephone numberのような入力の形式を示します。autocompleteは、browserが保存済みの情報を提案または補完するとき、そのfieldが何を受ける場所かを理解する手掛かりになります。

たとえば、資料請求formで郵便番号を必須にするなら、requiredを付けるかを、発送に本当に必要かどうかで決めます。郵便番号のfieldへautocomplete="postal-code"を付けるかは、そこが郵便番号を受けるfieldかどうかで決めます。一方を付けたから、もう一方が不要になるわけではありません。送信に必要な情報を減らす判断と、browserへfieldの目的を伝える判断を混ぜないようにします。

ここを混ぜると、formが長くなります。「自動入力に対応するため」という理由で、仕事に使わない住所や電話番号まで必須にしてはいけません。反対に、発送や訪問の日程調整で住所が必要なのに、入力補助だけを理由に任意項目へ変えることもありません。先に、何のために取得するか、誰が使うか、送信後にどこへ保存するかを決めます。そのうえで、必要なfieldだけへ目的に合うattributeを付けます。

textareaへ付けるのは住所のように目的が決まる文章である

textareaは長い文章を入れられるため、全ての複数行入力欄へ同じautocomplete値を付けたくなります。しかし、相談内容、質問、希望日時、自由記入欄の内容は、browserに保存された住所や氏名とは別の情報です。何を自動入力するfieldなのかを一意に決められない自由記入欄では、目的を無理に住所へ寄せません。

複数行の住所を一つのfieldで受ける場合は、textareaへautocomplete="street-address"を付ける候補になります。W3C HTML 5.2では、street-addressを住所全体のfield nameとして示しています。住所を一行ずつ分けるformなら、address-line1、address-line2、address-line3のように、各fieldが何を受けるかを分けます。画面で「建物名、部屋番号」と書いているfieldへ、住所全体を受ける値を付ければ、browserの補助と画面の説明が食い違います。

仮に、イベントの申込みformに「送付先住所」と「連絡事項」の二つのtextareaがあるとします。送付先住所は、印刷や発送に使う住所を一つの欄で受けるなら、住所として扱えます。連絡事項は、到着時間の希望や質問などを自由に書く欄です。二つとも文字を複数行で入れるからといって、同じautocompleteを付ける理由にはなりません。HTMLの要素名ではなく、受け取る情報の目的で決めます。

selectへ付ける前に選択肢が表す内容を確かめる

selectへautocompleteを付ける場合も、選択肢の見た目ではなく、選んだ値の意味を確認します。都道府県を選ぶselectなら、住所の行政区分を受けるfieldとして考えられます。国を選ぶselectなら、国名または国codeのどちらを送るかを先に決めます。画面に同じ「地域」というlabelがあっても、営業担当を振り分ける地域、配送先の住所、興味のある商品分類では、意味が違います。

配送先の都道府県を選ばせるselectと、問い合わせの内容を選ばせるselectを同じ扱いにしないでください。前者は住所の一部です。後者は、営業やサポートが最初に読む分類です。問い合わせ種別へ住所用のfield nameを付けても、browserの入力補助と業務上の分類が一致しません。選択肢を増やす作業と、autocompleteを付ける作業も別です。

同じformに請求先と配送先が並ぶ場合は、どちらの住所かを画面のlabel、fieldsetの見出し、送信後のdataで区別します。HTML 5.2ではshippingやbilling、section-から始まるtokenを、同種のfieldを区別するために組み合わせられます。複数の住所を受ける必要がないsiteで、見本どおりのtokenを増やす必要はありません。二つ以上の住所を実際に扱うときだけ、browserへ区別を伝える必要があります。

attributeを足した後は送信内容と画面を同時に確認する

autocompleteを追加しても、formの送信先や保存するdataは自動では決まりません。属性を付けた後に確認するのは、browserが候補を出すかだけではありません。入力した値がfieldのlabelと一致しているか、送信後のmailや管理画面でどの項目として読めるか、担当者が必要な情報だけを受け取るかを見ます。

まず、一つのformを選び、各fieldのlabel、name、type、required、autocompleteを同じ表へ書き出します。次に、住所、氏名、mail address、電話番号のように目的が明確なfieldだけを選びます。自由記入欄、内部用の分類、確認用のcheckboxは別に残します。この手順なら、attributeを増やすために個人情報の取得項目を増やさずに済みます。

browserの対応は同じ時点でも環境で違うため、Chrome 66 Betaの案内だけを理由に公開中のformを一度に替えません。対象browserで入力、選択、送信、error表示を試します。autocompleteが働かない環境でも、labelを読み、手で入力し、送信できることがformの基本です。入力補助は、必要な情報を少ない手間で渡せるようにする補助として使います。

textareaとselectへautocompleteを付けるときは、最初にfieldの目的を言葉で説明できるか確かめます。住所のように目的が定まるfieldには、その内容に合うfield nameを付けます。相談内容や業務上の分類には、無理に住所や氏名のtokenを当てません。最後に公開画面と送信後のdataを見れば、browserの補助と実際の受付を同じ形に保てます。