What is best practice for designing form error messages?

  • 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.

    As far as location: no studies, but from personal preference at least, the "_Above the label_" and "_Below the label_" examples don't work for me (either the message or the label gets too separated from the field). The "_Below the input_" is OK, providing it doesn't get confused with any input field below it. My preference, if space permits, would be "_To the right of the input_".

  • 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

    One of the problems with this approach, however, is that it obscures the input.

    how so? The input is clearly visible, and the flag should disappear upon 'focus'

    I like the look of the tooltip error, but I think there may be multiple problems with it. If the error disappears on focus, before the field is proven valid, that can be a usability problem as well as the user may want to reference the error while they are typing. I'm not sure, but I suspect there might be some problems with mobile display too, depending on how its implemented. Also, ignoring the live validation for a moment, how would you display errors if you only had server-side validation?

    Anything the user would need to reference while typing should not be in the error flag, it should just be part of the page. Otherwise, how are they supposed to get it right the first time?

    As far as mobile, I have actually used the flag option on mobile devices before and have not had any issues or complaints, but who knows, this is just what has worked for me in the past.

    As for server-side validation, I would do it with an ajax submit, and use the server response to activate the needed changes to the dom, but that is more of a stackoverflow question than a ux one. Either way, a full page refresh for form validation is not a great experience compared to ajax.

    Agreed on the reference point, but I'm writing a custom plugin for public use, so I can't guarantee that the error won't contain vital information and would like to use best practices by default. Ajax and live validation is definitely a better user experience, but my comment on server-side validation was mainly meant for use cases where JavaScript is disabled. Ideally, the fallback server-side errors would be styled the same way. Do you have any comparison or conversion rate data for your method versus other methods?

    Sorry, I don't have any studies. Its just the only method I've found so far has handled all the edge cases consistently, and with no complaints. Personally I don't support 'noscript' cases, as its less than 1% of marketshare, but if you want to support it, it should be possible to style the page the same way for those users. As for guarantees of reference points, you could just note the best practice wherever you distribute the code; if people abuse the code to ill effect there is not much you can do about that anyway.

    +1 Thanks for all the follow-up. I'm leaving the question open because I'd like to find some other options and studies, but I appreciate your answer.

    Oh for sure. All good.

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

    How about the implementation of the proposed method, anyone got links for js/css libraries ?

    @RenanMalkeStigliani that is more a question for stackoverflow; but I have no idea. I write all my own js and css.

    I like the idea of tooltips but how could this be best addressed on mobile?

    "These fields do not match, and must be a valid email address." - This is a confusing message. It technically doesn't make sense if you read it, but the more serious problem is that it's trying to stuff two error messages (email invalid, and fields not matching) into one short message.

    @Brandin I disagree. As a user I would be annoyed to make them match, then find out the email address is malformed, or vice versa. Though i don't have anything more rigorous to offer than that.

    @Fresheyeball Yes then we agree. The two things are separate. 1. Whether the email address is valid or not, and 2. Whether they match. If one of the email addresses is not valid, fix that first. Finally, if both email addresses are valid, then check if they match and deal with that problem if applicable. OR make it clearer in the message, e.g. "The email addresses do not match. Additionally, blahblah is not a valid email address."

  • 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.

    enter image description here

    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.

    These forms are wildly nicer than pressing submit and getting pissed off.

    Very nice approach. But not always possible consider a money transfer form in an internet bank web site. The user enters an amount, which is valid in the format we show him an smile but logically the number is not correct as he does not have the amount in his account or lots of other business rules. The case may be more complicated if the transfer form is a three step form and you can not check the amount until user pass all form steps. The user then claims that he got an smile for amount in first step but then the system says that the amount for transfer is not valid.

    @AlirezaFattahi do you know *Ajax* ?

    @Aperçu this is not a problem which can be solved by Ajax. Please consider that the form is multi-step

    I dislike forms that are too eager to flag errors. Sometimes I may need a second to think what about value to fill. Or I may need to refer to something else (like a Google doc). Pointing out errors too quickly is rigid, and implies that the user must bend to the software, not the other way around. One of the advantages of software over, say, a human asking you a series of questions, is flexibility. Let's not lose that.

    Good point about the hints, although the question was about error messages positions. Love the idea of Submit button still working and take the user to the first error +1. Two points to notice: One is that the form could look very crowded with all the indicators and hints (I would use as small as possible indicators and maybe they disappear in case of success after moving to next field? Second, maybe shorter error messages? (oh, it looks like there r...sorry for the... we need more to....) all that is a lot to read, and it does increase the completion time. Hence affect the completion rate :)

  • 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

    Interesting idea on the linked error summary at the top of the form, I don't think I've seen that before. I think it might lose some effectiveness on longer forms, though. Being as I've never seen it in the wild, it might cause some confusion too.

    Regarding your placement of the error directly after the label, are there any data or studies that show that this might be the preferred method? Also, great points on accessibility.

    @VirtuosiMedia The error isn't directly after the label, it's *part* of the label. (At least in the markup). The label itself needs to update to make screenreaders aware that the field is in error. I'll update my answer to highlight this point. As for studies, no I don't have any I'm afraid. I've taken accessibility best-practices as the main starting point for this form example. It can be enhanced with script certainly, but I'd be concerned that some studies may find a form that does something totally differently gets really good test results but from a totally in-accessible form.

    +1 for the link @JonW! My organization requires that we list all errors somewhere together, so it's not uncommon, @VirtuosiMedia. Here's two other sites that recommend putting a list of all errors at top: Smashing Magazine Form-Field Validation and Adam Kalsey Simplified Form Errors

  • 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.

    Interesting information, but let's keep in mind that it's at least 6 years old. Habits change and people adapt to changes in workflow pretty quickly once it becomes common.

    I agree there is a lot of outdated stuff. Here's a good description on how to handle error in forms and the physiology behind it [http://uxmovement.com/forms/how-to-make-your-form-error-messages-more-reassuring]How to Make Your Form Error Messages More Reassuring

  • 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.

    Interesting idea. Has this been implemented anywhere? Do users respond well to this? I'd love to see this in action to see if it is a good option to go with. It might depend on how many fields there are in the form though - a mortgage application form would just be full of tags everywhere, but smaller forms may be more suitable.

    @JonW: I haven't seen this idea implemented anywhere. When I saw the question, I thought how I will solve it and I came up with the above mentioned solution. I would be happy to discuss it further if you are interested.

    One advantage of this idea is that the user can never hit submit and not see the error because it has scrolled off the screen, something that a lot of the highly voted answers seem not to account for.

  • 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

    enter image description here

    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.

    new idea, just not sure how confusing it could be to users seeing the original label gone and replaced with red error message.

  • 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).

  • 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.

  • 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.

    +1 for the links. Just a little confused, your text says "to the left of the label", but your example mockup doesn't show that. Which way did you mean?

    Thanks for the feedback. I meant that the Windows User Experience Interaction Guidelines recommends an asterisk to the left of the label. I have updated the text to further clarify. Let me know if something is still unclear.

  • 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.

    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)

    Hi Glen. I think you're focusing on the wrong part of the question - OP is asking about the *positioning* of the messages, not about what the message should be or about whether it is Required or Optional. The question would still be the same if OP asked where the 'This field is Optional' message is to be located.

    my comment was specifically in response to this: _"Still the traditional way of marking mandate fields with "*" is the best"_

    Ah, so you're responding to another answer, not leaving an answer to the actual question? I'm afraid that's not really how this site works - we can't do threaded comments - that's more for forums. Answers should explicitly answer the main question. Once you receive 50 rep points then you can leave comments against posts, but really it's Questions and Answers that should get the focus, not comments.

    edited and updated accordingly. Had to rush to airport hence didn't post full answer earlier.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM