ログインの入力でつまずく?パスワードと確認コードの貼り付けを確かめる

会員サイトで、長いパスワードや確認コードの打ち直しに困っていませんか。制作を依頼する側と制作担当が、入力を助ける方法を確かめる手順を説明します。
貼り付け・自動入力・認証の完了を、別々に確かめます。

会員ログインの入力を検討する、説明用の架空の制作場面です。実サイトの操作や本人確認の成功を示すものではありません。
まず、どの画面で入力に困るかを確かめる
認証は、そのアカウントを使う本人かどうかを確かめる手続きです。ここでは、登録済みの会員がログインするときの入力を扱います。文字を欄に入れられたことと、本人確認が終わって会員ページへ進めたことは別です。
最初に、対象の画面と止まる操作をそろえます。パスワードを入れる画面なのか、追加の確認コードを入れる画面なのかを分け、作業用か公開先か、ブラウザーと画面幅も確認します。同じ「貼り付けできない」でも、何も入らない場合と、一部だけ入る場合では調べる箇所が違います。
長い文字列を覚えたり見ながら打ち直したりする操作は、人によって大きな負担になります。W3CのWCAG 2.2の認証に関する基準では、記憶や転記に頼る操作に対し、入力を助ける仕組みや別の方法などを扱っています。この記事の簡易確認だけで、サイト全体の適合は判定しません。
制作担当と、試してよい作業用画面と試験用アカウントの範囲を先に決めてください。貼り付けの受け方を見るだけなら、承認された仮画面と架空の試験文字列を使う方法もあります。その結果は実サービスの認証試験とは分けます。実際のパスワードや確認コードを相談文、画面写真、作業記録へ載せる必要はありません。
以降の例は、別々の作業用会員サイトを想定した架空の記録です。実在する会員のログインや、この記事の制作中に行った認証試験ではありません。
パスワードの貼り付けと自動入力を分ける
貼り付けは、コピーした文字を選んだ欄へ入れる操作です。自動入力は、ブラウザーやパスワード管理アプリが、保存した情報を対応する欄へ入れる補助です。手で貼り付けられた場合でも、自動入力を試したことにはなりません。
PCでは、試験用の文字列をコピーして対象の欄を選び、編集メニューの「貼り付け」や、その環境の貼り付けキーを使います。スマートフォンでは、対象の欄を選んで貼り付けメニューを使います。制作担当は、文字が入るかだけでなく、途中で切れたり、意図しない変更が加わったりしないかも、許可された試験条件で確かめます。
一つ目の架空例には、パスワード欄へ試験文字列を貼り付け、「欄に入力された記録あり」とだけ残っています。全文が欠けずに入ったか、自動入力が使えたか、認証が完了したかは、この記録からは分かりません。入力できたという観測を、ログイン成功へ読み替えないでください。
自動入力は別の試行にします。承認された試験用の保存情報で、対象の欄が認識されるか、選んだ情報が入るかを確認します。自動入力されないときも、ただちにサイト側の原因とは決めず、欄の作りと試験条件を制作担当が照合します。利用者へ管理アプリの変更やブラウザー保護の解除を一律に勧める手順にはしません。
パスワードを表示する機能がある場合は、利用者が自分で表示・非表示を選べるかも見ます。GOV.UKのパスワード入力部品の説明は、通常は文字を隠し、利用者が表示を選ぶ方法と、貼り付け・自動入力の支援を示しています。表示切替は入力確認の補助であり、本人確認が終わったという表示ではありません。
確認コードは全文を一度に入力できる?
確認コードは、ログイン時などに本人確認のため入力を求められる文字列です。複数の小さな欄へ一文字ずつ入れる画面でも、利用者が全文を一度に貼り付けたときの扱いを確かめます。パスワード欄の結果を、そのまま確認コード欄へ当てはめないでください。
二つ目の架空例は、別の作業用会員サイトの確認コード画面です。全文の架空コードを一度貼り付けたところ、先頭欄に先頭の一文字だけ入り、他の欄は空欄という記録です。原因、別の入力方法、認証の完了はいずれも未確認です。一つ目の例を直した後の結果ではありません。

