inputmode属性は入力内容が決まったfieldへだけ指定する

inputmode属性は、form fieldへどのような入力方法を使うかをbrowserへ示すための属性です。電話番号、メールアドレス、URLのように、入力する内容が決まっているfieldで検討します。入力の形式を制限する属性でも、server側の入力確認を代わりに行う属性でもありません。

mobileのformでは、入力しやすさがそのまま問い合わせのしやすさに影響します。しかし、画面に数字用の入力方法が出たからといって、何を入力する欄かが明確になるわけではありません。fieldの目的、画面上の説明、入力の補助、送信後の確認を順にそろえます。inputmodeは、決まった目的をbrowserへ伝える補助です。

HTML 5.1 Candidate Recommendationは、inputmode属性をform controlの入力方法を示すものとして定めています。kana、katakana、numeric、tel、email、urlなどの値を扱います。この時点でinputmode属性はat-risk featureにも含まれるため、指定だけで動作を決めつけず、対象browserで確認します。

入力内容と入力方法を分ける

問い合わせformでは、fieldへ何を書いてもらうかを先に決めます。入力内容が曖昧なままinputmodeを選ぶと、利用者が見るlabelとbrowserが示す入力方法がずれます。入力方法を先に選んで、あとからfieldの意味を合わせる順序にはしません。

たとえば、fieldのlabelが「ご連絡先」だけなら、電話番号とメールアドレスのどちらを入れるか決まりません。このfieldへinputmode="tel"を付けても、入力内容を説明したことにはなりません。電話番号を受け取るならlabelを「電話番号」とし、メールアドレスを受け取るなら別のfieldに分けます。

数字だけを入力してほしいfieldでも、数字用の入力方法を出せばよいとは限りません。郵便番号、電話番号、注文番号、人数では、桁数、記号、先頭のゼロを扱う必要が異なります。まず、利用者に何を書いてもらい、受信側が何に使うかを決めます。入力方法は、その内容に合うかを確認してから選びます。

用途が決まらないfieldへinputmodeを付けると、利用者に余計な制限を感じさせることがあります。自由に相談内容を書く欄、住所の補足、備考のように文字を入力するfieldは、電話番号と同じ補助にはしません。formを入力しやすくするために、各fieldを同じ形へそろえる必要はありません。

input typeを選んでから補助の指定を考える

電話番号を受け取るfieldでは、まずtype="tel"を使うかを考えます。メールアドレスやURLにも、それぞれ対応するinput typeがあります。inputmodeは、fieldの目的を決める前に付けるものではありません。

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

この例は、fieldの用途と入力方法をそろえるための仮例です。inputmodeを付けても、存在しない電話番号や誤ったメールアドレスを受け取らないとは限りません。必要なfieldだけに絞り、送信後に受信内容を確認する仕組みを残します。

inputmodeがあることと、input typeを適切に選んだことも別です。見た目の入力方法だけを合わせて、typeやnameを曖昧にすれば、送信されたdataを扱う側が困ります。label、input type、name、inputmode、受信画面の項目名を対応させます。fieldの一つを変えたら、画面と受信後の両方を確認します。

browserが表示する入力方法は、利用者への補助です。誤った値を必ず止める仕組みではありません。電話番号のfieldに文字列が入る、email addressのfieldが空欄のまま送られる、といった場合をどう扱うかは、必須設定とserver側の確認で別に決めます。attributeを足したことで、受信後の検査を省かないことが必要です。

実機で入力から送信まで確認する

入力方法は、source上のattributeだけで評価しません。mobile端末でformを開き、利用者が迷わず入力して送れるかを確かめます。

1. fieldごとに、受け取る内容を一文で決める。
2. labelとinput typeを対応させる。
3. 入力方法が明確なfieldだけへinputmodeを指定する。
4. mobile端末で入力し、表示される入力方法を確認する。
5. 送信後に受信したdataを確認する。
6. fieldの目的、確認した端末、変更日、承認者を記録する。

実機で確認するときは、入力画面が出るかだけで終えません。labelを見て何を書くか分かるか、入力方法がfieldの内容に合うか、送信buttonまで進めるか、送信後に受信内容が分かるかを順に見ます。formの途中で別pageへ移ったり、入力をやり直したりする場合は、利用者が戻れるかも確認します。

formの修正を外部へ頼む場合も、どの情報を受け取るか、受信先はどこか、送信を誰が確認するかはsite側で決めます。入力を補助する設定を頼むことと、問い合わせを受け取れる状態を確認することは別です。依頼するときは、対象field、期待する入力、確認する端末、受信後に見る項目を渡します。実装した人だけでなく、受付する人も受信内容を確認します。

最初の一手は、電話番号やメールアドレスのように用途が決まっているfieldを一つ選び、mobile端末で入力から送信まで試すことです。fieldの意味が決まらない項目へ、先にattributeを足しません。利用者の入力を助けることと、事業者が必要な情報を受け取ることを、同じ確認で確かめます。