What is best practice for designing form error messages?

Question

I've seen quite a lot of research on form design, but so far, I haven't come across any studies on error message design best practices. The only piece of advice seems to be that each error should clearly be associated with the invalid form field that it aims to correct. Has there been any research on this?

I have some specific issues I'm trying to work through and would appreciate any insight or resources.

Error message location

When you have live form validation, where should an error (or success) message appear in relation to the form element?

Some options:

---

To the right of the input

^{download bmml source – Wireframes created with Balsamiq Mockups}

---

To the right of the label

^{download bmml source}

---

Above the label

^{download bmml source}

---

Below the label

^{download bmml source}

---

Below the input

^{download bmml source}

---

There are some thorny issues that also need to be taken into account regarding location:

• How are errors displayed for radio or checkbox groups?
• How wide is the error message?
• Is the error message multi-line?

Error message visibility

Besides location, I'm also interested in how the visibility of the error message affects its usability. Does it matter or is it strictly a aesthetic decision? Consider the following 3 options:

^{download bmml source}

Edit: There have been some excellent points on accessibility in some of the answers so far, as well as some interesting examples. However, I really would like to see some data from actual studies, if possible. Also, none of the answers so far have really addressed the two questions I had above:

• Where should the error be located in relation to the input and label?
• How does the design and visibility of the error message itself affect its usability?

Regarding the accessibility of the forms, it seems to me as if there might be two potentially conflicting use cases, live validation and server-side validation (which would require reloading the page). If the page is reloaded and the user again starts at the top of the form, an error summary makes sense, especially from an accessibility perspective. However, in the case of live validation, the error summary at the top makes much less sense, both for form design and for accessibility purposes.

Consider how a user would actually use a form with live validation:

The validation occurs on the blur event. Usually, the focus of will be on the next form element, not the list at the top. As I understand screen readers, there wouldn't be any reason to return to the top of the form to read the error list. For users not using screen readers, the error list at the top pushes the entire form down, doubly so if the error takes up vertical space near the form field as well. In longer forms, this is a usability issue as the error summary may not be visible. In shorter forms that have per-field errors, like a login, the error summary just looks like overkill. For all forms, the interface would be pushed down, making a poor user experience.

For live validation, if you really want to make the form errors accessible, I think using ARIA Live Regions might be the preferred solution.

Answer 1

Encapsulated flags are the only solution I've found that reach all edge cases. Pointing the flag at the label rather than the input allows for consistency with radio buttons and check mark groups or weird inputs like sliders or sorters.

Highlighting the field with red is also helpful, but not always possible. Example usages below.

^{download bmml source – Wireframes created with Balsamiq Mockups}

^{download bmml source}

^{download bmml source}

In reading @jonW's answer, I could not agree more with his thoughts on screen-readers, and my solution can be equally as effective depending on implementation. You can place the flags just north on inputs in the markup, and use aria to achieve the same accessibility

---

"Inline Validation and Validation Events" section on this page seems about ideal: http://semantic-ui.com/modules/form.html

Answer 2

It seems you're already marking optional form fields instad of required ones. There seem to be no 'required' indicators, but no 'optional'-indicators, too, so I wanted to mention that.

What I like to do on forms is to "micro-gamify" them: For every field in the form provide a "validation-indicator". For simplicity, let's say it's just a small circle. This starts off on a neutral position: A grey circle with a question mark. For optional fields, it's a grey circle with a checkmark. Whenever the user leaves a form field, it's live-validated and the following things happen:

1. the indicator changes to either "success", e.g. green circle + checkmark, or "error" (e.g. red circle + exclamation mark)

2. if there was an error, the field is highlighted

3. if there is an error, the submit-button will grey out (clicking it will still work, but it only will take the user to the first error) and a general information message will be displayed above it.

If you're writing good hints it should suffice to just highlight the field and the hint. If you feel like you need a separate error message, chances are your hints could use some work. In my experience it is almost always possible to cover user input errors with good hints.

The user doesn't like to mentally go back in a form. It is processed field by field, the user focuses on it field by field, and goes through a mental checklist. By pointing out errors as they happen we support this mode and do not make the user go back "later on". It's a break in the flow of the user and an annoyance to click "submit" and then be "blocked" and "sent back". It's a much smoother experience if problems are just highlighted, and thus can be corrected, as they happen.

Answer 3

