「Form Design Patterns」要点一覧 (その1)

• 公開日 : 2020年5月18日 (2023年5月17日 更新)
• カテゴリー : アクセシビリティ / ユーザビリティ

先にご紹介した監訳本「Form Design Patterns — シンプルでインクルーシブなフォーム制作実践ガイド」には、あらゆるユーザー (たとえ障害や何らかの利用状況を抱えていたとしても) にとって利用可能なフォームを提供するための具体的な考えかたや実装方法が、300ページにもわたるボリュームで詰まっています。

この記事は、主に本書をお読みいただいた方に向けて、その要点を一覧できるようまとめたものです。内容把握のチェックリストとしてご活用いただけたら幸いです。本書をお読みでない方も、この記事を通じてご興味をお持ちになりましたら、ぜひご一読いただければと思います。

3回に分けて記事にまとめていますが、今回はその1回目です。(「その2」「その3」も併せてご覧ください。)

第1章 登録フォーム

• フォームコントロールに対して、<label> 要素でラベルを付ける (フォーカス時のスクリーンリーダーでの読み上げ、タッチ領域の拡大のため)。
• プレースホルダーはラベルの代替にしない (入力を始めたら消えてしまうため)。
• フロートラベルは、結局はラベル用の領域を事前に確保しておかないといけないので、実はあまり有用ではない。
• ヒントテキストは、プレースホルダーではなく、フィールドの欄外に配置する。<label> 内に記述すれば、その分、タッチ領域のさらなる拡大になる。
• 「質問プロトコル」でフォーム入力項目をシェイプアップする。
• パスワード不要のサインインも検討できる (例 : メールアドレスを入力させ、メールを送信し、秘密のリンクにアクセスさせる)。
• ラベル (<label>) はフォームコントロールの上に左寄せで配置する (ビューポートが小さくてもラベルが常に見えるようにするため)。
  • チェックボックス / ラジオボタンは除く。
• 入力フィールドは、入力できることがシグニファイアとして伝わるようにデザインする (枠で囲む)。
• ラベルとフォームコントロールを近接させる (ゲシュタルトの法則)。
• タップターゲットのサイズは、44ピクセル四方以上を保つ。
• フォーカスを可視化する。
• <input> 要素は、内容に応じて適切に type 属性を設定する。
• CSS や JavaScript の適用においては、プログレッシブエンハンスメントを意識する。
• パスワードフィールドは、表示 / 非表示のトグルができると便利 (ただし実装方法はいろいろ議論あり)。
• フォームの最後に送信ボタンを配置する際は、左揃えで配置する。
• 送信ボタンの実装には <input type="submit"> または <button type="submit"> を用いる。後者のほうが柔軟で、他の要素を内部にネストできる (例 : アイコンを付ける、など)。 なお、サーバーへの送信をしないインタラクションのボタンは、<button type="button"> を用いる。
• 送信ボタンのラベルは、動詞にする。
  • ただし日本語の場合、「(名詞) + する」という形であれば、「する」を省くことも検討できる。
• バリデーション。エラーサマリーを冒頭に提示する。tabindex="-1" を設定し、表示されたエラーサマリーにフォーカスが自動的に当たるよう JavaScript で設定する。そこから個々の (エラーが発生した) フィールドにリンク (フォーカス) させる。
• <title> 要素にエラーが生じている旨を表示する、というのも有効 (サーバーへのリクエスト後、エラーメッセージを含むページをリロードする場合)。
• 個々のフィールドにおけるエラーメッセージ (インラインエラー) は、対象フィールドのすぐ上に配置する。ヒントテキストと同様に <label> 内に記述するのが望ましい。
• エラーが生じているフィールドの <input> 要素には、aria-invalid="true" 属性があると、スクリーンリーダーユーザーにも伝わりやすい。
• 入力フォーマットなど、システムで吸収できるものは、吸収する (ささいなミスは許す)。
• ライブの (リアルタイムの) バリデーションは、ユーザー体験をかえって不快にする可能性があるので注意する。
• パスワード入力では、チェックリストを消し込む形で、バリデーションを提示する方法もある。その場合、オンスクリーンキーボード使用時にも見えるように、フィールドの下ではなく上に配置するのが望ましい。
  • ただし、そのチェックリストの項目数が多いと、ラベルとフィールドが離れてしまうため注意が必要。
