ログイン フォームのベスト プラクティス

クロスプラットフォームのブラウザ機能を使用して、安全でアクセスしやすく、使いやすいログイン フォームを構築します。

ユーザーがサイトにログインする必要がある場合は、ログイン フォームのデザインが重要になります。これは、接続が不安定な場合、モバイルを使用している場合、急いでいる場合、ストレスを感じている場合に特に当てはまります。ログインフォームのデザインが不適切だと、直帰率が高くなります。直帰は、ログインの機会を逃しただけでなく、ユーザーを失い、不満を抱かせたことを意味する可能性があります。

以下に、すべてのベスト プラクティスを実践したシンプルなログイン フォームの例を示します。

チェックリスト

意味のある HTML を使用する

このジョブ用に作成された要素(<form>、<label>、<button>)を使用します。これらを使用すると、組み込みのブラウザ機能が有効になり、ユーザー補助機能が向上し、マークアップに意味が追加されます。

<form> を使用する

入力を <div> でラップし、JavaScript のみで入力データの送信を処理したくなるかもしれません。通常は、従来の <form> 要素を使用することをおすすめします。これにより、スクリーン リーダーやその他の支援デバイスでサイトにアクセスできるようになり、さまざまな組み込みブラウザ機能が有効になります。また、古いブラウザでも基本的な機能のログインを簡単に構築でき、JavaScript が失敗した場合でも動作します。

<label> を使用する

入力にラベルを付けるには、<label> を使用します。

<label for="email">Email</label>
<input id="email" …>

理由は 2 つあります。

  • ラベルをタップまたはクリックすると、フォーカスが入力に移動します。ラベルの for 属性と入力の name または id を使用して、ラベルを入力に関連付けます。
  • スクリーン リーダーは、ラベルまたはラベルの入力がフォーカスされると、ラベルテキストを読み上げます。

プレースホルダを入力ラベルとして使用しないでください。ユーザーは、テキストの入力を開始すると、特に入力中に気が散った場合、入力内容を忘れてしまうことがあります(「メールアドレス、電話番号、アカウント ID のどれを入力していたっけ?」)。プレースホルダには他にも多くの問題があります。納得できない場合は、プレースホルダ属性を使用しないとフォーム フィールドのプレースホルダは有害をご覧ください。

ラベルは入力欄の上に配置するのが最適です。これにより、モバイルとパソコンで一貫したデザインを実現でき、Google AI の調査によると、ユーザーによるスキャンを迅速化できます。ラベルと入力は全幅で表示されるため、ラベルテキストに合わせてラベルと入力の幅を調整する必要はありません。

モバイルでのフォーム入力ラベルの位置(入力の横と入力の上)を示すスクリーンショット。
ラベルと入力が同じ行にある場合、幅が制限されます。

モバイル デバイスで label-position のデモを開いて、実際に確認してみてください。

<button> を使用する

ボタンには <button> を使用します。ボタン要素は、ユーザー補助機能と組み込みのフォーム送信機能を提供し、簡単にスタイルを設定できます。<div> やその他の要素をボタンのように見せかけて使用する意味はありません。

送信ボタンに、そのボタンの機能が示されていることを確認します。たとえば、[アカウントを作成] や [ログイン] などです。[送信] や [開始] は該当しません。

フォームが正常に送信されたことを確認する

パスワード マネージャーがフォームの送信を認識できるようにします。これを行うには 2 つの方法があります。

  • 別のページに移動します。
  • History.pushState() または History.replaceState() を使用してナビゲーションをエミュレートし、パスワード フォームを削除します。

XMLHttpRequest または fetch リクエストでは、ログインの成功がレスポンスで報告され、DOM からフォームを削除してユーザーに成功を示すことで処理されるようにします。

ユーザーが [ログイン] ボタンをタップまたはクリックしたら、このボタンを無効にすることを検討してください。多くのユーザーは、ボタンを複数回クリックします。これは、高速でレスポンシブなサイトでも同様です。これにより、インタラクションが遅くなり、サーバーの負荷が増加します。

