「Form Design Patterns」要点一覧 (その2)
先にご紹介した監訳本「Form Design Patterns — シンプルでインクルーシブなフォーム制作実践ガイド」には、あらゆるユーザー (たとえ障害や何らかの利用状況を抱えていたとしても) にとって利用可能なフォームを提供するための具体的な考えかたや実装方法が、300ページにもわたるボリュームで詰まっています。
この記事は、主に本書をお読みいただいた方に向けて、その要点を一覧できるようまとめたものです。内容把握のチェックリストとしてご活用いただけたら幸いです。本書をお読みでない方も、この記事を通じてご興味をお持ちになりましたら、ぜひご一読いただければと思います。
3回に分けて記事にまとめていますが、今回はその2回目です。(「その1」「その3」も併せてご覧ください。)
第3章 航空券予約フォーム
- 選択肢が多い中からユーザーに選ばせる場合、どの UI をチョイスすべきか？
- セレクトボックス (<select>) は、操作が煩雑になりがち。
- ラジオボタンは、項目数が多い場合は不向き。
- 検索ボックスは、タイプミスやマッチするデータが無いリスクが想定される。
- データリスト (<input type="text"> と <datalist> の組み合わせ) は挙動が不安定。
- カスタムのオートコンプリートの実装を検討する。
- 裏側にセレクトボックス (<select>) があり、拡張された可視 UI として role="combobox" のテキストボックスと、選択肢のリスト (role="listbox" の <ui>、role="option" の <li> から成る) がある。テキストボックスでの入力に応じて選択肢 (<li>) の提示が絞り込まれ、最終的に選ばれた <li> の値が <select> の <option> の value としてサーバーに渡される、という具合。
- オートコンプリートで選択肢の件数が変動する場合、ライブリージョン (aria-live="polite") も併せて実装する。
- コントロールには1つのタブストップを設定する。オートコンプリートのコンボボックスの場合、テキストボックスをタブストップとし、その下に提示されるリスト項目はタブストップとしない。代わりに矢印キーで回遊できるようにする。
- オートコンプリートのリスト項目がフォーカスされた場合、その項目には aria-selected="true" を適用する (フォーカスされていないリスト項目は aria-selected="false")。また、フォーカスされていることが視覚的にわかるようスタイリングする。
- オートコンプリートにおいては、エンドニムやタイプミスを吸収する (data-alt 属性)。
- 日付の入力は、どの UI をチョイスすべきか？
- セレクトボックス (年、月、日の <select>) は入力が面倒。
- テキストボックスは、日付フォーマットのバラツキの面で課題。
- 画面外のものから転記させる場合 (例 : クレジットカードに記載された有効期限)、そのフォーマットのまま入力できるようにテキストボックスを1つ用意するのがよい。
- ユーザーが記憶している日付 (記念日など) は、年月日のテキストボックスで入力させるのがよい。
- 転記や、記憶している日付の入力以外は、デートピッカーの使用を検討する。日付フォーマットの違いを気にすることなく、ユーザーに日付を入力してもらうことができる。
- デートピッカーは、ネイティブのものが使えればをそれを使う。ブラウザが <input type="date"> をサポートしていない場合は、カスタムのデートピッカーをアクセシブルな形で提供する (各種 UI コンポーネントのキーボード操作、テーブルで提示されるカレンダーのスクリーンリーダーでの読み上げ、など)。
- 数値入力 (例 : 人数や個数の入力) では、ステッパーを採用するとよい。
- グループ (ラジオボタン / チェックボックス) におけるバリデーション。<legend> 要素内にエラー表示をする。また。<fieldset> 内に aria-invalid="true" を適用する。
- ラジオボタン / チェックボックスのグループが複数あるようなケースで、<fieldset> を入れ子にするのは避ける (<input> 要素にフォーカスが当たったときにどちらの <legend> を読み上げるかが、スクリーンリーダーによって一定でないため)。
- ラジオボタンは丸く、チェックボックスは四角く、スタイリングする。
- ラジオボタン / チェックボックスを隠し、そのラベルのみを提示することもできる (航空機予約の座席選択など、小さいビューポートにも対応する形で、二次元的に選択肢を配置する場合)。その際、状態 (チェックの有無) の可視化はラベル部分に対して適用する。
- 二次元的に選択肢を配置する場合、スクリーンリーダー (一次元的な情報取得) 向けに、補足テキストをラベルの中に記述する (航空機の座席であれば「窓側」「通路側」など)。
- 座席選択のチェックボックスで、既に他者が予約済み (選択不可) の座席がある場合など、<input> 要素を無効化する (disabled 属性を付ける) ことが合理的なケースもある。
第4章 ログインフォーム
- ラベルは具体的に記述する。ユーザーに (意味や意図を) 考えさせない。ヒントテキストで具体性を担保するのもよい。
- 自動大文字化、コートコレクト、スペルチェックは、固有名詞入力のフィールド (名前、メールアドレス、など) では無効化する (autocapitalize="none"、autocorrect="off"、spellcheck="false")。
- 入力すべき情報に制約がある場合は事前にヒントテキストとして提示する (例 : パスワードフィールドにおける文字数やフォーマット)。
- 複数のテキストボックスの並び (例 : 暗証番号の一部の特定の桁番号を入力させる) などで、自動タブ移動を実装するのは避ける。[Tab] キーで行きつ戻りつするのは面倒。視覚障害者ユーザーの場合、状況を見失う恐れもある。
- テキストボックスは、まとめられる場合はまとめる (なるべく分けない)。
- ラベルの一貫性を保つ。「ログイン」に対して「ログアウト」、「サインイン」に対して「サインアウト」など。
- 「ユーザー名とパスワードが一致しません」だと、どちらを修正すべきかわからない。具体的にどちらが間違っているのかを伝える。まずユーザー名を入れて、OKなら次の画面でパスワードを入れさせる、という UI が最近は増えてきている。
- ログインと登録 (サインアップ) を同じ画面に並べない。別の画面にして、お互いにリンクで行き来させる。
- 「パスワードをお忘れの場合」リンクは、フォームの先頭 (フィールド群の上) に配置する。
- ソーシャルログインを用いる場合は、ユーザーの許可なく目的外の使用はしない旨を明記する。
- ソーシャルログインを用いる場合は、以前にユーザーがどのアカウントでログインしたか忘れてしまうケースがあるので、自動的にアカウントを統合 / 連携させる (ユーザーの任意で連携の解除も自由にできる) のが望ましい。
- 複数のログイン手段を用意すること自体は一見便利だが、オプションが多すぎるとかえってユーザーの選択負荷につながる恐れもあるので、バランスを大切に。