二つの架空記録と未確認の項目を、全文で読む
貼り付けの入力結果を、項目ごとに比べる
二つは別サイトの架空の記録です。修正前後や同じ人の連続した操作ではありません。実パスワードや確認コードの値は含みません。「未確認」は、なし・失敗・成功という意味ではありません。
先に比べるところ|欄へ何が入ったか
パスワード欄では入力された記録があります。別サイトの確認コード欄では、全文を一度貼り付けても先頭欄に一文字だけ入り、他の欄は空欄でした。どちらも認証の完了は未確認です。別の画面・環境の記録で、修正前後の比較ではありません。
二つの別記録について、同じ項目を続けて比べます。
欄への入力結果
- パスワード欄の別記録
- 欄に入力された記録あり
- 確認コード欄の別記録
- 先頭欄に先頭の一文字だけ入り、他の欄は空欄の記録
対象の欄
- パスワード欄の別記録
- パスワード欄
- 確認コード欄の別記録
- 一文字ずつ入れる複数の確認コード欄
行った入力操作
- パスワード欄の別記録
- 許可された架空の試験文字列を貼り付け
- 確認コード欄の別記録
- 全文の架空確認コードを一度貼り付け
対象の画面
- パスワード欄の別記録
- 既存会員のログイン画面
- 確認コード欄の別記録
- 既存会員の確認コード画面
試した環境
- パスワード欄の別記録
- 作業用会員サイト/Chrome/幅390(架空)
- 確認コード欄の別記録
- 別の作業用会員サイト/Chrome/幅390(架空)
記録の場面
- パスワード欄の別記録
- パスワード欄の貼り付けを確認した別記録
- 確認コード欄の別記録
- 確認コード欄の貼り付けを確認した別記録
両方に共通する記録
- 自動入力の結果
- 未確認
- 利用できる別の方法
- 未確認
- 認証の完了
- 未確認
- アカウントの回復
- 未確認
- 原因
- 未確認
- 変更後の結果
- 未確認
自動入力・別の方法・認証の完了・回復・原因・変更後の結果は、両方とも未確認です。欄に文字が入ったことを、認証成功やアカウント回復とは扱いません。
担当者が確認するときは、対象の欄を選び、承認された試験文字列の全文を一度に貼り付けます。その直後に、どの欄へどこまで入ったかを読み、別の欄へ移動した後の状態も分けて記録します。ここで入力結果を確かめる操作と、認証ボタンを押す試験は別です。実サービスへの送信は、この確認だけから進めません。
制作担当は、全文の受け取り方を調べます。一つの入力欄で全文を受け取る設計か、分割した欄へ文字を振り分ける処理があるか、貼り付けた文字を処理する部分で一文字だけに切っていないかを、実装と照合します。複数欄という見た目だけから原因を断定せず、利用者に一文字ずつ転記させずに済む方法を検討してください。
図の二つの記録で、入力・自動入力・認証の完了を分けて読めるようにしました。全項目と未確認の内容は、図の直下から文字でも読めます。空欄だったという二つ目の入力観測と、まだ調べていない項目の「未確認」は区別しています。
別の方法と、ログインの全手順を確認する
パスワードを入れられても、その後の追加確認で手入力だけを求められるなら、会員が最後まで進めるかは分かりません。ログイン画面から追加確認、完了後の画面まで、必要な手順を実際の設計に沿って並べます。アカウントを回復する経路がある場合も、別に確認します。
別の方法とは、同じ文字をもう一度打ち直すだけではなく、そのサービスで利用できる異なる本人確認の経路です。何が利用できるか、利用者がその方法を選べるかを確認してください。二つの架空例では代替の方法を調べていないため、「方法がない」とは書けません。新しい認証製品を無条件に導入する結論にもなりません。
W3Cの認証基準の解説は、パスワード管理や貼り付けによる入力支援、追加の確認、回復時の経路を説明しています。パスワード欄だけでなく、必要な認証の手順を通して、覚える・転記する負担を助ける方法が使えるかを見ます。
WCAGは、Webの内容をさまざまな人が使えるようにするための基準です。この認証の項目はその一部です。貼り付けの一試行だけでサイト全体を合格とも違反とも決めず、対象の基準、手順、別の方法、未確認の範囲をそろえて評価します。
制作依頼では「ログインを簡単にする」だけでなく、「パスワードの貼り付けと管理アプリからの入力を分けて試す」「確認コード全文の貼り付けを試す」「追加確認と回復の経路も確かめる」と、必要な操作を具体的に示してください。認証自体をなくす依頼とは分けます。
制作担当は、欄の名前と入力処理を調べる
欄の名前は、利用者や読み上げソフトが「何を入れる欄か」を識別するための情報です。入力目的は、ブラウザーなどへ、その欄が現在のパスワード等のどの情報を求めるか伝える指定です。画面に名前が見えることと、プログラム上で欄と名前が対応することを両方見ます。
HTMLは、Webページの見出しや入力欄などを、ブラウザーに伝わる形で書くための言語です。HTMLで一般的なパスワード欄を作る場合の小さな説明例を示します。labelは欄の名前を対応させる部分、typeはパスワード欄であること、autocompleteは自動入力が扱う情報の種類を伝える部分です。既存会員のパスワードを求める例なのでcurrent-passwordとしています。これは動く認証フォームではなく、説明用の文字列です。
<label for="member-password">パスワード</label>
<input id="member-password" type="password"
autocomplete="current-password">
W3Cの技術例H100は、名前を対応させた入力欄や、貼り付けと入力補助を妨げない実装の一例です。この書き方だけが唯一の方法ではなく、上の指定を追加するだけで全体の動作が直る保証もありません。実際の部品と処理に合わせて確認します。
制作担当は、HTMLの名前と用途の指定に加え、貼り付け直後の処理、入力を一文字に制限する処理、送信前の値の扱いを、問題の部品に絞って調べます。確認コードの分割欄は、個々の欄だけでなく全文を受け取る処理も対象です。見た目の部品を変える前に、どの操作がどの処理へ入るかを確かめてください。
変更は許可された作業用環境で行い、同じ貼り付けと自動入力をもう一度試します。ブラウザー保護を下げる、外部の拡張機能で制限を回避する、必要な本人確認を外すといった一律の対応を、この入力点検から勧めるものではありません。
まとめ:同じ操作で確かめ、公開先は別に確認する
ログインの入力点検は、会員に覚えて打ち直してもらう前に、貼り付けと自動入力を使えるか確かめることから始めます。パスワード欄と確認コード欄、入力結果と認証完了、追加確認と回復の経路を分けて見ると、制作担当が調べる範囲を具体的にできます。
まず、制作担当と試験してよい画面を一つ決め、「どの欄へ、どんな方法で入力し、何が表示されたか」を共有してください。認証値そのものを記録する代わりに、全文が扱われたか、一部だけか、何がまだ未確認かを残します。別の二記録を修正前後として比べないようにします。
修正後は、問題が起きた同じ画面・ブラウザー・幅・入力方法で再確認します。貼り付けだけ直して自動入力が使えなくならないか、必要な関連操作も確認します。作業用で確認した結果を公開先へ自動的に移さず、公開先で許可された必要な確認を別に行い、認証完了まで試した範囲を明示してください。
サイト全体のキーボードや表示を整理したい場合は、企業サイトのアクセシビリティの初期点検が次の入口です。会員ログインではなく、相談フォームの必要項目や入力例を直したい場合は、問い合わせフォームの項目とエラーの決め方を参照してください。対象が違う点検を一つの「入力成功」へまとめずに進められます。
仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。