逆に、ユーザー入力を待機しているフォーム送信を無効にしないでください。たとえば、ユーザーがお客様 PIN を入力していない場合でも、[ログイン] ボタンを無効にしないでください。ユーザーがフォームに記入漏れがあることに気づかず、無効になっている [ログイン] ボタンを何度もタップして、機能していないと思う可能性があります。少なくとも、フォームの送信を無効にする必要がある場合は、無効になっているボタンをクリックしたときに、何が不足しているかをユーザーに説明します。

入力を重複させない

一部のサイトでは、ユーザーにメールアドレスやパスワードを 2 回入力するよう求めています。これにより、一部のユーザーのエラーは減るかもしれませんが、すべてのユーザーに余分な作業が発生し、放棄率が増加します。ブラウザがメールアドレスを自動入力したり、安全なパスワードを提案したりする場合も、2 回尋ねる意味はありません。ユーザーがメールアドレスを確認できるようにし(いずれにしても必要になります)、必要に応じてパスワードを簡単に再設定できるようにすることをおすすめします。

要素属性を最大限に活用する

ここで魔法をかけます。 ブラウザには、入力要素の属性を使用する便利な組み込み機能が複数あります。

パスワードを非公開にする(ただし、ユーザーが希望する場合は表示できるようにする)

パスワード入力には、パスワード テキストを非表示にし、入力がパスワード用であることをブラウザが認識できるように、type="password" を指定する必要があります。(ブラウザは、さまざまな手法を使用して入力ロールを理解し、パスワードを保存するかどうかを決定します)。

ユーザーが入力したテキストを確認できるように、[パスワードを表示] 切り替えボタンを追加する必要があります。また、[パスワードを忘れた場合] リンクも忘れずに追加してください。パスワードの表示を有効にするをご覧ください。

[パスワードを表示] アイコンが表示されている Google ログイン フォーム。
Google ログイン フォームのパスワード入力: パスワードを表示アイコンとパスワードをお忘れの場合リンク。

モバイル ユーザーに適切なキーボードを表示する

<input type="email"> を使用すると、モバイル ユーザーに適切なキーボードを提供し、ブラウザによる基本的な組み込みのメールアドレス検証を有効にできます。JavaScript は必要ありません。

メールアドレスではなく電話番号を使用する必要がある場合は、<input type="tel"> を使用すると、モバイルで電話キーパッドが有効になります。必要に応じて inputmode 属性を使用することもできます。inputmode="numeric" は PIN 番号に最適です。詳しくは、Everything You Ever Wanted to Know About inputmode をご覧ください。

モバイルキーボードが [ログイン] ボタンを遮らないようにする

残念ながら、注意しないと、モバイル キーボードがフォームを覆ったり、さらに悪いことに、[ログイン] ボタンを部分的に遮ったりする可能性があります。ユーザーは、何が起こったのかを理解する前に諦めてしまう可能性があります。

Android スマートフォンのログイン フォームの 2 つのスクリーンショット。1 つは、[送信] ボタンがスマートフォンのキーボードで隠れている様子を示しています。
[ログイン] ボタン: 表示される場合と表示されない場合があります。

可能であれば、ログインページの上部にメールアドレス(または電話番号)とパスワードの入力欄、[ログイン] ボタンのみを表示することで、この問題を回避してください。他のコンテンツは下に配置します。

Android スマートフォンのログイン フォーム: [ログイン] ボタンがスマートフォンのキーボードで隠れていない。
キーボードが [ログイン] ボタンを遮らない。

さまざまなデバイスでテストする

ターゲット オーディエンスのさまざまなデバイスでテストし、それに応じて調整する必要があります。BrowserStack を使用すると、さまざまな実際のデバイスやブラウザでオープンソース プロジェクトの無料テストを行うことができます。

iPhone 7、8、11 のログイン フォームのスクリーンショット。iPhone 7 と 8 では、[ログイン] ボタンがスマートフォンのキーボードで隠れてしまうが、iPhone 11 では隠れない
[ログイン] ボタン: iPhone 7 と 8 では隠れていますが、iPhone 11 では隠れていません。

2 ページの使用を検討する

