Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Validation rules are run when data is provided to the system, to check that it the data conforms. This guide focuses on validating data which is inputted manually by users via fields.

...

  • The data should not be saved

  • An error message should be displayed beneath the field

  • The user should be able to move freely around the form or page and not be locked to the field

  • Any save options should be inactive, unless validation for the field can only be run on “save”

  • If the user leaves the form or page they should see the standard “Unsaved changes” warning [link to be added]

Note that a field can instead be in a warning state, rather than an error state. Fields in this a warning state can still be saved and are not considered to be invalid.

...

When a field contains invalid content, it should be made clear to the user what the problem is and how they can fix it.

Messages Error messages should always include the name of the field to support accessibility guidelines.

Messages should be informative yet short. We should avoid using words such as “please”. [add more stop words?]

Empty mandatory field

When a mandatory field is empty the error message should state: “Enter a/an/the {field label}”.

...

When a field contains invalid content , it should be made clear to the user what the problem is and how they can fix it. The the error message should always start with the field label and be informative but kept short. The error message should follow the format:

...

When a field’s content does not conform to any data restriction rules in place, the error message should follow the same format as described. For example, “Latitude must be a number between -90 and 90”

...

  • The field background color should change to the standard error background color

  • Field label text and feedback text be displayed in the standard error foreground color [to be reviewed]

A field may instead be in a warning state. In this case the warning styles would be applied.

...

  1. All invalid fields should be displayed in the error state

  2. Focus should move to the first invalid field

  3. An “error” toast should be displayed, letting the user know their submission contains errors and has not been saved. The toast should display:

    • A heading “Error”

    • The text “The {name/entity} was not saved. Some of the data provided is invalid. Please correct any errors and retry” [using a general message here as the specifics are displayed in context]

...