The error message should appear before the form field itself (at a minimum in the markup itself, but ideally visually shown this way on the screen too) so that when someone is reading the form they read that the field has errored before they then read the field in question - that way the user is prepared mentally that "the contents of this field I am about to read is incorrect and I therefore need to amend it".

This is even more important for creating accessible forms. If someone is reading the form via screenreader they need to be presented with the error before the form field is read out for the same reason as detailed above. (They don't want to have to go back after hearing the content of a field and then being told that field had an error). This is why it is the label of the form itself that needs to contain the error text, and not just be a popup or scripted alert because you can't guarantee that screenreaders or older browsers will be able to detect this text.

Also, if it's a long form, or if the user is browsing via keyboard and using the Tab button several of the fields may exist below the fold, so if you Tab down the form you might not notice that a field is in error until you have then tabbed into the next one (the field will scroll into view but if the error message is below it the error might be displayed off-screen).

Finally, there is an additional route you probably should take for your error messages:

You should summarise the errors right at the start of the form so that the user knows how many errors there are, and what those errors are. Really these should be links that jump you down to the errored fields in question (yet another reason why the error message against those fields should be before the field itself)

Much of this information can be found in the WebAIM article: Usable and Accessible Form Validation and Error Recovery

Here is an example. The errors are displayed at the beginning of the form and are also links so the user can easily navigate to the fields in question, where the error text is also displayed:

---

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 4

There is an old (2007) white paper presented by Human Factors International that has some data about error messages. The conclusion they came up with then was:

...most users go through a completion phase—in which the goal is form completion—followed by a correction or revision phase, in which errors are corrected...immediate errors were largely ignored until the form was completed.

Thus, of the six possible ways to present error messages, these three proved more effective than the others.

1. Present the errors afterward, embedded in the form, all at once
2. Present the errors afterward, embedded in the form, one by one
3. Present the errors afterward, in dialogues, one by one

Obviously we wouldn't do number 3 anymore. The white paper is called "What we have learned: Looking back at 2007." You can download it from their site, after filling out a form. :)

It doesn't really talk about placement of error messages, except dialog vesus embedded, so not sure if this is really helpful.

Answer 5

Just above the submit button, there could be a list of mandatory items in the form of tags. Each tag should be hyperlinked to the respective field. As the user starts filling the form from the top, the tags keep disappearing. Before the user hits the submit button, s/he can verify if all the mandatory fields have been filled or not. If s/he has missed some item, s/he can easily scroll back to the field by pressing the appropriate tag.

Answer 6

What I am about to suggest is merely what came to mind as a solution that I would use when I read your question, so clearly you may not find any related research or material to substantiate it.

I am specifically addressing the question "When you have live form validation, where should an error (or success) message appear in relation to the form element?"

What if we show the message instead of the label itself something like

As and when the errors are resolved (considering they are the form level client side validations) you may revert to the original view of the labels helping the user keep a track of the remaining ones.

For this approach to work you may want to carefully word your messages to convey completely what the user needs to do in the least possible words. If the messages are long you can wrap it to the length of the fields.

Answer 7

As the question concerns real studies' results, here is a link to a 2009 study on different variations of validation messages by Luke Wroblewski (author of Fill in the Blanks).

It provides very interesting insights into how best to display validation messages, some of which might interest you. For example,

[ON BLUR] METHOD HELPS USERS TO COMPLETE FORMS MORE QUICKLY When we used the “after” ([on blur]) method..., participants completed the form seven to ten seconds faster than when we used the “while” ([on keystroke]) and “before and while” methods respectively.

As far as the position of the error message, the study reveals that

NOT FADE AWAY—KEEP SUCCESS MESSAGES PROMINENT OUTSIDE FORM FIELDS Displaying validation inside form fields failed to deliver any substantial benefit. The positioning of these messages was—necessarily—inconsistent. (While it’s possible to make validation messages appear inside form fields, it is much more difficult to display them inside standard drop-down lists, so we displayed them outside these elements.) In-field validation was not any more noticeable than messages displayed outside the fields.

2- Concerning the message visibility (color, etc.), here is another article suggesting UX Designers to tone down the severity of those messages and actually make users feel good about their progress (and not frustrated over their no-progress)

Among other things, it basically says that we should use orange/orange color for form error messages: enough alarming when users see it but less physically stimulating as red (likely cause them to panic).

Answer 8

Good suggestions were made regarding the summary of required fields above the form as a recall.

I would say that a the very first example shown here is a rather good one (error message next to the filed itself). You migh want to highlight the field in red as well but it is not proven to be more effective.

Now regarding the radio buttons issue, I would say that if you need such an error message for a radio button, it means that the radio button is not the right design option on the first hand: indeed, by essence, a radio button MUST have and SHOULD ONLY have one single option selected by default. This means that a radio button should always present a default option selected, whether it be a "none" option. In any other case, you should consider using any other design option that fits your needs (eg.: checkboxes if several options might be selected, or dropdown menu or whatever).

Answer 9

After reading Web Form Design: Filling in the Blanks and researching about this on the web I found out that the best ones are under the input or to the right of the input.

Also the presumption that * = Required is not always right, some people don't know that. Most popular way of doing it is having explanation what * is at the top of the form. Or my favourite is getting rid of all unrequired fields and having "all fields required" or something similar at the top of the form.

Answer 10

I have not run across any studies on where the best place to put validation messages is. However, from a practical standpoint, I think user interface guidelines are close enough. Microsoft is well known to have done quite a lot of first-hand research in their usability labs for the information in their guidelines. As much as we all like to pick on Microsoft for some poor UI practices, generally those practices did not follow their User Interface Design Guidelines :)