一部のサイト(Amazon や eBay など)では、メールアドレス(または電話番号)とパスワードを 2 つのページで要求することで、この問題を回避しています。このアプローチでは、ユーザーが一度に 1 つのタスクのみを行うため、エクスペリエンスも簡素化されます。

Amazon ウェブサイトのログイン フォーム: メールアドレス / 電話番号とパスワードが 2 つの別々の「ページ」にあります。
2 段階のログイン: メールアドレスまたは電話番号、パスワードの順に入力します。

理想的には、これは単一の <form> で実装する必要があります。JavaScript を使用して、最初はメール入力のみを表示し、その後、メール入力を非表示にしてパスワード入力を表示します。メールアドレスとパスワードの入力の間に、ユーザーを新しいページに移動させる必要がある場合は、2 ページ目のフォームにメールアドレスの値を含む非表示の入力要素を配置して、パスワード マネージャーが正しい値を保存できるようにする必要があります。Chromium が認識するパスワード フォームのスタイルに、コードの例が記載されています。

ユーザーがデータを再入力しなくて済むようにする

ブラウザがデータを正しく保存し、入力を自動入力できるようにすることで、ユーザーがメールアドレスとパスワードの値を入力する必要がなくなります。これはモバイルでは特に重要であり、放棄率が高いメール入力では不可欠です。

これには次の 2 つの部分があります。

  1. autocomplete、name、id、type 属性は、ブラウザが入力の役割を理解し、後で自動入力に使用できるデータを保存するのに役立ちます。自動入力のためにデータを保存できるようにするには、最新のブラウザでは、入力に安定した name 値または id 値(ページ読み込みやサイトのデプロイごとにランダムに生成されるのではなく)があり、submit ボタンのある <form> に含まれている必要があります。

  2. autocomplete 属性は、ブラウザが保存されたデータを使用して入力を正しく自動入力するのに役立ちます。

メール入力には autocomplete="username" を使用します。username は、最新のブラウザのパスワード マネージャーで認識されるためです。ただし、type="email" を使用する必要があり、id="email" と name="email" を使用することもできます。

パスワード入力では、適切な autocomplete 値と id 値を使用して、ブラウザが新しいパスワードと現在のパスワードを区別できるようにします。

新しいパスワードに autocomplete="new-password" と id="new-password" を使用する

  • 登録フォームのパスワード入力、またはパスワード変更フォームの新しいパスワードには、autocomplete="new-password" と id="new-password" を使用します。

既存のパスワードに autocomplete="current-password" と id="current-password" を使用する

  • ログイン フォームのパスワード入力、またはパスワード変更フォームのユーザーの古いパスワードの入力には、autocomplete="current-password" と id="current-password" を使用します。これにより、サイトに保存されている現在のパスワードを使用するようにブラウザに指示します。

登録フォームの場合:

<input type="password" autocomplete="new-password" id="new-password" …>

ログインの場合:

<input type="password" autocomplete="current-password" id="current-password" …>

パスワード マネージャーをサポートする

ブラウザによってメールアドレスの自動入力とパスワードの候補の処理方法は多少異なりますが、効果はほぼ同じです。たとえば、デスクトップの Safari 11 以降では、パスワード マネージャーが表示され、利用可能な場合は生体認証(指紋認証または顔認証)が使用されます。

パソコンの Safari でのログイン プロセスの 3 つの段階(パスワード マネージャー、生体認証、自動入力)のスクリーンショット。
予測入力によるログイン - テキスト入力は不要です。

パソコン版 Chrome にメールアドレスの候補が表示され、パスワード マネージャーが表示され、パスワードが自動入力されます。

パソコン版 Chrome でのログイン プロセスの 4 つの段階(メールアドレスの入力、メールアドレスの候補、パスワード マネージャー、選択時の自動入力)のスクリーンショット。
Chrome 84 の予測入力ログインフロー。

ブラウザのパスワードと自動入力システムは単純ではありません。値を推測、保存、表示するアルゴリズムは標準化されておらず、プラットフォームによって異なります。たとえば、Hidde de Vries 氏が指摘しているように、「Firefox のパスワード マネージャーは、レシピシステムでヒューリスティックを補完しています」。

