皆さん、フォーム作ってますか？
Webサイトやアプリを作るにあたって避けられないのがForm作成、多くの方が autocomplete を設定するなど、より使いやすいフォームを作成するために尽力されていることと思います。
一方で、悪気なく書いたコードでより使いにくいフォームになってしまっている例が世の中には多く見られます(特に銀行系)
今回は、よくあるフォームの実装を例に、(特に日本語話者にとって)より使いやすいフォームにするためのちょっとした仕様や私が考える対策を書いていこうと思います。
忙しい方のために最初に書いておくと、この記事に書いてあることの多くは autocomplete の仕様を意識した実装をしましょう の一言に集約されます。
多くの方にとっては「何を当たり前のことを」と思われる項目も多いかとは思いますが、当たり前のことがされていないフォームが世の中には多すぎるので、少しでも快適なインターネットにするためにこの記事を執筆している次第です。
今回例にするフォームは以下の要素を含むものを想定しています
- 名前
- 郵便番号
- 住所
- 日付
- 電話番号
名前入力
名前を入力させるとき、通常は以下のように書くと思います。
<input type="text" name="name" autocomplete="name" />
autocomplete="name" の指定により、ブラウザは名前を自動入力してくれますが、ここで日本語話者限定で使いにくくなりがちなポイントがあります。それがふりがな入力欄です。
名前を入力する際にふりがなも入力させるフォームは、特に銀行等のかっちりしたところに多いですが、このふりがな欄にも autocomplete="name" が指定されている場合が多いです。ブラウザの自動補完はブラウザごとに実装が違いますが、どのブラウザでも基本的にはふりがなは補完してくれません（日本語限定ですからね）。
フォームにふりがな入力欄を設ける場合、autocomplete 属性を省略するか、autocomplete="off" を指定しましょう。
<input type="text" name="name_furigana" autocomplete="off" />
郵便番号
よく見る郵便番号入力の問題として、以下があります。
- 属性が
numberになっている - ハイフンの前後で入力欄が分かれている
- ハイフンの有無どちらかしか受け付けない
属性が number になっている
「そんなのある？」と思われるかもしれませんが、（具体的なサービス名は控えますが）かなり利用者が多いであろうサービスでもいくらかあります。郵便番号の autocomplete 要素である postal-code は text 型の入力欄であるため、自動補完を適切に働かせるためにも type="text" を指定しましょう。
モバイル端末での入力時に数字キーボードを表示させたい場合は type="number" ではなく inputmode="numeric" を指定するようにしましょう。
<input type="text" name="postal_code" autocomplete="postal-code" inputmode="numeric" />
ハイフンの前後で入力欄が分かれている
郵便番号をハイフンの前後で別々の入力欄に分けているフォームも見受けられます（すごいものだと、それぞれか片方に autocomplete="postal-code" が指定されているものもありました）。自動補完が適切に働かないため入力の手間が増えますし、コピペなども使えなくなります。入力欄は前後で分けず、1つにまとめるようにしましょう。
ハイフンの有無どちらかしか受け付けない
郵便番号を入力する際、ハイフンを入れる人と入れない人がいます。どちらか一方しか受け付けないフォームは、ユーザーにエラーを強いることになり、ストレスの原因となります。先述した通り、postal-code は text 型であることもあり、ハイフンの入力は許容されるべきです。
ハイフンの有無にかかわらず受け付けるようにし、必要に応じて入力値を正規化しましょう。例えば、サーバーサイドでハイフンを除去したり、自動的にフォーマットを統一することで、ユーザーの負担を軽減できます。
住所の自動検索
前の項目とも被りますが、郵便番号を入力した際にシステム側で郵便番号から自動で住所を検索して補完してくれるサービスも多く見受けられます。住所入力の手間を省けるため大変便利ですが、ここでも体験を損なう要素があります。
それは郵便番号を入力した瞬間やEnterを押した瞬間に自動補完してしまうものです。こういった実装の場合、ブラウザの自動補完をシステム側の補完が上書きしてしまう場合があります。こういった挙動はユーザー視点でかなりストレスが溜まるので、ボタンを用意しておいて、押下した場合だけ補完をかけるような挙動のほうが良いかと思います。
住所入力
よく見る住所入力の問題として、以下があります。
- 都道府県の選択
- 住所フィールドの問題
都道府県の選択
都道府県を入力する際に、プルダウン式を採用しているページが多く見られます。しかし都道府県は47個もありますので、プルダウンで探すのは大変ですし、自動補完も効かなくなってしまいます。通常の input タグにして autocomplete="address-level1" を指定するようにしましょう。
<input type="text" name="prefecture" autocomplete="address-level1" />
住所フィールドの問題
こちらは何が良い悪いではないですが、開発者が把握しておくべき仕様として以下のようなものがあります。それは住所の autocomplete 属性はブラウザによって（特にSafariとChromeで）異なるということです。
具体的には以下の差があります。
| 要素名 | 意味（日本の住所において） | Chrome | Safari |
|---|---|---|---|
| address-level1 | 都道府県 | 補完される | 補完される |
| address-level2 | 市区町村 | 補完されない | 補完される |
| address-line1 | 番地 | 建物名まで補完される | 番地まで補完される |
| street-address | 番地（大） | 市区町村を含めて最後まで補完される | 市区町村以外が補完される |
細かい仕様については他にもいくらかありますが、大事なことは開発者がこれらの違いの存在を把握しておくことです。これらの仕様を把握して、Safariに寄せるのかChromeに寄せるのか、User-Agent を見てフォームを出し分けるのか、間を取るのか、特殊な制御を入れるのかなど、意図を持って体験を設計しましょう。
日付入力
よく見る日付入力の問題として、以下があります。
- 年月日の入力欄が分かれている
年月日の入力欄が分かれている
年月日を別々の入力欄にすることで、ユーザーの入力ミスを減らそうとしているケースがありますが、かえって入力の手間を増やしています。1つの入力欄にまとめ、適切なプレースホルダーや入力補助を提供しましょう。また、type="date" を使用することで、デバイスに応じたカレンダー入力が可能になります。
2024/10/2 追記
type="date" で日付を入力する場合、年を選択するUIが各ブラウザで全く統一されていません。
そのため、現在から近い日付の場合は問題ないのですが、例えば生年月日など遠い日付になると却ってユーザーの体験を悪化させる可能性があるため注意が必要です。
参考
- https://zenn.dev/heguro/articles/2796c389eaa281
- https://gigazine.net/news/20221228-safari-date-picker-customer-support-issues/
電話番号
電話番号の入力でも、郵便番号と同様の問題が発生しがちです。
- 属性が
numberになっている - 入力欄が分割されている
- ハイフンの有無でエラーになる
属性が number になっている
電話番号の入力欄に type="number" を使用すると、先頭のゼロが削除される、ハイフンが入力できないなどの問題があります。また、電話番号は数値計算を行うわけではないので、type="number" は適切ではありません。type="tel" を使用しましょう。これにより、モバイル端末では電話番号入力に適したキーボードが表示され、ユーザーの入力が容易になります。
<input type="tel" name="telephone" autocomplete="tel" />
入力欄が分割されている
市外局番、局番、加入者番号で入力欄を分けるフォームがありますが、これもユーザーにとっては入力の手間が増えます。特にコピーペーストができず、不便です。電話番号も1つの入力欄にまとめましょう。ハイフンの有無にかかわらず受け付け、システム側で適切に処理することで、ユーザーの負担を減らせます。
ハイフンの有無でエラーになる
電話番号の入力で、ハイフンを入れる人と入れない人がいます。どちらか一方しか受け付けないと、エラーが発生し、ユーザーにストレスを与えます。ハイフンの有無を許容し、入力値を正規化するようにしましょう。ユーザーが入力した値からハイフンを除去または追加することで、データの一貫性を保ちながらユーザー体験を向上させることができます。
総括
本記事で言及した以外にも、世の中のフォームには細かいところで使いにくいものが多く存在します。フォーム入力の体験が悪いと最悪の場合ユーザーの離脱にもつながるので、日頃から意識してフォームの実装をしましょう。
Discussion
懺悔をします。つい最近、住所や名前を「全角で入力してください」とゆうフォームが作られるのを、
止めることができませんでした（下っ端なので）。心の中でゲロを吐きました。
理由は「接続先の基幹システムが全角だから」だそうです。
ちなみにこのサービスは、外国のお客様が比較的多いサービスでした。悔い改めて欲しい。ほんと。
どこかで誰かが毎年同じようなフォームを作っているので、
行政標準とそて産総研あたりが使い回せるの、作ってほしい。
もしくはGoogleアカウントとかに登録してるの引っ張ってきて、
いや、ブラウザに登録してあるの全部一発入力かな。
電話番号であれば、ハイフンだけじゃなくて括弧の有無も同様ですね。
メールアドレス入力で、inputタグのime-modeがinactiveはともかく、disabledになってて開発者ツールで削除してから入力したこともあります。自分のメールアドレスはIME辞書登録してあるので、disabledだと入力できない。
普通、自分のメールアドレスって手入力しませんよね？ひどいのになると、メールアドレスが @ で分離されて2フィールドになってる。
クレジットカード番号も、16桁連続とか、ハイフン有無とか、空白有無とかどうでもいいのに、強制される。4桁ずつ4項目になっているケースもあるので、コピペ困難。
名前の、姓・名が別項目になっている理由も分からない。1つしかない人、3つ以上ある人はどうするんだ？日本国籍がある人限定のサービスで、戸籍名を書かせるのが必須なら2つなのでしょうけど、そんな前提があるのはお役所系の一部かと思います。
金額のカンマもどうでも良い。「12,345円振り込んで下さい」のように振込依頼メールはカンマ入りで書く人多数なので、入力欄でカンマが許容されないとそのままコピペできず面倒。
住所番地の全角半角もどうでも良い。
と回答した人は、「全角と半角の変換はプログラムで簡単にできる」事を知らないのですかね？
「入力ミスを防ぐために、手入力を回避する」という発想を持てない人が多数なんでしょうか？
氏名、住所、電話番号、メールアドレス、口座番号、クレカ番号など、手入力を強要する発想が間違っている。これら全部「入力者が元々持っていたメモファイルから任意の形式でコピペする」ということが可能かを設計チェック項目に入れるべきですね。