フォームエラーメッセージをデザインするためのベストプラクティスは何ですか？
フォームデザインに関する多くの研究を見てきましたが、これまでのところ、エラーメッセージデザインのベストプラクティスに関する研究はありません。唯一のアドバイスは、各エラーは修正を目的とする無効なフォームフィールドに明確に関連付けられるべきだということです。これに関する調査はありましたか？
私が取り組んでいるいくつかの特定の問題があり、洞察やリソースをいただければ幸いです。
エラーメッセージの場所
ライブフォーム検証がある場合、フォーム要素に関連してエラー（または成功）メッセージはどこに表示されますか？
いくつかのオプション：
入力の右側に
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
ラベルの右側に
ラベルの上
ラベルの下
入力の下
位置についても考慮する必要がある厄介な問題がいくつかあります。
- ラジオまたはチェックボックスグループのエラーはどのように表示されますか？
- エラーメッセージの幅はどのくらいですか？
- エラーメッセージは複数行ですか？
エラーメッセージの可視性
場所に加えて、エラーメッセージの可視性がユーザビリティにどのように影響するかにも興味があります。それは重要ですか、それとも厳密に審美的な決定ですか？次の3つのオプションを検討してください。
編集：これまでの回答のいくつか、およびいくつかの興味深い例では、アクセシビリティに関していくつかの優れた点がありました。ただし、可能であれば、実際の研究のデータを実際に確認してください。また、これまでのところ、私が上記に挙げた2つの質問に答えた答えはありません。
- エラーは入力とラベルに関連してどこにあるべきですか？
- エラーメッセージ自体のデザインと可視性は、そのユーザビリティにどのように影響しますか？
フォームのアクセシビリティに関して、ライブ検証とサーバー側検証（ページの再読み込みが必要になる）の2つの潜在的に競合する使用例があるように思えます。ページがリロードされ、ユーザーがフォームの上部から再び開始する場合、特にアクセシビリティの観点からは、エラーの概要が理にかなっています。ただし、ライブ検証の場合、フォームデザインとアクセシビリティの両方の目的で、上部のエラー概要はあまり意味がありません。
ユーザーが実際の検証でフォームを実際にどのように使用するかを検討します。
検証は、ぼかしイベントで行われます。通常、のフォーカスは、一番上のリストではなく、次のフォーム要素にあります。スクリーンリーダーを理解しているので、フォームの先頭に戻ってエラーリストを読む必要はありません。スクリーンリーダーを使用していないユーザーの場合、上部のエラーリストによってフォーム全体が押し下げられ、エラーがフォームフィールドの近くの縦方向のスペースも占めることになります。長い形式では、エラーの概要が表示されない可能性があるため、これはユーザビリティの問題です。ログインのようにフィールドごとのエラーがある短い形式では、エラーの要約は過剰に見えます。すべてのフォームで、インターフェースが押し下げられ、ユーザーエクスペリエンスが低下します。
ライブ検証の場合、フォームエラーにアクセスできるようにしたい場合は、 ARIAライブリージョン を使用することをお勧めします。
カプセル化されたフラグは、すべてのEdgeケースに対応できる唯一の解決策です。フラグを入力ではなくラベルに指定すると、ラジオボタンやチェックマークグループ、またはスライダーやソーターなどの奇妙な入力との整合性が保たれます。
フィールドを赤で強調表示することも役立ちますが、常に可能とは限りません。以下の使用例。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
@jonWの答えを読んで、スクリーンリーダーに関する彼の考えにこれ以上同意することはできませんでした。私のソリューションは、実装によっては同等に効果的です。マークアップの入力の真北にフラグを配置し、ariaを使用して同じアクセシビリティを実現できます
このページの「インライン検証と検証イベント」セクションは、理想的なものと思われます。 http://semantic-ui.com/modules/form.html
あなたはすでに 必要なものの代わりにオプションのフォームフィールドをマークする のようです。 「必須」のインジケーターはないようですが、「オプション」のインジケーターもないようです。そのため、それについて触れておきます。
フォームで私がしたいのは、フォームを「マイクロ化」することです。フォームのすべてのフィールドに「検証インジケータ」を提供します。簡単にするために、それは単なる小さな円であるとしましょう。これは中立的な位置から始まります：疑問符の付いた灰色の円。オプションフィールドの場合は、チェックマークの付いた灰色の円です。ユーザーがフォームフィールドを離れると、そのフィールドはライブ検証され、次のことが起こります。
インジケーターが「成功」に変わります。緑の丸+チェックマーク、または「エラー」（例：赤の丸+感嘆符）
エラーがあった場合、フィールドが強調表示されます
エラーがある場合は、送信ボタンがグレー表示され（クリックしても機能しますが、最初のエラーに移動するだけです）、その上に一般情報メッセージが表示されます。
適切なヒントを書いている場合は、フィールドとヒントを強調表示するだけで十分です。別のエラーメッセージが必要だと思われる場合は、ヒントが作業に使用されている可能性があります。私の経験では、ほとんどの場合、ユーザーの入力エラーを適切なヒントでカバーすることが可能です。
ユーザーは精神的にフォームに戻ることを好まない。それはフィールドごとに処理され、ユーザーはフィールドごとに集中し、メンタルチェックリストを通過します。エラーが発生したときに指摘することで、このモードをサポートし、ユーザーを「後で」戻すことはありません。これは、ユーザーのフローの中断であり、「送信」をクリックしてから「ブロック」されて「返送」されるのが面倒です。問題が強調表示されているだけで、問題が発生したときに修正できる場合は、よりスムーズなエクスペリエンスになります。
エラーメッセージは、フォームフィールド自体の前に表示されます（少なくともマークアップ自体では表示されますが、理想的には画面上でもこのように視覚的に表示されます）。そのため、誰かがフォームを読んでいるときに、フィールドがエラーになってから、問題のフィールド-そのようにしてユーザーは精神的に準備されます"このフィールドの内容を読み込もうとすると正しくないため、修正する必要があります"。
これは、アクセシブルなフォームを作成するためにさらに重要です。誰かがスクリーンリーダーを介してフォームを読んでいる場合、上記と同じ理由でフォームフィールドが読み上げられる前に、エラーが表示される必要があります。 （フィールドの内容を聞いて} _フィールドにエラーがあったと通知された後、戻ってくる必要はありません）。これがエラーテキストを含める必要があるフォーム自体のラベルであり、スクリーンリーダーや古いブラウザが検出できることを保証できないため、単なるポップアップまたはスクリプトによるアラートではありませんこのテキスト。
また、長いフォームの場合、またはユーザーがキーボードを使用してタブボタンを使用している場合、折りたたみの下にいくつかのフィールドが存在する可能性があるため、フォームをタブダウンしても、フィールドがエラーになることに気付かない場合があります。次に、次のタブに移動します（フィールドはスクロールして表示されますが、エラーメッセージがその下にある場合は、エラーが画面外に表示されることがあります）。
最後に、エラーメッセージを表示するために使用すべき追加のルートがあります。
エラーをフォームの先頭にまとめて、ユーザーがいくつエラーがあるか、および何それらのエラーがあります。実際には、これらは問題のエラーフィールドにジャンプするリンクである必要があります（これらのフィールドに対するエラーメッセージがフィールド自体の前にあるべきもう1つの理由）。
この情報の多くは、 WebAIMの記事にあります：使用可能でアクセス可能なフォームの検証とエラー回復
例を示します。エラーはフォームの最初に表示され、リンクでもあるため、ユーザーは問題のフィールドに簡単に移動でき、エラーテキストも表示されます。
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
Human Factors International が発表した古い（2007）ホワイトペーパーには、エラーメッセージに関するいくつかのデータがあります。彼らがそのとき思いついた結論は次のとおりです。
...ほとんどのユーザーは、目標がフォームの完成である完了フェーズを通過し、その後にエラーが修正される修正フェーズまたは修正フェーズが続きます...即時エラーは、フォームが完成するまでほとんど無視されました。
したがって、エラーメッセージを表示する6つの方法のうち、これら3つは他の方法よりも効果的であることが判明しました。
- エラーを後でフォームに埋め込んで一度に表示する
- エラーを後でフォームに埋め込んで1つずつ提示する
- その後、エラーを1つずつ対話形式で提示する
明らかに、これ以上3はしません。ホワイトペーパーは「私たちが学んだこと：2007年を振り返って」と呼ばれています。 フォームに入力した後、サイトからダウンロードできます 。 :)
埋め込まれているダイアログvesusを除いて、エラーメッセージの配置については実際には触れていないため、これが本当に役立つかどうかはわかりません。
私が提案しようとしているのは、あなたの質問を読んだときに使用する解決策として頭に浮かんだものにすぎないため、関連する研究や資料を見つけられない可能性があることは明らかです。
「ライブフォーム検証がある場合、フォーム要素に関連してエラー（または成功）メッセージはどこに表示されますか？」という質問に具体的に取り組んでいます。
ラベル自体ではなくメッセージを表示するとどうなりますか
エラーが解決されると（フォームレベルのクライアント側の検証であると見なして）、ラベルの元のビューに戻り、ユーザーが残りのラベルを追跡できるようにすることができます。
このアプローチが機能するためには、メッセージを注意深くWord化して、ユーザーが必要なことを最小限の言葉で完全に伝えることができます。メッセージが長い場合は、フィールドの長さに折り返すことができます。
送信ボタンのすぐ上に、タグの形式で必須アイテムのリストがある場合があります。各タグは、それぞれのフィールドにハイパーリンクされている必要があります。ユーザーが上からフォームへの入力を開始すると、タグが消え続けます。ユーザーが送信ボタンを押す前に、すべての必須フィールドが入力されているかどうかを確認できます。アイテムを逃した場合、適切なタグを押すと、フィールドに簡単にスクロールして戻ることができます。
質問は実際の研究の結果に関係しているため、ここにリンクがあります 検証メッセージのさまざまなバリエーションに関する2009年の研究 Luke Wroblewski（Fill in the Blanksの著者）による。
検証メッセージを表示する最良の方法について非常に興味深い洞察を提供します。例えば、
[ぼかし]フォームをすばやく完成させるためにユーザーを支援する方法「後」（[ぼかし]）の方法を使用すると、参加者は「while」（[on keystroke]）および“ before and while”メソッドをそれぞれ使用します。
エラーメッセージの位置に関する限り、調査により、
フェードアウェイしない-フォームフィールドの外に成功メッセージを目立たせるフォームフィールド内に検証を表示しても、大きなメリットはありませんでした。これらのメッセージの位置付けは、必然的に、一貫していませんでした。 （検証メッセージをフォームフィールド内に表示することは可能ですが、標準のドロップダウンリスト内に表示することははるかに難しいため、これらの要素の外側に表示しました。）フィールド内検証は、外部に表示されるメッセージほど目立ちませんでした。フィールド。
2-メッセージの可視性（色など）については、次のとおりです 別の記事 UXデザイナーにメッセージの重大度を下げ、実際にユーザーに進捗状況について満足してもらう（そしてイライラしない）ように提案する進行なし）
とりわけ、基本的には、フォームエラーメッセージにはオレンジ/オレンジ色を使用する必要があると述べています。ユーザーがそれを見ると十分に警告されますが、物理的に赤く刺激されません（パニックを引き起こす可能性があります）。
検証メッセージを配置するのに最適な場所がどこにあるかについての調査はまだ行っていません。ただし、実用的な観点からは、ユーザーインターフェイスのガイドラインは十分に近いと思います。 Microsoftは、ガイドラインの情報について、ユーザビリティラボで多くの直接調査を行ったことがよく知られています。マイクロソフトがUIの貧弱な慣習を採用することを望んでいるのと同じように、一般にそれらの慣行はユーザーインターフェイス設計ガイドラインに従っていませんでした:)
Microsoftの Windowsユーザーエクスペリエンスインタラクションガイドライン は、ラベルの左側にあるアスタリスクとメッセージ付きのツールチップ：
download bmml source – Balsamiq Mockups で作成されたワイヤーフレーム
ガイドラインは、以下にまとめたいくつかの洞察に満ちたポイントも作成します。
- ほとんどのコントロールがオプションの場合は、何も指定しないでください（必要な入力がない場合はエラーメッセージを処理します。このアプローチにより、煩雑さが軽減されます）。
- ほとんどのコントロールで入力が必要な場合は、ラベルの後に「（optional）」を付けてオプションの入力を示します。
- すべてのコントロールに入力が必要な場合は、コンテンツ領域の上部に[すべての入力が必要]を配置します。
- 入力を早期に検証し、入力ポイントの近くにエラーを表示します。
- すぐに検出できるユーザー入力エラーのポップアップバルーンを使用します。 *バルーンは、インプレースメッセージを表示するために必要な利用可能な画面スペースや動的レイアウトを必要としません。
- 一度に1つのバルーンのみを表示します。
- 遅延エラー検出にインプレースエラーを使用します（たとえば、フォームを送信した後）。
興味深いことに、このトピックの Appleヒューマンインターフェイスガイドライン にはそれほど詳細はありませんが、以下は私が見つけた関連ポイントの要約です。
- 入力を早期に検証します
- キーを押すたびに入力を検証しないでください。検証を頻繁に行うのは面倒です。
繰り返しになりますが、これらは「エラーメッセージの設計のベストプラクティスに関する研究」ではないことに気づきましたが、これらのガイドラインの形成について調査が行われたことは確かであり、実用的なツールとして、このトピックの参照として最適です。
必須フィールドを*でマークするか、オプションのフィールドを（オプション）でマークします-これは、フォームの転換点によって異なります。
長いフォームがある場合-40フィールド（誇張するために-フォームには1つの画面に40のフィールドがあることをお勧めしません）と言い、それらの40、36が必要である場合、36を*でマークすることはノイズが多く冗長になります。
「オプションとしてマークされている場合を除いて、すべてのフィールドが必須です」という冒頭のステートメントを作成する方がはるかに簡単です。逆に、必須フィールドが比較的少ないフォームは、必須フィールドを示す必要があります。
言い換えれば、どれを例外として強調する必要があるかということです。
一般向けWebフォームの傾向は、ドロップオフ率を下げるために必要な情報を要求することだけです。したがって、すべてが必要になる傾向があるため、必須ではなくオプションのマークを付ける方向に移動します。これは、企業/ビジネスシステムでは常に当てはまるわけではありませんが、正当なオプションフィールドと必須フィールドを含む正当で詳細なフォームがあった場合。
エラーメッセージの配置に関する主な質問に関して：
ラベル->フィールドに関しては、フォームのデザインレイアウトに依存します。
フィールドの上にラベルを仮定すると、フィールドの右側にエラーメッセージが表示され、フィールドの境界線を赤で強調表示するだけでなく、「このフィールドは必須です」など、できるだけ多くの視覚的な合図が提供されます。赤。
理由：
1）フィールドへのエラーメッセージの近位配置
2）ラベルの近接性と関連付けを壊しません（これにより、ラベルとフィールドの間にエラーが発生します）
3）エラーメッセージは、修正が必要なものへの道標として機能しています（テキストは方法を示しています）。この意味で、標識は、ユーザーがアクションを実行する必要がある実際のこと、つまりラベルではなくフィールドを指す矢印にする必要があります。
4）ツールチップタイプのメッセージングは確立された慣例ではなく、他の誰かが指摘したように、リスクを実行したりアイテムを覆ったりします（ユーザーがこれを行うためにアクションを実行する実際のツールチップとは異なります）。アクセシビリティに良いとは思えない。
フェイススタイルアイコン+ハイライト+メッセージの私の最初の印象は、その感覚過負荷であるということです。情報を入手するためにどこに焦点を合わせるべきかわかりません。フィールドは途中で修正する必要がありますが、この前後に私の注意を争う視覚的な情報があります。これは、ユーザーが意味を消化するために多くの眼球運動と努力を意味します（純粋な仮説、私はユーザーテストを実行したことがありませんフォーム設定はまったく同じです）
Webフォームデザイン：空白を埋める を読んだ後、Webでこれについて調べたところ、最良のものは入力の下または入力の右側にあることがわかりました。
また、* = Requiredであるとの仮定は常に正しいとは限らず、一部の人々はそれを知らない。最も一般的な方法は、フォームの上部にある*について説明することです。または、私のお気に入りは、不要なフィールドをすべて削除し、フォームの上部に「すべてのフィールドが必要」または同様のものを配置することです。
フォームの上にある必須フィールドの概要を思い出させるために、良い提案が行われました。
ここに示されている最初の例は、かなり良い例（提出されたファイル自体の横のエラーメッセージ）だと思います。また、フィールドを赤で強調表示する必要があるかもしれませんが、それがより効果的であるとは証明されていません。
ラジオボタンの問題に関して、ラジオボタンにこのようなエラーメッセージが必要な場合、それはラジオボタンが正しいデザインオプションではないことを意味します。つまり、本質的に、ラジオボタンは、デフォルトで選択されている単一のオプションを1つだけ持っている必要があり、持っている必要があります。つまり、ラジオボタンは、「なし」オプションであるかどうかにかかわらず、常にデフォルトのオプションが選択された状態で表示される必要があります。それ以外の場合は、ニーズに合った他のデザインオプションを使用することを検討してください（例：複数のオプションが選択されている場合はチェックボックス、またはドロップダウンメニューなど）。
驚くべきエラーメッセージは、ユーザーを不安にさせる可能性があります。ユーザーの不安は、ユーザーにフォームを放棄させる可能性があります。ユーザーがそれを修正するためにユーザーをいかに台無しにしたかを強調する必要はありません。
安心できるエラーメッセージ を使用すると、ユーザーは間違いを修正するのがより快適になります。目標は、彼らに注意を喚起し、彼らに彼らの間違いを正すように導くことであり、彼らが大きな間違いをしたことを彼らに印象づけることではありません。
残念ながら、元の質問であるfromのエラーを表示する「標準的な」方法はないようです。
より詳細な答えを探してみましたが、形式にはさまざまなスタイルがあり、明確な解決策はないと思います。デスクトップで表示されるフォームは、通常、モバイルデバイスのフォームよりもエラーテキスト用のスペースが多くなります。最近では、Windows 8のモダンスタイル（旧称Metro）にIEの特定のスタイルガイドラインがあるため、今設計しているオペレーティングシステムについても考える必要があります。現代の各ブラウザーにはHTML5フォーム検証用の独自のスタイルがあり、これを標準化するのは面倒になります。
私が見つけることができた最も多くは、Jakob Nielsenからの一連のガイドライン（ http://www.useit.com/alertbox/20010624.html ）でした。これらのガイドラインは非常に広範で、唯一の明確なルールは、障害のあるユーザーが読みにくくする可能性があるため、色だけに頼ることはできない（フィールドのテキストを赤に変える）ことです。色覚異常のユーザーやスクリーンリーダーを使用しているユーザーは、テキストを区別できません。
これは、ここに掲載されているコールアウトソリューションで私が持っている唯一の予約です。障害を持つユーザーはそれを読むことができますか？
解決策は、ターゲットユーザーの大多数（Microsoft、Google、またはApple）で使用されているスタイルを採用して、それに合わせることです。
私が非常にフォーム集約的なプロジェクトのために設計したアプローチの1つを共有し、それはチームからは高く評価されましたが、いくつかの制約のために構築できませんでした。
インタラクション-カーソルUIを移動すると、送信ボタンをトリガーする前に修正するためのクライアント側の指示メッセージが表示されます。
私はグーグルが彼らのサインアップフォームのエラーメッセージのための簡単な解決策を持っていると思います;境界線を赤に変更して、フィールドとその下の単純なメッセージを赤で強調表示します。
これは、デザインを小さなデバイスにスケーリングするときに簡単で、明確かつ簡潔です。
Facebookのエラーメッセージの表示方法は、最も効率的でユーザーフレンドリーだと思います。スクリーンショットを確認してください。これは余分なスペースを消費しません。ユーザーは何が悪いのかを理解し、さらに詳しく知るために、フィールドにカーソルを合わせるだけで、フィールドが必須である理由を知ることができます。 
要約があるべきだと私は他の人に同意します。特定のアカウントか、「ここで問題が発生しました。ハイライトされたエントリを確認し、必要な変更を加えて、フォームを再送信してください。ありがとうございます。」
このメッセージは、送信フォームの上部または下部に表示されますが、表示せず、スクロールせずにすぐにユーザーに目立つようにする必要があります。したがって、javascriptマジックが送信ボタンによってページを押し下げることができれば、すばらしいです。ユーザーがいた場所なので、ページの移動や点滅が少なくなります。
次に、あなたの例から、最も単純な規則は「ラベルの下」バージョンになると思います。ラベルは、ユーザーが最初に方向付けする方法であり、そのすぐ下にエラーテキストがあり、すぐ下にアクション可能な場所（フィールド）があります。
私は「赤いボックス」の例と吹き出しの吹き出しが好きですが、私のお気に入りのUIは問題のフィールドがあるものです。
- 色を超えて異なって見えるエラーテキストでマークされています。イタリックまたは太字の色は、単なる色よりも優れています。独特の色（標準は赤）は良いですが、色覚異常のユーザーは誰でも知っていますよね？
- テキストやテキストの色を超えて他のフィールドから目立つ。すべての「ok」フィールドを少しグレー表示して、編集が必要なフィールドをより鮮明なコントラストで目立たせることができれば、とてもクールです。ただし、これらの「ok」フィールドの1つを編集したい場合でも、クリックすると「明るい」編集のために「開く」必要があります。
私はJonWが少し変更を加えて言ったことを2番目にしたいと思います。スクリーンリーダーを使用しているユーザーの場合は、フォームの上部にエラーを要約する必要があります。次に、フォームに入ったら、フィールドの前に個々のエラーをスクリーンリーダーに通知します。
私は職場でこの問題に直面し、使いやすくてアクセスしやすい方法を見つけたいと思いました。私はこのブログ投稿を見つけました http://www.nomensa.com/blog/2010/accessible-forms-using-the-jquery-validation-plug-in/ これは非常に役に立ちました。私は大学のアプリケーション開発で働いているので、このようなことは非常に重要です。
ベストプラクティス-機能することが証明されている方法-はありますが、実際のユーザーテストに勝るものはありません。それは非常に貴重です。
この例は、jQueryと検証プラグインに依存しています。
要約する：
- すべてのエラーをグループ化して、支援技術（AT）を使用しているユーザーが問題を鳥瞰図で理解できるようにします。
- ATがフィールドに入力する前にエラーをユーザーに警告するように、各フォームフィールドの上に個別のエラーを配置します。
- 可能な場合は、例のように、要約されたエラーを問題の個々のフィールドにリンクします。
最後に、特定のフォーマットが必要な場合は、エラーの数を減らすために（そして、よく見えない、またはまったく見ることができない人の生活を容易にするために）ラベルにフォーマットを必ず記載してください。
常に最善の方法
- インラインエラーメッセージを表示する
- そして、フォームを送信した後、空のままにした最初の委任フィールドまたは無効なデータのフィールドにフォーカスを設定します。
リアルタイム/ライブデータ検証の場合
- フィールド赤にフォーカスし、インラインエラーメッセージを表示する
サーバー側の検証の場合-たとえば、jsが無効になっている場合-
- それでも、空のフィールドまたは無効なデータのフィールドにフォーカスしたインラインエラーメッセージを表示する
通常の練習-
- データの検証はリアルタイムでなければなりません（ユーザーが無効なデータを入力したときに正しい形式を提案するツールチップ）
- 委任フィールドのチェックはフォームの送信時に行われる必要があります-これは、ユーザーデータ入力に対するシステムの介入が多すぎないようにするのに役立ちます）
それでも、「*」で必須フィールドをマークする従来の方法が最適です