クロス プラットフォームのブラウザ機能を使用して、安全でアクセスしやすく使いやすいログイン フォームを構築できます。
ユーザーがサイトにログインする必要がある場合は、適切なログイン フォームを設計することが重要です。これは、接続状態が悪い人、モバイル デバイスを使用している人、急いでいる人、ストレスを感じている人に特に当てはまります。ログイン フォームの設計に問題があると、直帰率が高くなります。ユーザーが直帰するたびに、ログインの失敗だけでなく、失望し、不満を覚えるユーザーになる可能性があります。
すべてのベスト プラクティスを示すシンプルなログイン フォームの例を次に示します。
チェックリスト
- 意味のある HTML 要素を使用する:
<form>
、<input>
、<label>
、<button>
。 - 各入力に
<label>
のラベルを付けます。 - 組み込みのブラウザ機能にアクセスするには、要素属性
type
、name
、autocomplete
、required
を使用します。 - 入力の
name
属性とid
属性には、ページの読み込み時やウェブサイトのデプロイ時に変更されない安定した値を指定します。 - ログインを独自の <form> 要素内に配置します。
- フォームが確実に送信されるようにする。
autocomplete="new-password"
とid="new-password"
を使用して、登録フォームのパスワード入力と、パスワード リセット フォームでの新しいパスワードの入力を行います。- ログイン パスワードの入力に
autocomplete="current-password"
とid="current-password"
を使用します。 - [パスワードを表示] 機能を提供します。
- パスワード入力には
aria-label
とaria-describedby
を使用します。 - 入力を二重にしないでください。
- モバイル キーボードで入力やボタンが見えにくくならないようにフォームを設計します。
- フォームをモバイルで利用できるようにします。判読可能なテキストを使用し、入力とボタンの大きさをタップ ターゲットとして機能させるのに十分な大きさにします。
- 登録ページとログインページでブランディングとスタイルを維持する。
- ラボだけでなく現場でもテスト: ページ分析、インタラクション分析、ユーザー中心のパフォーマンス測定を、登録フローとログインフローに組み込みます。
- 複数のブラウザやデバイスでテストする: フォームの動作はプラットフォームによって大きく異なります。
意味のある 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 Glitch を開き、実際に確認します。
<button>
ボタンには <button>
を使用します。ボタン要素を使用すると、ユーザー補助の動作と組み込みのフォーム送信機能を実現でき、スタイル設定も簡単です。<div>
などのボタンに見せかけた要素を使用しても意味がありません。
送信ボタンにその内容が表示されることを確認します。たとえば、アカウントの作成やログインなどです。[送信] や [開始] は使用できません。
フォームを確実に送信できるようにする
フォームが送信されたことをパスワード マネージャーが把握できるようにします。これには次の 2 つの方法があります。
- 別のページに移動します。
History.pushState()
またはHistory.replaceState()
を使用してナビゲーションをエミュレートし、パスワード フォームを削除します。
XMLHttpRequest
リクエストまたは fetch
リクエストでは、ログインの成功がレスポンスで報告され、DOM からフォームを取り出してユーザーに成功を示すことで処理されるようにします。
ユーザーが [ログイン] ボタンをタップまたはクリックしたら、そのボタンを無効にすることを検討してください。処理が速くレスポンシブなサイトでも、多くのユーザーはボタンを複数回クリックします。これにより操作が遅くなり、サーバーの負荷が高まります。
逆に、ユーザー入力を待機するフォーム送信を無効にしないでください。たとえば、ユーザーがカスタマー PIN を入力していない場合は、[ログイン] ボタンを無効にしないでください。フォームの入力を見逃し、無効になっている [ログイン] ボタンを繰り返しタップしようとしても、機能していないとユーザーが感じてしまうことがあります。少なくとも、フォームの送信を無効にする必要がある場合は、無効になっているボタンをクリックしたときに不足している情報をユーザーに説明します。
入力を二重にしない
一部のサイトでは、ユーザーにメールアドレスまたはパスワードを 2 回入力する必要があります。これにより、数人のユーザーのエラーは減少する可能性がありますが、すべてのユーザーに対して余分な作業が発生し、放棄率が増加します。また、ブラウザでメールアドレスが自動入力されたり、安全なパスワードが提案されたりする場合は、2 回入力しても意味がありません。ユーザーがメールアドレスを確認できるようにして(いずれにせよ必要です)、ユーザーが必要に応じて簡単にパスワードを再設定できるようにすることをおすすめします。
要素の属性を最大限に活用する
魔法のような体験です。 ブラウザには、入力要素の属性を使用する便利な機能が複数用意されています。
パスワードは非公開にし、ユーザーが必要に応じて確認できるようにする
パスワード入力では、パスワード テキストを非表示にして、入力がパスワード用であることをブラウザが理解できるように、type="password"
を指定する必要があります。(ブラウザはさまざまな手法を使用して入力ロールを把握し、パスワード保存の確認メッセージを表示するかどうかを決定します)。
[パスワードを表示] トグルを追加して、ユーザーが入力したテキストを確認できるようにする必要があります。[パスワードをお忘れの場合] リンクも忘れずに追加してください。パスワードの表示を有効にするをご覧ください。
モバイル ユーザーに適切なキーボードを提供
<input type="email">
を使用してモバイル ユーザーに適切なキーボードを提供し、ブラウザによる組み込みの基本的なメールアドレス検証を有効にします。JavaScript は必要ありません。
メールアドレスの代わりに電話番号を使用する必要がある場合は、<input
type="tel">
を使用してモバイルで電話のキーパッドを有効にします。必要に応じて inputmode
属性を使用することもできます。inputmode="numeric"
は PIN 番号に最適です。詳細については、inputmode についてをご覧ください。
モバイル キーボードが [ログイン] ボタンを遮らないようにする
注意しないとモバイルのキーボードがフォームを覆ったり、[ログイン] ボタンが一部見えにくくなったりします。ユーザーは何が起こったのか 理解する前にあきらめる可能性があります
可能であれば、ログインページの上部にメールアドレス、電話番号、パスワードの入力と [ログイン] ボタンのみを表示するようにします。他の内容を以下に追加してください。
さまざまなデバイスでテストする
さまざまなデバイスでテストを行い、それに応じて調整する必要があります。BrowserStack では、さまざまな実際のデバイスとブラウザでオープンソース プロジェクトの無料テストを行うことができます。
2 ページの使用を検討する
一部のサイト(Amazon や eBay など)では、2 つのページでメール、電話番号、パスワードの入力を求めることで、この問題を回避できます。このアプローチはエクスペリエンスも簡素化されます。ユーザーは一度に 1 つのタスクのみを行います。
理想的には、単一の <form> で実装します。JavaScript を使用して、最初はメール入力のみを表示し、その後非表示にしてパスワード入力を表示します。メールアドレスとパスワードの入力の間にユーザーに新しいページに移動させる必要がある場合は、2 番目のページのフォームで、メールアドレスの値を含む非表示の入力要素を使用して、パスワード マネージャーが正しい値を保存できるようにします。Chromium が認識するパスワード フォームのスタイルにコードサンプルがあります。
ユーザーがデータを再入力する必要がないようにする
ブラウザがデータを正しく保存し、自動入力入力を行えるようにすることで、ユーザーがメールアドレスとパスワードの値の入力を思い出さなくても済むようにします。これはモバイルで特に重要であり、放棄率が高いメール入力においても重要です。
これには次の 2 つの部分があります。
autocomplete
、name
、id
、type
の各属性は、後で自動入力に使用できるデータを保存するための入力の役割をブラウザが理解するのに役立ちます。最新のブラウザでは、自動入力用のデータを保存するために、入力が安定したname
値またはid
値(ページの読み込み時やサイトデプロイのたびにランダムに生成されない値)を持つことと、<form> 内でsubmit
ボタンが存在することも必要です。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 以降ではパスワード マネージャーが表示され、利用可能な場合は生体認証(指紋認証または顔認証)が使用されます。
パソコンの Chrome で、メールの候補表示、パスワード マネージャーの表示、パスワードの自動入力が行われます。
ブラウザのパスワードや自動入力のシステムは単純ではありません。値を推測、保存、表示するアルゴリズムは標準化されておらず、プラットフォームによって異なります。たとえば、Hidde de Vries 氏は「Firefox のパスワード マネージャーはレシピシステムでヒューリスティックを補完します」と述べています。
自動入力: ウェブデベロッパーが知っておくべきことに、name
と autocomplete
の使用について詳しく説明しています。HTML 仕様には、可能な 59 個の値がすべてリストされています。
安全なパスワードをブラウザで提示できるようにする
最新のブラウザはヒューリスティックを使用して、パスワード マネージャー UI を表示するタイミングを決定し、安全なパスワードを提案します。
パソコンで Safari を使用する場合は次のようになります。
(Safari のバージョン 12.0 以降では、強力な固有のパスワードの候補が利用可能です。)
組み込みのブラウザ パスワード生成ツールにより、ユーザーとデベロッパーが「安全なパスワード」とは何かを考える必要はありません。ブラウザはパスワードを安全に保存し、必要に応じて自動入力できるため、ユーザーがパスワードを覚えたり入力したりする必要はありません。また、ブラウザの内蔵パスワード生成ツールの利用を促すことは、ユーザーがサイトで一意の安全なパスワードを使用する可能性が高くなり、他の場所で不正使用される可能性のあるパスワードを再利用する可能性も低くなります。
ユーザーが誤って入力を見逃してしまう事態を防ぐ
メールアドレスとパスワードのフィールドの両方に required
属性を追加します。最新のブラウザでは、不足しているデータに対するメッセージが自動的に表示され、フォーカスが設定されます。JavaScript は必要ありません。
指や親指に配慮したデザイン
特にモバイルでは、入力要素とボタンに関するほぼすべてのものについて、デフォルトのブラウザサイズが小さすぎます。当たり前に思われるかもしれませんが、多くのサイトでログイン フォームでよく見られる問題です。
入力とボタンの大きさが十分であることを確認してください
入力とボタンのデフォルトのサイズとパディングは、パソコンでは小さすぎます。モバイルではさらに問題があります。
Android のユーザー補助ガイダンスによると、タッチスクリーン オブジェクトの推奨ターゲット サイズは 7 ~ 10 mm です。Apple のインターフェース ガイドラインでは 48x48 ピクセルを推奨しており、W3C では 44x44 以上の CSS ピクセルを推奨しています。そのため、モバイルでは入力要素とボタンに(少なくとも)約 15 ピクセル、パソコンでは約 10 ピクセルのパディングを追加します。実際のモバイル デバイスで実際の指や親指で試してみましょう。各入力とボタンを簡単にタップできる必要があります。
タップ ターゲットのサイズが適切でない Lighthouse の監査は、小さすぎる入力要素を検出するプロセスの自動化に役立ちます。
親指で操作できるようにデザインする
「タップ ターゲット」を検索すると、人差し指の画像がたくさん見つかります。しかし、現実の世界では、多くの人が親指でスマートフォンを操作します。親指は人差し指よりも大きく、操作は精度が下がります。タップ ターゲットのサイズを適正化することはさらに重要です。
文字を大きくする
サイズやパディングと同様に、入力要素とボタンのデフォルトのブラウザ フォントサイズは小さすぎます(特にモバイルの場合)。
プラットフォームによってフォントのサイズは異なるため、どこでも適切に機能する特定のフォントサイズを指定することは困難です。一般的なウェブサイトの簡単な調査では、パソコン上でのサイズは 13 ~ 16 ピクセルであることが示されています。モバイルでは、この物理サイズを最小でもテキストのサイズに合わせることが推奨されます。
つまり、モバイルではより大きなピクセルサイズを使用する必要があります。パソコン用の Chrome では、16px
は非常に読みやすくなりますが、視力が良好であっても、Chrome for Android では 16px
のテキストを読むのは困難です。メディアクエリを使用すると、ビューポート サイズごとに異なるフォント ピクセルサイズを設定できます。20px
はモバイルでの使用に適していますが、ロービジョンの友人や同僚と試してみる必要があります。
Lighthouse の監査機能を使用すると、ドキュメントが判読可能なフォントサイズを使用していません。Lighthouse の監査機能を使用すると、小さすぎるテキストを検出するプロセスを自動化できます。
入力と入力の間に十分なスペースを空ける
タップ ターゲットとして入力が適切に機能するよう、十分な余白をとってください。指の幅ほどの余裕を持たせましょう
入力内容がはっきりと表示されるようにする
入力のデフォルトの枠線スタイルでは、入力が見えにくくなっています。Chrome for Android など、一部のプラットフォームではほとんど認識されません。
パディングに加えて枠線も追加します。白い背景では、原則として #ccc
かそれよりも濃い色を使用します。
組み込みのブラウザ機能を使用して無効な入力値を警告する
ブラウザには、type
属性を持つ入力に対して基本的なフォーム検証を行う機能が組み込まれています。無効な値を含むフォームを送信すると、ブラウザは警告を表示し、問題のある入力にフォーカスを設定します。
:invalid
CSS セレクタを使用して無効なデータをハイライト表示できます。:not(:placeholder-shown)
を使用して、コンテンツのない入力を選択しないようにします。
input[type=email]:not(:placeholder-shown):invalid {
color: red;
outline-color: red;
}
無効な値を含む入力をハイライト表示するさまざまな方法を試してください。
必要に応じて JavaScript を使用する
パスワードの表示を切り替え
[パスワードを表示] 切り替えを追加して、ユーザーが入力したテキストを確認できるようにする必要があります。入力したテキストがユーザーに表示されない場合、ユーザビリティが低下します。現時点では、これを行う組み込みの方法はありませんが、実装の計画があります。代わりに JavaScript を使用する必要があります。
次のコードでは、テキストボタンを使って [Show password] 機能を追加します。
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.');
}
}
最終的な結果は次のとおりです。
パスワード入力にアクセスできるようにする
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>
以下の Glitch では、ARIA 機能の実際の動作を確認できます。
フォームを利用しやすくするためのその他のヒントについては、誰もが使いやすいフォームを作成するをご覧ください。
リアルタイムかつ送信前に検証
HTML のフォーム要素と属性には、基本的な検証のための機能が組み込まれていますが、ユーザーがデータを入力するときやフォームを送信しようとするときに、より確実な検証を行うために JavaScript を使用する必要があります。
ログイン フォームの Codelab のステップ 5 では、Constraint Validation API(広くサポートされています)を使用して、組み込みのブラウザ UI でカスタム検証を追加し、フォーカスと表示のプロンプトを設定します。
詳しくは、JavaScript を使用して複雑なリアルタイム検証を行うをご覧ください。
分析と RUM
「測定できないもの、改善できないもの」が特に当てはまるのは、登録フォームとログイン フォームです。目標を設定し、成果を測定し、サイトを改善して、繰り返す必要があります。
割引のユーザビリティ テストは変更を試すのに便利ですが、登録フォームとログイン フォームでのユーザー エクスペリエンスを十分に理解するには、実際のデータが必要です。
- ページ分析: 登録とログインのページビュー、直帰率、離脱数。
- インタラクション分析: ゴール ファネル(ユーザーがログインフローまたはログインフローを放棄した場所)とイベント(フォームを操作した際のアクション)
- ウェブサイトのパフォーマンス: ユーザー中心の指標(登録フォームとログイン フォームがなんらかの理由で遅くなっているか、ある場合はその理由は何か)。
また、登録とログインのさまざまな方法を試すために A/B テストの実装や、すべてのユーザーに変更をリリースする前に一部のユーザーで変更を検証する段階的な公開を検討することもおすすめします。
全般的なガイドライン
UI と UX を適切に設計することで、ログイン フォームの放棄を削減できます。
- ユーザーがログインを探し回らないようにしましょう。ページの上部に、一般的な表現(「ログイン」、「アカウントを作成」、「登録」など)を使用して、ログイン フォームへのリンクを配置します。
- 焦点を絞る登録フォームは、特典やその他のサイト機能でユーザーの注意をそらす場所ではありません。
- 登録の複雑さを最小限に抑えます。他のユーザーデータ(住所やクレジット カード情報など)を収集するのは、そのデータを提供することで明らかなメリットがユーザーに生じた場合のみです。
- ユーザーが登録フォームを開始する前に、どのような価値提案を行うかを明確にします。ログインすることで、ユーザーにどのようなメリットがありますか。登録を促す具体的な動機付けを提示します
- 一部のユーザーはメールを使用しない可能性があるため、可能であれば、ユーザーがメールアドレスではなく携帯電話番号で本人確認できるようにします。
- ユーザーが簡単にパスワードを再設定できるようにし、[パスワードをお忘れの場合] のリンクをわかりやすくします。
- 利用規約とプライバシー ポリシーのドキュメントへのリンクを用意し、ユーザーデータの保護方法を最初からユーザーに明確に示します。
- 登録ページとログインページに会社または組織のロゴと名前を含め、言語、フォント、スタイルをサイトの他の部分と一致させます。フォームによっては、特に URL が大きく異なる場合、他のコンテンツと同じサイトに属していると思われません。
さらに詳しく
- 便利なフォームの作成
- モバイル フォームのデザインに関するおすすめの方法
- より優れたフォーム コントロール
- 使いやすいフォームを作成する
- Credential Management API を使用したログインフローの合理化
- WebOTP API を使用してウェブ上で電話番号を確認する
写真撮影: Meghan Schiereck(Unsplash)