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

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

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

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

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

第5章 受信トレイ

• 二次元的なレイアウトにおいて、レイアウトテーブルは避ける。マテリアルオネスティに反するし、レスポンシブデザインの点でも難点。
• チェックボックスとテキストリンクが一対になっている (視覚的にはリンクテキストがチェックボックスのラベルとしても機能する) 場合でも、チェックボックス用のラベル (<label>) は必要。視覚的に隠す形で実装する。
• 必要以上に視覚的フィードバックを演出しない。チェックボックスであればチェックが入っている / 外れていることが示せていれば十分。
• 複数の送信ボタンがある場合、[Enter] キーを押すと (暗黙的な送信として) どのボタンが実行されるのかがわからない (実際にはドキュメントソースの最初のボタンが実行されるが、ユーザーには伝わりにくい)。実行結果の影響がもっとも少ないボタンを最初に配置するとよい。
• スティッキーメニューはなるべく避ける (キーボード操作でアクセスしにくく感じられてしまう、特にモバイルや画面拡大時にコンテンツ本文を覆い隠してしまう、という懸念があるため)。
• 特定の条件のとき (たとえば、受信トレイで項目がひとつも選択されていない場合)、ボタンを非表示する、といった実装は避ける。
  • デフォルトで非表示にすると、使用可能なアクションがあることにユーザーが気づかない恐れがある。
  • 結局はあらかじめボタン表示用のスペースを確保しておく必要があり、UI をコンパクトにするという点では限界がある。
  • ボタンが表示されるという余計な視覚的フィードバックが生じることで、ユーザーの意識がそっちに持っていかれてしまう、という問題もある。
• セレクトボックス (<select>) はメニュー用途で用いない。
  • 選択したら即実行 (サブミット行為を伴わずに) という UI は、ユーザーの混乱を招く恐れがある (WCAG 達成基準 3.2.2)。
  • スマートフォンではセレクトボックス、タブレットや PC ではメニューを展開表示、という実装はレスポンシブではない (アダプティブなデザインになる) のでよくない。
  • サーバーへのリクエスト方法が利用デバイスによって異なる、という点でもよくない。
• アダプティブデザインではなく、レスポンシブデザインを採用する。デバイスの種類ではなく、あくまでもコンテンツの表示領域という視点で考える。
  • あらゆるデバイス幅に対応したデザインを用意するのは不可能。
  • デバイス幅に応じてコードを追加する形だと、その分、パフォーマンスに影響する。
  • 大事なのは、デバイスの種類に関わらず一貫性のあるユーザー体験を提供すること。
• メニューの選択などで、マウスオーバーによるインタラクションは用いない。クリックでトリガーする。
• ポップアップが開く UI では、ユーザーにポップアップの存在を知らせるために、aria-haspopup を記述する。
• 折りたたみ / 展開させる UI では、ユーザーに状況を知らせるために、aria-expanded を記述する。
• アイコンとテキストラベルが隣接する場合など、アイコンが純粋な装飾でスクリーンリーダーユーザーにとって情報ノイズになる場合は、aria-hidden="true" を記述する。
• すべての項目を選択する (全項目のチェックボックスに一括でチェックを入れる) 機能は、それ用のチェックボックスを設けるのもよいが、より明確に「すべてを選択」ボタンを実装することも検討する (すべて選択された状態の場合、ボタンのラベルは「すべての選択を解除」に切り替える)。
• アクションが完了した旨のメッセージを出す場合、当該メッセージの要素には role="alert" を記述する。
• アクション完了メッセージは、トーストバナーのような一時的な表示 (時間が経つと消える) では実装しない。また、コンテンツの一部を覆い隠すようなオーバーレイ表示も避ける。インレイで表示し、ユーザーの任意でのみ消せるようにする。
• アクションの実行においては、フールプルーフ (実行前の確認メッセージ) ではなくフェイルセーフ (動作完了メッセージで必要に応じて undo できる) を採用する。

第6章 検索フォーム

• 検索機能にスコープがある場合は、ラベルやヒントテキストで明示する。さもなくば、何でも検索できるようにする。
• 検索フォームにおいてもラベル (<label>) は必要。晴眼者にとっては、送信ボタンが疑似ラベルとして機能するため、<label> は視覚的に非表示にしてもよい。
• 検索フォームの送信ボタンは、省かないのが望ましい。[Enter] キーによる暗黙的な送信を知らないユーザーもいることに配慮する。どうしても送信ボタンを省く場合は、ボタン要素に tabindex="-1" を記述する (でないと、[Tab] キーでのフォーカス対象となってしまい、目が見えるキーボード操作ユーザーの混乱を招く恐れがある)。
• トグルボタンと JavaScript でコンテンツを展開 / 折りたたみする場合、プログレッシブエンハンスメントを意識する。トグルボタンは素の HTML に書くのではなく、JavaScript で動的に差し込む。また、JavaScript 無効時には、コンテンツを隠さず展開表示させる。
• コンテンツを動的に展開させる際は、フォーカスはそのポップアップされた最初のフォーカス可能要素に自動的に当てることを検討する。
• 検索結果 (SERPs) などで、無限スクロールを採用することは避ける。
• role="search" ランドマークによって、スクリーンリーダーユーザーが素早く検索機能にアクセスできるようにする。

