8
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

フォームデザインについて考えたこと 〜2021〜

Posted at

この記事は「弁護士ドットコム Advent Calendar 2021」の 20 日目の記事です。
昨日は @NaokiTsuchiya さんでした。

はじめに

弁護士ドットコムでエンジニアをしている @blkclct です。2021 年は,フォームのフロントエンド側を実装する機会が多い年になりました.ログインフォームや,会員登録フォーム,問い合わせフォームなど,どのアプリにもありそうなものを,ゆっくり検討するいい機会をいただきました.検討した中で,最低限この辺りは押さえておくとよさそうだな!と思ったものを何個かピックアップして紹介します!そんなの当たり前だよ!という内容もあるかもしれませんが,お手柔らかに.

参考にした文献

最初にフォームのことを考える上で参考にした文献を紹介しておきます.

フォーム実装の基本的なことを,様々なフォームを元に,網羅的にまとめられているのでおすすめです.

フォーム実装のいろは

フォーム実装におけるフロントエンド側の役割の大部分はユーザビリティを担保してあげることだと思っています.こちらを踏まえた上で読んでいただけると助かります.

maxlength を指定しない

HTML の input 要素や textarea 要素に対して,maxlength 属性を指定するのは,(フォーム実装に関しては,)必要になるケースはないと思っています.
例えば,input 要素の場合,意図しない文字の切り詰めが起きて,それをユーザーが気づかない可能性があります.スマホだと画面幅が狭かったりするので,割と起きると思っています.
特に,パスワードフォーム実装で,input 要素の type="password" で文字長に切り詰めが起こるとまずいので,絶対指定しないようにした方がいいと思います.たまに遭遇するんですが,登録フォームでは,maxlength 指定があって,ログインフォームでは指定ないとかだと一生ログインできなくて泣きます.

Twitter のように 140 文字制限があるのであれば,それを入力中もしくは,submit 時にその旨をフィードバッグしてあげればいいだけの話だと思います.

バリデーションのルールの明示する

こちらもユーザビリティ観点なのですが,基本的に入力フォーム付近に,バリデーションルールの明示もしくは例示を入れるべきだと思います.submit しないとエラーがわからないような仕組みはよくないと思っています.またパスワードフォームの話になりますが,パスワードフォームは,ルールが複雑な場合が多いと思うので,登録時にはルールを明示してあげることは必須だと思います.何度もエラーを返していると,ユーザをイライラさせ,離脱の原因になり,結果 CVR などにも影響が出ると思います.

submit ボタンに disabled 属性をつけない

よく最後に利用規約にチェックを入れないと submit ボタンが活性化されない仕様があると思いますが,それについてです.
こちらは賛否両論ありそうですし,実際ものによると思います.disabled を入れたほうが都合のいい UI もあると思います.ただ,僕は基本的には,入れなくていいと思っています.
この仕様があることで,まず,ユーザーはボタンを有効化するために,どれを入力しないといけないのか考えることを強いなければなりません.その時点で入力ハードルは上がりますし,実装者視点でも,実装もデザインも複雑になりがちです.また,そのフォーム自体の拡張性を悪くすると思っています.最初は,シンプルで簡単だったフォームも仕様が変わり,複雑になっていくかもしれないので,それに備えて最初から,disabled 属性は使わず,submit イベントが起きてからエラーを発生させてユーザーにエラー内容を伝える方法にした方がいいと思ってます.今回の記事では,あまり触れていなかったのですが,アクセシビリティの観点でも,aria-disabled を使いつつ,状態を伝えることはできますが,何を入力しないといけないかまで伝えるのは,また大変だったりするのでおすすめできません.

HTML 最低限正しく書く

意外と漏れてたりするのですが,フォームの各要素について,HTML を正しく書いてあげることは,当然ですが,大切です.モバイル端末で,入力するユーザーに恩恵を得られるので.
特に,最近では,パスワードや個人情報を自動入力させるアプリケーションを使っているユーザーが増えていると思うので,それを使えるよう正しく HTML を書いてあげなければいけないと思ってます.

最低限抑えておくべきなのは下記2点です.

  • input 要素の type 属性を正しく設定する
  • input 要素の name 属性の値を適切に設定する

input 要素の type 属性を正しく設定する

こちらは,例えば,電話番号の入力欄で,<input type="text" name="tel" /> とするのではなく,<input type="tel" name="tel" /> と正しく設定するという話だけです.こちらは,特にこれ以上ないです.

input 要素の name 属性の値を適切に設定する

input 要素の name 属性はデタラメにつけるのではなく,意図に合った命名にした方がいいという話です.なぜかというと,name 属性が適当だったりすると,ブラウザの自動入力補完が働かなったりするためです.
また,name 属性に加えて,autocomplete 属性を使って正しい値を当てることも大切です.name 属性の値がよくなくても,補完が効くようになるはずです.

このあたりの話は,ics.media さんの掲載記事である,今どきの入力フォームはこう書く!に詳しく書いてあったので見てみて下さい!

余談

フロントエンドとバックエンド両サイドのバリデーション管理

今年中にいい結論が出なかったのですが,フロントエンドとバックエンドのバリデーションルールをいい感じに同期させる方法について頭を悩ませました.バックエンド側で仕様が変更されたときにフロントエンド側も同時に変更しないといけないのはつらいよな..という話です.昨今のフロントエンドではリッチな UI が求められがちで,複雑な状態管理を行う都合上,結構変更入れないといけないとかになる,よりつらいよなーと思ってます.
何かいい方法はないだろうか..いい方法があればご教示いただきたいですmm

おわりに

以上になります.実装については,ほぼなく,ポエムっぽい記事になってしまいましたが,ご容赦ください.
最後まで読んでくださりありがとうございました!

明日は,@edi_t さんです.お楽しみに!

8
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?