Validation rules are run when data is provided to the system to check that it conforms. This guide focuses on validating data which is inputted manually by users via fields.
Validation can be invoked by one of two actions, either when the user:
Dirties a field - , i.e. when they enter some content and then move away from the field - check thison the fly, as they as entering content into a field. This is the primary validation method.
Selects “Save”
...
. Fields which cannot be validated when they are dirtied should instead be validated on the “Save” action.
When a field contains invalid data it is in an “error state”.
The data should not be saved
An error or warning message should be displayed beneath the fieldInvalid data should not be saved
The user should be able to move freely around the form or page and not be locked to the field
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. Fields in this state can still be saved and are not considered to be invalid.
Feedback message
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 message
Messages should always start with the field label and be short.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}”.Insert example.
...
Invalid format
When the input format is wrong, the a field contains invalid content, it should be made clear to the user what the problem is and how they can fix it. The message should always start with the field label and be short. The error message should follow the format:
...
Fields expecting an email address check for the format name@domain. The error message should read:
“{field label} must be an a valid email address”
Fields expecting a URL check that http or https is included. The error message should read:
...
Each validation message should be displayed underneath the relevant field. If the message takes up the full width of the field it should then wrap onto another row.
When a field in an error or warning state:
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
A field may instead be in a warning state. In this case the warning styles would be applied.
Validation on save
When validation is run on save a user “save” action and errors are found, some guidelines, additional to those described above, must be applied:
All invalid fields should be highlighted.displayed in the error state
Focus should move to the first invalid field
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”
...