はるさめ.dev

「Form Design Patterrns - シンプルでインクルーシブなフォーム制作実践ガイド」要点まとめ１

投稿日：Sat Feb 24 2024 01:02:57 GMT+0000 (Coordinated Universal Time)

Form Design Patterrns - シンプルでインクルーシブなフォーム制作実践ガイド を読んだので要点まとめ + α など

input と label を紐づける

<label for=“name”>名前</label>
<input id=“name” type=“text” />
  • テキストフィールドにフォーカスを合わせたときに読み上げをしてくれる
  • クリック領域が広がる（ラベルをクリックでもテキストフィールドにフォーカスできるようになる）

プレースホルダーの代わりにヒントテキストを使用する

<label for=“password”>
  <span>パスワード</span>
  <span>8文字以上で入力してください。</span>
</label>
<input id=“password” />
  • プレースホルダーは低コントラストで見づらい
  • プレースホルダーは１文字入力すると内容が見えなくなってしまい、複雑な内容は忘れてしまう可能性がある
  • 入力済みと勘違いしてしまう可能性がある
  • プレースホルダーをサポートしていないユーザーエージェントがある
  • 長いテキストは途中で途切れてしまう可能性がある
  • aria-describedby で紐づける方法もあるが、ラベルをクリックしてもテキストフィールドにフォーカスされない

フロートラベルは使用しない

フロートラベル： フォーカスするとプレースホルダのテキストがラベルの位置に移動するやつ

  • ラベルとヒントを一つとして扱うのでヒント用のテキストを記載することができない
  • プレースホルダと同じようなデメリット
  • ラベルの移動先が必要なのでスペースの節約にもならない

パスワード不要サインイン

入力されたメールアドレス宛にログインリンクを送信する

  • 入力フォームを削減できる
  • パスワードを覚えなくても良くなる
  • ただし、ログインフローが複雑になる
    • ユーザーが慣れていない
    • いちいちメーラーに移動するのが面倒
    • パスワードを覚えている・パスワードマネージャーを活用している人には冗長

パスフレーズの使用を促す

  • パスワードに比べてパスフレーズは覚えやすく十分に長く安全
  • 大文字、小文字、数字の使用を強制しないでも良くなる

ラベルは入力フィールドの左上に配置する

  • 目線の移動が少なく両方の要素を捉えることができる
  • 小さいビューポートでは横にスペースがない可能性がある
  • 拡大するとテキストがスクリーン外に消える可能性がある

入力フィールドは四方を線で囲む

  • 線で囲まれて中身が空白の場合は入力が必要なことがわかりやすい
  • 下線のみだと区切り線のようにみえ、枠の上と下どちらに入力するべきか分かりづらい

フォントサイズは16ピクセル以上にする

  • 小さすぎると読みづらい

コントロールのサイズは 44 x 44 以上にする

フォーカススタイルを削除しない

css の input:focus outline

  • キーボードユーザーがフォーカス位置を確認するのに役立つ

適切な input type を設定する

  • モバイルデバイスで適切なオンスクリーンキーボードが利用できる

プログレッシブエンハンスメント

  • ブラウザ、デバイス、ネットの質に関係なくどのようなユーザーにも合理的な体験を提供できるようにする
  • パフォーマンスに優れているため HTML と CSS を重視する

パスワードを表示できるようにする

  • パスワードに入力中の値が見えないとタイプミスの修正が難しい（すべてを削除して最初から入力するほうが簡単）
  • 大半のユーザーは背後に覗く人がいない状況で使用している
  • type=“password” と type=“text” を切り替えると、type=“text” 状態の場合、全角の入力が可能になってしまうことに注意すること
  • Edge ではブラウザの機能で切り替えボタンが表示されているため、時前で実装する場合は非表示にすること ::-ms-reveal

「パスワードの確認」フィールドを用意しない

  • ユーザーの手間が増える
  • タイプミスのリスクが増える
  • 誤った値を２回入力するリスクがある

マイクロコピー

「パスワード」ではなく「パスワードを設定」など意味がより明確になるようにラベルを設定する

  • 「パスワード」だとすでに登録済みのパスワードか新しく設定するパスワードか混乱するユーザーがいる

ボタンはボタンらしく、リンクはリンクらしく見せる

  • リンクは新しいタブで開けたり、ブックマークするなどボタンにできないことができる。
  • ボタンをリンクのように見せると新しいタブで開いたり、ブックマークできないのにできると勘違いさせてしまう

あるマテリアルを別のマテリアルの代わりとして使用しない

  • 上のボタンはボタンらしく、リンクはリンクらしくと同じで、ラジオボタンなのにチェックボックスのような見た目にしたり、チェックボックスをラジオボタンのような見た目にしては行けない

送信下は直線のフィールドのすぐ下に左揃えで配置する

  • 入力欄は左に寄せて上から下に向かって並べるので、同じ用に送信ボタンも配置すると自然。
  • 右揃えだと画面を拡大すると見えなくなってしまう可能性がある

ボタンのテキストは起こすアクションを明確で文字数を抑えて動詞にする

  • 素早く読めるように文字数は抑える
  • 明確さを犠牲にしてまで文字数を削る必要はない
  • 日本語の場合は「名詞＋する」という形の動詞があるが文脈上問題なければ省くことも検討できる

HTML5 のバリデーションの利用

  • 属性を追加するだけでフォームの送信時に入力をチェックできる
  • ブラウザが対応していない場合もサーバー側でのバリデーションにフォールバックできる
  • ブラウザによって挙動が統一されていないことに注意が必要
  • サーバー側でもクライアント側でも同じ用にエラーを表示するためには独自にデザインする必要がある

バリデーションエラー時のフィードバックとして title にエラー表示を設定する

「（２件のエラー）サービスの登録」などのようにする

  • スクリーンリーダーが最初に読み上げるため、問題があったことをユーザーに素早く知らせることができる
  • サーバーへのリクエスト後、ページをリロードする場合に有用

エラーサマリーを上部に表示する

エラーには対象のフォームへ移動するリンクを表示する

  • 下にスクロールしなくてもエラーが発生したことがわかる

入力フィールドのすぐ上にインラインエラーを表示する

  • ラベルに含めることでフォーカスしたときにエラーの内容が読み上げられる
  • フィールドの下に配置するとオートコンプリートパネルやオンスクリーンキーボードに隠れてしまう可能性がある

エラーが発生しているフィールドには aria-invalid を使う

  • フォーカスが当たるとスクリーンリーダーが無効などと読み上げてくれる

入力は柔軟に受け入れる

郵便番号の - はあってもなくてもプログラムで削除する・追加することで受け入れる事ができる。

  • オートコンプリートの違いや入力の癖を吸収できる

入力内容のチェックリストパターンを使用する

満たす必要があるルールを事前に列挙しておいて、満たされるとグレーアウトしたり✓表示を行う

  • ライブバリデーションのように１文字目からエラーが表示される早すぎるエラーや、フィールドを離れるタイミングでエラーを表示する遅すぎるエラーでユーザーの集中を阻害しない

送信ボタンを無効化しない

  • ボタンが存在するはずなのに押せない理由がわからない
  • フォーカスできないため、スクリーンリーダーを利用しているユーザーに送信ボタンの存在を知覚できない
  • コントラストが下がっているので読みにくい

エラーメッセージの内容

  • 簡潔
  • 一貫性を保つ
  • 具体的に示す
  • 専門用語を避ける
  • 平易な言葉を使用する
  • 能動態を使用する
  • ユーザーを避難しない

コメント