So... Microsoft's Windows User Experience Interaction Guidelines essentially chooses an asterisk to the left of the label and a tooltip with the message:

^{download bmml source – Wireframes created with Balsamiq Mockups}

The guidelines also makes some insightful points, that I have summarized below:

• If most controls are optional, don't indicate anything (Handle missing required input with error messages. This approach reduces clutter.)
• If most controls require input, indicate optional inputs with "(optional)" after the label.
• If all controls require input place "All input required" at the top of the content area.
• Validate input early, show errors near the point of input.
• Use popup balloons for user input errors that can be detected immediately. *Balloons don't require available screen space or the dynamic layout that is required to display in-place messages.
• Display only a single balloon at a time.
• Use in-place errors for delayed error detection (e.g. after submitting a form).

Interestingly, there is not much detail in the Apple Human Interface Guidelines on this topic, but below is a summary of the relevant points that I found:

• Validate input early
• Avoid validating input after each keystroke. To frequent validation is annoying.

Again, while I realize these are not "studies on error message design best practices", I am sure research went into the formation of these guidelines and as a practical tool they are a great point of reference for this topic.

Answer 11

Marking required fields with * or marking which fields are optional with (optional) - which is best depends on the tipping point in the form.

If you have a long form - say 40 fields (to exaggerate -I'm not suggesting a form should have 40 fields on one screen) and of those 40, 36 are required then marking 36 with * is both noisy and becomes redundant.

It is far simpler to make a statement at the top that 'all fields are required except where marked optional'. Conversely a form with relatively few required fields should indicate the required ones.

In other words which ones do we need to highlight as the exceptions.

The trend toward public facing web forms is toward only asking for the required information to reduce drop off rates, hence the move toward marking optional rather than required as they all tend to be required. This is not always the case on corporate/business systems though were there are legitimate in depth forms that contain legitimate optional and required fields.

With regard to the main question of placement of error message:
It is dependent on the design layout of the form in regard to label->fields.
Assuming the label over field I would put the error message to the right of the field and provide as many visual cues as possible, such as highlighting the field border in red as well as the 'this field is required' in red.

Reasons:
1) proximal placement of error message to field
2) does not break the proximity and association of the label (which putting the error between the label and field would)
3) your error message is acting as a signpost to what needs fixing (the text indicates how). In this sense you want your signpost to be an arrow pointing to the actual thing the user needs to take action on, which is the field, not the label.
4) tooltip type messaging is not a well established convention and as someone else has pointed out runs the risk or covering over items (unlikely I an actual tooltip where the user takes an action to do this) - it is also unlikely to be good for accessibility.

