Poorly communicated errors can be frustrating for users. Apply the following guidelines when handling errors:
Write error messages in clear and simple language. User should be able to understand the problem while reading an error message.
Include suggestions on how to resolve the error.
Avoid technical jargon.
Don’t use negative words and never blame the user.
Use a general error message to communicate that something went wrong but also ensure specific messages are used inline and placed where the error took place.
Try to prevent errors from occurring in the first place. For example; if a date in the future is required, disable the ability to select a date in the past. If errors do occur let the user know right away. Make sure it’s clear what the error is, and where it occurred. If possible, implement inline validation with real-time feedback right after the answered question. This will increase success rates and satisfaction, and decrease errors made and completion time.
Symbolic colours (such as red for error) and icons are often used to help signify meaning to a user for error messages, warnings and success messages. Never rely solely on colours or icons, they should be used along with supporting text so that the information is accessible for all users.
Please provide a valid email address.
Do: Use specific messages where the error took place
Please provide a valid email address.
Don't: Rely solely on colours and/or icons to communicate errors
How it works
We currently recommend using custom validation styles, as native browser default validation messages are not consistently exposed to assistive technologies in all browsers (most notably, Chrome on desktop and mobile).
Here’s how form validation works with Bootstrap:
HTML form validation is applied via CSS’s two pseudo-classes, :invalid and :valid. It applies to <input>, <select>, and <textarea> elements.
Bootstrap scopes the :invalid and :valid styles to parent .was-validated class, usually applied to the <form>. Otherwise, any required field without a value shows up as invalid on page load. This way, you may choose when to activate them (typically after form submission is attempted).
To reset the appearance of the form (for instance, in the case of dynamic form submissions using AJAX), remove the .was-validated class from the <form> again after submission.
As a fallback, .is-invalid and .is-valid classes may be used instead of the pseudo-classes for server side validation. They do not require a .was-validated parent class.
Feedback messages may utilize the browser defaults (different for each browser, and unstylable via CSS) or our custom feedback styles with additional HTML and CSS.
With that in mind, consider the following demos for our custom form validation styles, optional server side classes, and browser defaults.
Custom feedback styles apply custom colours, borders, focus styles, and background icons to better communicate feedback. Background icons for <select>s are only available with .custom-select, and not .form-control.
We recommend using client-side validation, but in case you require server-side validation, you can indicate invalid and valid form fields with .is-invalid and .is-valid. Note that .invalid-feedback is also supported with these classes.
Validation styles are available for the following included form controls and components:
<input>s and <textarea>s with .form-control (including up to one .form-control in input groups)
<select>s with .custom-select
.custom-checkboxs and .custom-radios
Validation states can be customized via Sass with the $form-validation-states map. Located in our _variables.scss file, this Sass map is looped over to generate the default valid/invalid validation states. Included is a nested map for customizing each state’s colour and icon. While no other states are supported by browsers, those using custom styles can easily add more complex form feedback.
Please note that we do not recommend customizing these values without also modifying the form-validation-state mixin.