自動入力: ウェブ デベロッパーが知っておくべきことには、name と autocomplete の使用に関する詳細情報が記載されています。HTML 仕様には、使用可能な 59 個の値がすべて記載されています。

ブラウザで安全なパスワードを自動生成できるようにする

最新のブラウザは、ヒューリスティックを使用して、パスワード マネージャーの UI を表示するタイミングを決定し、安全なパスワードを提案します。

パソコン版 Safari での操作方法は次のとおりです。

パソコンの Firefox パスワード マネージャー。
Safari でのパスワード候補のフロー。

(Safari では、バージョン 12.0 以降で安全な固有のパスワードの提案機能が利用可能になっています)。

ブラウザに組み込まれたパスワード生成機能により、ユーザーとデベロッパーは「安全なパスワード」とは何かを考える必要がなくなります。ブラウザはパスワードを安全に保存し、必要に応じて自動入力できるため、ユーザーがパスワードを覚えたり入力したりする必要はありません。ユーザーにブラウザに組み込まれたパスワード生成機能の使用を促すことで、サイトで一意の安全なパスワードが使用される可能性が高まり、他の場所で漏洩する可能性のあるパスワードが再利用される可能性が低くなります。

ユーザーが誤って入力を忘れないようにする

メールアドレスとパスワードの両方のフィールドに required 属性を追加します。最新のブラウザでは、不足しているデータに対して自動的にプロンプトが表示され、フォーカスが設定されます。JavaScript は不要です。

デスクトップ版 Firefox と Android 版 Chrome で、データが不足している場合に「このフィールドに入力してください」というプロンプトが表示される。
パソコン版 Firefox(バージョン 76)と Chrome for Android(バージョン 83)で、不足しているデータに関するプロンプトとフォーカス。

指と親指を考慮した設計

入力要素とボタンに関連するほぼすべてのデフォルトのブラウザサイズは、特にモバイルでは小さすぎます。これは当たり前のことのように思えますが、多くのサイトのログイン フォームでよく見られる問題です。

入力欄とボタンが十分な大きさであることを確認する

入力とボタンのデフォルトのサイズとパディングは、デスクトップでは小さすぎ、モバイルではさらに小さくなります。

パソコン版 Chrome と Android 版 Chrome のスタイルなしのフォーム。

Android のユーザー補助に関するガイダンスによると、タッチスクリーン オブジェクトの推奨ターゲット サイズは 7 ~ 10 mm です。Apple のインターフェース ガイドラインでは 48x48 px、W3C では 44x44 CSS ピクセル以上が推奨されています。これを基準として、モバイルの場合は入力要素とボタンに 15 ピクセル以上、デスクトップの場合は 10 ピクセル程度のパディングを追加します。実際のモバイル デバイスと実際の指で試してみてください。各入力とボタンを簡単にタップできる必要があります。

タップ ターゲットのサイズが適切に設定されていません。Lighthouse 監査は、小さすぎる入力要素を検出するプロセスを自動化するのに役立ちます。

親指で操作しやすいデザイン

「タップ ターゲット」を検索すると、人差し指の画像がたくさん表示されます。しかし、実際には多くの人が親指を使ってスマートフォンを操作しています。親指は人差し指よりも大きく、操作の精度が低くなります。タップ ターゲットのサイズを適切に設定することが重要である理由は、これだけではありません。

テキストを十分な大きさにする

サイズやパディングと同様に、入力要素とボタンのデフォルトのブラウザ フォントサイズは、特にモバイルでは小さすぎます。

パソコンと Android の Chrome でのスタイル設定されていないフォーム。
パソコンとモバイルのデフォルトのスタイル設定: 入力テキストが小さすぎて、多くのユーザーにとって判読できません。

プラットフォームが異なるとブラウザのフォントサイズも異なるため、どこでも適切に機能する特定のフォントサイズを指定することは困難です。人気のウェブサイトを簡単に調査すると、パソコンでは 13 ~ 16 ピクセルのサイズが表示されます。この物理サイズに合わせることは、モバイルのテキストの最小サイズとして適しています。