My initial impression of the face style icons + highlighting + message is that its sensory overload. I'm not sure where my eye should be focussing to get the information. The field is what needs fixing in the middle but there's visual information vying for my attention before and after this, which means a lot of eye movement and effort for the user to digest the meaning (Pure hypothesis, I've never run user testing on a form set-up quite the same)

Answer 12

Unfortunately, there doesn't seem to be a "standard" way of displaying an error for a from, which was the original question.

I tried searching for a more detailed answer, but I think there isn't a definite solution because there are so many different styles of forms. Forms viewed on a desktop will generally have more space for error text than a form on a mobile device. Recently, you have to even think about what operating system you are designing for now that the Windows 8 modern style (formally Metro) has specific style guidelines for IE. Add in the fact that each modern browser has its own style for HTML5 form validation, and standardizing this becomes a mess.

The most I could find was a set of guidelines from Jakob Nielsen (http://www.useit.com/alertbox/20010624.html). These guidelines are very broad, with the only explicit rule being that you cannot only rely on color (turning the text for field red) because that can make it hard for users with disabilities to read. Color-blind users or those using screen-readers would not be able to differentiate the text.

That is the only reservation I have with the callout solution also posted here. Would users with disabilities be able to read it?

A solution could be to either adapt a style that is used by the majority of your targeted users (either Microsoft, Google, or Apple) and go with that.

Answer 13

sharing one of the approach which I designed for very Form intensive project and it was appreciated by team but because of some constraint we couldnt build it.

Interaction - the moment you move your cursor UI will show you client side instruction message to correct it before triggering submit button.

Answer 14

Alarming error messages can make users anxious. User anxiety can cause users to abandon your form. You don't have to emphasize how bad the user screwed up to get them to fix it.

Reassuring error messages will make users feel more comfortable fixing their mistakes. The goal is to call their attention and guide them to correct their mistakes, not impress upon them that they made a huge mistake.

Answer 15

I agree with others that there should be a summary. Whether it is a specific account or "Something went wrong here. Please review any highlighted entries, make the necessary changes, and resubmit the form. Thanks."

This message could be at the top, or at the bottom by the submit form, but it just has to be visible and stand out to the user, without scrolling, immediately. So, if javascript magic can keep the page down by the submit button, great. That's where the user just was, so there's less page moving/blinking.

Then, I think that the simplest convention will be the "Below the label" version, from your examples. The label is how the user will first orient, and having the error text just below it makes good sense, with an actionable place (the field), just below.

I do like the 'red box' examples, and the hover bubbles, but my favorite UI for this would be one where the fields in question are:

• Marked with error text that looks different beyond color. Italics or bold with color is better than just color. Unique color (with red as standard) is good, but we all know about color blind users, right?
• Standing out from the other fields in a way beyond the text and text color. It would be very cool if all of the "ok" fields would be grayed out a bit, so that one could see the ones that need editing stand out in sharper contrast. However, if one wanted to edit one of these "ok" fields, a click should still 'open' them for 'bright' editing.

Answer 16

I want to second what JonW said with some slight alteration. For those users on screen readers, you'll want to summarize the errors at the top of the form. Then, once you get into the form you want to notify screen readers of individual errors before the fields.

I came up against this issue at work and wanted to find a method that was both usable and accessible. I found this blog post http://www.nomensa.com/blog/2010/accessible-forms-using-the-jquery-validation-plug-in/ which helped tremendously. Being that I work in application development for a University, stuff like this is very important.

There are best practices - methods that are proven to work - but nothing beats real user testing. It's invaluable.

The example relies on jQuery and the validate plugin.

To summarize:

• Group all errors together so users with assistive technology (AT) understands what's wrong from a birds-eye perspective.
• Place individual errors above each form field so AT alerts users to the error before they complete the field.
• If at all possible, link the summarized errors to the individual fields in question, like in the example.

Finally, if you require a certain format, make sure you mention the format in the label to reduce the number of errors (and to make the lives easier for those who can't see well or at all).

Answer 17

Its always best to

1. Show inline error messages
2. And Set the focus to the First Mandate Field left empty or the field with invalid data after form submission.

In case of Real time/live data validation

1. Focusing the Field Red and showing a inline error message

In case of server side validation-for eg. where js is disabled -

1. Still show an inline error message with focus to the empty field or the field with invalid data

Usual practice -

1. Data validation should be real time (Tool tip suggesting the right format when user inputs invalid data)
2. Checking for mandate field should happen on form submission - This helps avoid too much of system intervention on user data input)

Still the traditional way of marking mandate fields with "*" is the best

Answer 18

I think google has a simple solution for the error messages on their signup form; change the border to red to highlight the field and a simple message underneath with a message in red.

This is easy when scaling a design to a small device and is clear and concise.

Answer 19

I think Facebook's way of showing error messages is most efficient and user friendly. Check the screenshot. This one is not consuming any extra space. User gets what is wrong and also to know in more detail, he can just hover on the field to know why the field is mandatory.