• 送信ボタンは (たとえユーザーの入力が不十分でも) 非表示 / 無効化しない。入力が不十分である場合は、アクセシブルな形でエラーメッセージを出せばよい。
• エラーメッセージは適切な言葉で表現する (簡潔に、具体的に、平易に、能動態で、ユーザーを非難しない、など)。

第2章 決済フォーム

• 「1ページにつき1つのこと」を意識する。アコーディオンで、長いプロセスを1ページにまとめるのは、特にエラー発生時のユーザーによる修正作業など、実はかえってユーザーにストレスを与える恐れがある。
• 「1ページにつき1つのこと」の区切りかた (まとめかた) は、ユーザビリティテストで確認するのが望ましい。
• 一連のプロセスは、ユーザーにとって合理的なフロー、順序で尋ねる。
• 「ゲスト」での利用を可能にする。後で、ユーザーの任意で、サインインできるようにする。
• 個人情報 (メールアドレス、電話番号など) など、ユーザーにとってセンシティブな情報を入力させる場合は、理由 (使用目的など) を明示するとよい。ヒントテキストと同様に <label> 内に記述する。
• 任意フィールドと必須フィールドの識別。「質問プロトコル」によってフィールドが厳選されれば、自ずと必須フィールドが基本になるはずなので、その場合は、任意フィールドに対して「任意」であると明示する (<label> 要素内に明記する)。この場合、aria-required や required 属性は不要になる。
• フィールド幅は、入力される情報量に応じて適切に設定する。フィールド幅が、さりげない手がかりとしてユーザーに認知される。
• ラジオボタン / チェックボックスは、<fieldset> でグループ化し、<legend> でグループ名をラベリングする。
• スマートデフォルトをあらかじめ設定するのが望ましい場合は、設定する。
• ラジオボタン / チェックボックスにおけるラベル (<label>) は、クリック / タッチ領域の拡大という点でもとても大事。
• <textarea> 要素で、テキスト量 (文字数) を制限する必要がある場合、max-length は使用しない。代わりにリアルタイムの文字数カウントダウン表示を提示し、スクリーンリーダー経由でも伝わるようライブリージョン (aria-live="polite") として実装する。文字数カウントダウンが常に表示されるのが適切でない場合は、基準値に達したときに初めてフィードバックが提供される、という形にしてもよい。
• autocomplete 属性によって、フォームを埋める労力を減らし、またタイポを防ぐことができる。
• <input type="number"> は、あくまで「数」の入力で用いる。文字列としての「数字」を扱う場合は、<input type="text"> を用い、patten 属性を使ってオンスクリーンキーボードを最適化する。
• 請求先とは別に、配送先の住所の入力したい場合など、大半のユーザーにとって必要のないフィールド群がある場合は、プログレッシブディスクロージャーによって、任意で展開表示させる。
• 入力内容の送信前チェックを用意し、必要に応じて項目ごとに修正できるようリンクを設ける。修正画面は「1ページにつき1つのこと」を適用する。
• 送信後の確認情報を適切に提示して、ユーザー体験 (UX) をよりよいものにする。
• 2回目以降の利用時には、既に入力したことのある情報を再入力させないようにする。
• プログレスバーは、条件分岐に対応できなかったり、モバイルでの表示が難しかったりするので、用いなくても済むようなデザインにするのが望ましい。
• 入力済の情報を編集する画面では、(編集せずキャンセルできるように) 明示的な「戻る」リンクを配置するとよい。