第7章 フィルターフォーム

• インタラクティブフィルターとバッチフィルター。どちらがよいかは慎重に検討する。多くの場合、バッチフィルター + Ajax の組み合わせがよさそう (複数のファセットを柔軟に選択でき、そのうえ都度送信ボタンを押さずに済むため)。マテリアルオネスティには反するがユーザーのメンタルモデルを優先する。
  • バッチフィルター + Ajax の組み合わせを採用するにしても、送信ボタンはソースコード上では実装する (プログレッシブエンハンスメント)。
• Ajax のローディング状態の提示。ライブリージョンとして実装し、スクリーンリーダーユーザーにも「読み込み中」「読み込み完了」を伝える (フィルターによる絞り込みの場合、読み込み完了時に、読み込まれた件数も伝達できるとなおよい)。これらのテキストは視覚的に非表示でもよい。
• Ajax ではブラウザの「戻る」ボタンがユーザーの意図通りに機能しない問題がある。その解決として、HTML5 では History API がある。
• ファセット (フィルターの選択肢) のサイドバーが長い場合、フィルタリングした結果が見えない (スクロールアップしないと見えない) 恐れがある。ファセットをプログレッシブディスクロージャーにするなどして、フィルタリング結果が目につきやすくする。
• 小さいビューポート (スマートフォンなど) ではフィルターフォームをどう見せるか。ファセットをドロワーにして、フィルタリング結果がチラ見えする形で (完全には覆い隠さない形で) オーバーレイさせる、という手がある。

第8章 アップロードフォーム

• アップロードするファイルが1つだけなら、標準のファイルピッカー <input type="file"> で十分。ただし、スタイル (CSS) の設定はブラウザが対応しておらず実質不可能。実はドロップゾーンとしても機能するが、大半のユーザーはドラッグ＆ドロップでファイルをアップロードできることを知らない。
• 複数ファイルをアップロードさせる場合、<input type="file" multiple> がお手軽だが、対象ファイルが異なるディレクトリにある場合、対応できない。また、multiple 属性に対応していないブラウザもある。
• ファイルを選択しアップロードする一連の操作を、何度も繰り返し行なうことができる「持続的なアップロードフォーム」がおすすめ。アップロード済みのファイルはファイルピッカーの上に一覧表示され、クリックして見たり削除することができるようにする。
• 併せて、ファイルピッカーの周囲 (<div> で囲む) を広めのドロップゾーンとして機能させ、背景色を塗ることで視覚的にもわかりやすく提示する (ドラッグオーバー時のスタイリングも含めて)。ドロップゾーン内では、ファイルピッカーのラベル (<label>) を [Tab] キーでアクセス可能なクリッカブルボタンとしてスタイリングする。
• アップロード中の進行状況を明示する。アップロードが完了したら完了の旨を明示する。アップロードのエラーが生じた場合はエラーを明示する。これらの情報は、スクリーンリーダーユーザーにも伝わるように、ライブリージョンとして実装する。
• アップロード可能なファイル形式は、柔軟に対応したい。スプレッドシートであれば、エクセルだけでなく CSV も許容する、など。
• <input type="file"> の accept 属性で、ファイルの種類を指定できる。
• <input type="file"> の capture 属性で、使用するカメラを指定できる。

第9章 経費フォーム

• 複数の情報を作成 / 追加する場合。「持続的なフォーム」「1ページにつき1つのこと」「さらに追加」パターンが検討できる。条件分岐の有無や使用頻度などの観点から、ユーザビリティに優れたものを選択する。
• 「さらに追加」パターンを用いる場合 :
  • 項目の追加や削除が生じた際、フィールドとラベルを紐付ける id 属性値 (動的に変化する) を適切に管理する。
  • 項目を削除する場合のフォーカス制御をしっかり検討する。ブラウザ任せにしない。見出しにフォーカスを当てるのも一考。
  • 項目を追加した場合のフォーカスは、新しく追加されたフィールドにフォーカスを自動的に当てるのが自然。
• 項目追加 / 削除のフィードバックは、必要十分なものにとどめる。不必要に余計なアニメーションを加えたりしない。
• tabindex="-1" (つまり [Tab] キー操作ではフォーカスを当てないが、JavaScript によってフォーカスを当てる) の要素に対しては、インタラクティブな要素であるという誤解を避けるため、フォーカスリングなどの視覚化はしない。

第10章 長くて複雑なフォーム

• 「事前にチェック」パターン。あらかじめユーザーに理解しておいてほしいことを事前に提示し、自身がサービス利用に適格であるかどうかを自ら判断できるようにする。
  • 一連のウィザード的な質問によって、具体的なコンタクト先にユーザーをナビゲートする、という手もある。
• 「タスクリスト」パターン。一連のプロセスの中の子タスクを一覧提示し、完了状況を示す。また、各タスクへのリンクを設け、プロセスの途中、都合のよいときに都度タスクに取り組んだり、また取り組み済みのタスクの編集をしたりできるようにする。
• プロセスやタスクの所要時間 (どのくらいかかるのか) の目安を示すとなおよい。