https://designnotes.blog.gov.uk/2013/11/14/exploring-validation-messages/

Exploring validation messages

CBTC_error_message

This is a recent pattern we’ve started using on GOV.UK Mainstream for error messages when the user hasn’t entered their details correctly, or at all.

Errors are first grouped at the top of the page in a summary and then markers are placed next to the incorrectly completed fields.

12 comments

  1. Pete

    Should the errors listed at the top be anchor links to specific errors? Could be good. Could be tough with drop downs etc...

    Link to this comment Reply
  2. Amy Whitney

    Hi Pete,

    sorry I should have stated they are anchor links to specific errors. In research users scrolled rather than clicking the links, but it is good accessibility with screen readers. We added tabindex="-1" to the div, and use .focus() to move keyboard focus to the div as it opens. This will cause screen readers to announce the heading text, and will also put both screen reader users and keyboard only users in the right place on the page to access the error information.

    The anchor links take the user to the div rather than the field as you say this could be tough with drop downs.

    Link to this comment Reply
  3. joelanman

    Screenshot of register to vote validation.

    looks nice, couple of points:

    If you're validating with JavaScript, I think it makes more sense to put the message near the continue button.

    On Register to Vote, we've been able to keep each step relatively small, and one advantage of that is it makes validation messages very easy to connect to the fields. In your example, it might be hard for people to connect a less obvious error (such as in my image, above) with the field, as when you scroll to the field, the message is not on the screen.

    In the past I've used the icon/bubble approach, so a user can click on the [ ! ] next to a field to read the error message.

    Link to this comment Reply
    • Amy Whitney

      We aren't validating with Javascript.

      I really like the fact that the error messages are next to the continue button, I think it works really well when you can keep the sections small.

      In the example of child benefit tax calculator all of the steps are one page because the questions are connected to each other. Having the validation messages at the top means that users scroll (or use the anchor links) to navigate to the errors and then down to the calculate button.

      Link to this comment Reply
  4. chrisheathcote

    For HMRC, we're looking at putting the error reasons grouped at the top, and also the reason by the question, as some of the validation we do isn't pure data entry errors, but logical errors (answers in different questions contradict, don't add up, etc.).

    Link to this comment Reply
  5. timpaul

    Something we've been trying on another exemplar is combining the error message with the field label. So, instead of 'First name' followed by an error - 'Please enter first name', we just colour the label red and add the word 'missing', so 'First name missing' (this is in addition to summarising the errors at the top of the page).

    It's more compact and your able to easily generate error text based on the type of error. It's also untested as of yet ;-).

    I'd have posted images to illustrate but we're not able to. Can we sort that?

    Link to this comment Reply
  6. Luke L

    Is there a reason the error messages are not displayed in the same order as the actual fields themselves?

    Link to this comment Reply
  7. nhau thai cuu

    If you're validating with JavaScript, I think it makes more sense to put the message near the continue button.

    Link to this comment Reply
    • Amy Whitney

      Hi nhau thai cuu,

      We aren't validating with Javascript. In the example of child benefit tax calculator all of the steps are one page because the questions are connected to each other. Having the validation messages at the top means that users scroll (or uses the anchor links) to navigate to the errors and then down to the calculate button.

      On Register to vote they are able to keep the steps really small, so the validation messages are easily connected to the field and the button.

      We will continue to explore both patterns and iterate based on our findings.

      Link to this comment Reply
  8. catfood

    do you have any specifications or opinions regarding the semantics of your error messages?

    Repeat the context of the errors location in the message:

    "Enter the date child benefit started"

    or keep it generic:

    "This field must not be left blank"

    I imagine option A requires more developer, copy and maintenance resources whilst option B can be rolled out pretty quickly but comes with obvious accessibility issues and would only work if it appeared alongside the field containing the error.

    Any research or validation you've done in this regard would be appreciated.

    tx
    cf

    Link to this comment Reply
    • Ed Horsford

      Hi Cf,

      We recommend validation messages be specific and as helpful as possible. The first message is clearer for users, and works better if there's more than one error on the page.

      It follows our fourth design principle: 'Do the hard work to make it simple'.

      Our design patterns for validation have moved on a bit since this blog post - you can see our current guidance for this pattern here:
      http://govuk-elements.herokuapp.com/errors/

      Ed

      Link to this comment Reply

Leave a comment