つまり、モバイルではより大きなピクセルサイズを使用する必要があります。デスクトップ版 Chrome の 16px は非常に読みやすいですが、視力が良くても、Chrome for Android の 16px テキストを読むのは困難です。メディアクエリを使用すると、ビューポートのサイズごとに異なるフォントのピクセルサイズを設定できます。20px はモバイルではほぼ適切ですが、ロービジョンの友人や同僚にテストしてもらう必要があります。

ドキュメントで読みやすいフォントサイズが使用されていない Lighthouse 監査を使用すると、小さすぎるテキストを検出するプロセスを自動化できます。

入力要素間に十分なスペースを確保する

入力がタップ ターゲットとして適切に機能するよう、十分なマージンを追加します。つまり、指 1 本分の幅の余白を確保します。

入力内容がはっきりと見えるようにしてください

入力のデフォルトの枠線スタイルでは、入力が見づらくなっています。Chrome for Android などの一部のプラットフォームでは、ほとんど表示されません。

パディングだけでなく、枠線も追加します。白い背景の場合、一般的には #ccc 以上の濃い色を使用することをおすすめします。

Android 版 Chrome でスタイル設定されたフォーム。
読みやすいテキスト、表示される入力枠、適切なパディングとマージン。

ブラウザの組み込み機能を使用して、無効な入力値に関する警告を表示する

ブラウザには、type 属性を持つ入力に対して基本的なフォーム検証を行う機能が組み込まれています。ブラウザは、無効な値を含むフォームが送信されると警告を表示し、問題のある入力にフォーカスを設定します。

パソコン版 Chrome のログイン フォーム。ブラウザのプロンプトと、無効なメールアドレス値のフォーカスが表示されている。
ブラウザによる基本的な組み込み検証。

:invalid CSS セレクタを使用して、無効なデータをハイライト表示できます。:not(:placeholder-shown) を使用して、コンテンツのない入力が選択されないようにします。

input[type=email]:not(:placeholder-shown):invalid {
  color: red;
  outline-color: red;
}

無効な値を含む入力をハイライト表示するさまざまな方法を試します。

必要に応じて JavaScript を使用する

パスワードの表示を切り替える

[パスワードを表示] 切り替えボタンを追加して、ユーザーが入力したテキストを確認できるようにする必要があります。ユーザーが入力したテキストを確認できないと、ユーザビリティが低下します。現在、これを実現する組み込みの方法はありませんが、実装の計画はあります。代わりに JavaScript を使用する必要があります。

[パスワードを表示する] 切り替えボタンと [パスワードをお忘れの場合] リンクが表示されている Google ログイン フォーム。
Google ログイン フォーム: [パスワードを表示] 切り替えボタンと [パスワードをお忘れの場合] リンク。

次のコードでは、テキストボタンを使用してパスワードを表示する機能を追加しています。

HTML:

<section>
  <label for="password">Password</label>
  <button id="toggle-password" type="button" aria-label="Show password as plain text. Warning: this will display your password on the screen.">Show password</button>
  <input id="password" name="password" type="password" autocomplete="current-password" required>
</section>

ボタンを書式なしテキストのように表示する CSS は次のとおりです。

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  /* Media query isn't shown here. */
  font-size: var(--mobile-font-size);
  font-weight: 300;
  padding: 0;
  /* Display at the top right of the container */
  position: absolute;
  top: 0;
  right: 0;
}

パスワードを表示する JavaScript:

const passwordInput = document.getElementById('password');
const togglePasswordButton = document.getElementById('toggle-password');

togglePasswordButton.addEventListener('click', togglePassword);

function togglePassword() {
  if (passwordInput.type === 'password') {
    passwordInput.type = 'text';
    togglePasswordButton.textContent = 'Hide password';
    togglePasswordButton.setAttribute('aria-label',
      'Hide password.');
  } else {
    passwordInput.type = 'password';
    togglePasswordButton.textContent = 'Show password';
    togglePasswordButton.setAttribute('aria-label',
      'Show password as plain text. ' +
      'Warning: this will display your password on the screen.');
  }
}

最終的な結果は次のようになります。

Mac と iPhone 7 の Safari で、[パスワードを表示] テキスト「ボタン」が表示されたログイン フォームのスクリーンショット。
Mac と iPhone 7 の Safari で、[パスワードを表示] テキスト「ボタン」が表示されたログイン フォーム。

パスワード入力のアクセシビリティを高める

aria-describedby を使用して、制約を記述する要素の ID を指定することで、パスワード ルールを記述します。スクリーン リーダーは、ラベルテキスト、入力タイプ(パスワード)、説明の順に読み上げます。

<input type="password" aria-describedby="password-constraints" …>
<div id="password-constraints">Eight or more characters with a mix of letters, numbers and symbols.</div>

パスワードを表示機能を追加する場合は、パスワードが表示されることを警告する aria-label を含めるようにしてください。そうしないと、ユーザーが誤ってパスワードを公開してしまう可能性があります。

<button id="toggle-password"
        aria-label="Show password as plain text.
                    Warning: this will display your password on the screen.">
  Show password
</button>

次のデモでは、両方の ARIA 機能が動作していることを確認できます。

Creating Accessible Forms には、フォームをユーザー補助対応にするためのヒントが記載されています。

リアルタイムで送信前に検証

HTML フォームの要素と属性には、基本的な検証を行うための機能が組み込まれていますが、ユーザーがデータを入力しているときやフォームを送信しようとしたときに、より堅牢な検証を行うために JavaScript も使用する必要があります。

ログイン フォームの Codelab のステップ 5 では、Constraint Validation API(広くサポートされている)を使用して、組み込みのブラウザ UI を使用してカスタム検証を追加し、フォーカスを設定してプロンプトを表示します。

詳細: より複雑なリアルタイム検証に JavaScript を使用する。

分析と RUM

「測定できないものは改善できない」という言葉は、登録フォームやログイン フォームに特に当てはまります。目標を設定し、成果を測定し、サイトを改善する、というプロセスを繰り返す必要があります。

割引ユーザビリティ テストは、変更を試すのに役立ちますが、ユーザーが登録フォームやログイン フォームをどのように操作しているかを実際に把握するには、実際のデータが必要です。

  • ページ分析: 登録ページとログインページのページビュー、直帰率、離脱率。
  • インタラクション分析: 目標到達プロセス(ユーザーがログインまたはログインフローを放棄する場所)とイベント(ユーザーがフォームを操作するときに実行するアクション)。
  • ウェブサイトのパフォーマンス: ユーザー中心の指標(登録フォームやログイン フォームが遅い理由とその原因)。

また、A/B テストを実装して、登録とログインのさまざまなアプローチを試すことも検討してください。さらに、段階的な公開を使用して、変更をすべてのユーザーにリリースする前に、一部のユーザーで変更を検証することも検討してください。

一般的なガイドライン

適切に設計された UI と UX により、ログイン フォームの放棄を減らすことができます。

  • ユーザーがログイン方法を探す必要がないようにします。ログイン フォームへのリンクをページの上部に配置し、[ログイン]、[アカウントを作成]、[登録] など、わかりやすい文言を使用します。
  • 焦点を絞る。登録フォームは、特典やその他のサイト機能でユーザーの注意をそらす場所ではありません。
  • 登録手続きをできるだけ簡素化します。その他のユーザーデータ(住所やクレジット カードの詳細など)を収集するのは、そのデータを提供することでユーザーが明確なメリットを得られる場合に限ります。
  • ユーザーが登録フォームに入力する前に、価値提案を明確にします。ログインするとどのようなメリットがあるのかを説明します。ユーザーが登録を完了するための具体的なインセンティブを提供する。
  • メールを使用しないユーザーもいるため、可能であれば、メールアドレスではなく携帯電話番号でユーザーを識別できるようにします。
  • ユーザーがパスワードを簡単に再設定できるようにし、[パスワードをお忘れの場合] リンクをわかりやすく表示します。
  • 利用規約とプライバシー ポリシーのドキュメントへのリンク: ユーザーのデータをどのように保護するかを最初から明確にします。
  • 登録ページとログインページに会社または組織のロゴと名前を記載し、言語、フォント、スタイルがサイトの他の部分と一致するようにします。フォームによっては、特に URL が大きく異なる場合、他のコンテンツと同じサイトに属しているように感じられないことがあります。

学習を継続