👌

フォームを作るならtype属性くらい適切に設定してくれ

2023/05/23に公開3

web制作の基本中の基本、フォーム作成に付いてのお話です。

TL;DR

web制作において殆どの場合避けて通ることができないフォーム作成ですが、今日平然と運用されてるwebサイトの多くがフォームの基本中の基本であるtype属性を適切に設定していない場合があります。
本記事はtype属性を適切に設定することの意義、適切に設定しないことの罪について話していきます。

type属性とは?

type属性とは、その名の通りinputに設定される型であり、デフォルトではtextで定義されます。
ブラウザはこのtype属性を読み取って、フォームの見た目を変化させたり、valueの型を設定したりといった挙動をします。

MDN Docs

type属性を設定しない罪

type属性はデフォルトでtextになるという話をしましたが、ではemailpasswordあるいはurlといった文字列で表される情報を入力するときに、なぜtextではいけないのでしょうか?
あるいは、passwordではない値を入力する欄をpasswordに設定してしまうことの何が問題なのでしょうか?

アクセシビリティの低下

typeを適切に設定しないことのデメリットの殆どは「アクセシビリティの低下」という言葉に集約されます。
例えば、required属性が設定された<input type="email" required />のようなフォームがあったときに、特別な実装をしなくてもsubmitボタン押下時にブラウザは簡易的なバリデーションを行い、不備がある場合は以下のように、該当箇所を指摘するエラーメッセージが出てきます。
これはスクリーンリーダーでも読み上げられます(lang=jaを設定していれば日本語でメッセージが出る)

また、passwordであれば文字列が伏せ字になったり、telであれば(端末によっては)電話番号入力用のテンキーを表示したり、numberはスピナーを表示し、weekdateはカレンダーで入力する奴(名前がわからない)を表示したりと、ブラウザはtypeに応じた様々な挙動を示します。
このようにHTML5に対応したブラウザ(つまりほぼ全部)では、type属性の値を読み取って、それに応じたアクセシビリティ機能を提供しています。typeを設定しないということは、それらの恩恵をユーザーが受けることができないということです。
誰でもwebサイトを使う現代に置いて、アクセシビリティに配慮しないなんてありえないですよね。

ブラウザのサジェスト機能が適切に動作しない

上のアクセシビリティの低下と同じに書こうか迷ったのですが、一旦分けることにしました。
例えばwebアプリにログインするとき、パスワード入力欄に以下のようにサジェストが出ることがあると思います。

また、初めてログインするようなサイトでパスワードを保存するか聞かれることもあるかと思いますが、こういったブラウザの挙動はtype属性を読んでpasswordであるとブラウザが認識しているため適切に動作しています。
(注: 厳密には自動補完に関わるのはtype属性だけではなくautocomplete属性もあって、例えば郵便番号の自動入力なんかはautocomplete="postal-code"とか設定しているんですがpasswordtypeでいいのでその話はまた別の機会に)
フォームにpassword型を適切に定義しないということはユーザーがパスワードのサジェスト機能を利用できないもしくは意図せずパスワードのサジェストが発動して煩わしくなることを意味します。
後者が本記事を書くに至った具体的な要因なので詳しく解説します(私怨)
passwordに限らず適切でないtypeはユーザーの期待した挙動を裏切ることが多いので具体例として解説します。

パスワードでない値にpasswordを設定してしまう罪

passwordに設定されたフォームは以下のような挙動を示します。

  • フォームの内容が伏せ字になる
  • ブラウザがドメインに紐付けられたパスワードをサジェストする
  • ブラウザがドメインに紐付けられたパスワードを更新するか確認してくる

問題になるのは下2点です。
よくある例でいうと、2FAを採用しているサイト、具体的には銀行系のサイトやSNS、某大手MMORPGの管理画面など、セキュアなログインが求められるサイトに多いのですが、以下のようなフォームです。

一見問題なさそうに見えますが、passwordを設定したフォームの挙動を思い出していただきたいです。
このフォームでログインしようとしたときユーザーはパスワードを入力しようとしていないのにパスワードをサジェストされsubmitするとパスワードを入力してないのにパスワードを保存するか毎回聞かれる(そしてうっかり押してしまったりする)という体験をすることになります。
これでは良いUXとは言えません。
2FAのワンタイムパスワードのようなものも、ログインに関わる値のため何となく伏せ字にするためにpasswordにしている事が多いと思うのですが、ワンタイムパスワードのような一時的な鍵はそもそも構造的に覗き見されたりスクリーンショットを取られても殆ど不都合がないため、伏せ字にする必要性も薄いです。(GitHubなんかはtextにしてます)
passwordを設定する前に一度自分の胸に手を当ててそれが本当に伏せ字にする必要がある値なのか検討してみましょう。そしてもし様々な理由で伏せ字にする必要があるのであれば、javascriptでなんとか対応するか、非推奨ですがautocomplete="off"にした上でpassword型にしましょう(autocompete="off"は無視するブラウザが多いため気休めにしかならない)

まとめ

本記事では主にpassword属性を例に上げて解説しましたが、その他のtelemail等のよくtextに設定されてしまっているフォームでも大体同じことが言えます。
webエンジニアの皆さんは、ユーザーの体験を上げるためにもフォームを作る際にはtypeを適切に設定するようにしましょう。

株式会社ゆめみ

Discussion

TakashiAiharaTakashiAihara

有用な記事ありがとうございます。
内容と直接関係なくて申し訳ないですが、TL;DR の使い方が若干違うような。
検索すると、↓のような内容が。

記事の筆者が冒頭に内容を要約した箇条書きなどを掲載するときに、その表題として用いるようになった。その場合は「長すぎるという方のための要約です」のような意味合いになる。

「はじめに」とか「背景」のが近いなぁと。