Form errors and warning responses based on user input
Form validation ensures the data a user has entered into a form matches the requirements of our systems. Validation allows us to cater contextual feedback and instructions to what the user is doing. Validation feedback can be presented before, during or after an interaction, depending on the need and technique used. Validation should only be used once non-blocking techniques such as providing help text, accepting multiple formats for input data and using input masking have all failed.
fieldset, and be provided a legend description
placeholderattribute, instead, use the help
textslots to provide formatting information
The best interaction a user can have with a form is to easily enter their data and to move on, never interacting with the provided validation. We can help our users avoid blocking validation by clearly identifying required form fields, using clear and informative text for labels, and providing persistent formatting instructions. The following requirements will help reduce user exposure to form blocking validation.
aria-requiredattributes to "required" form fields
Once the user has created an error and validation has been triggered, it's necessary to call out the form field(s) in error and provide instruction on how to resolve them.
aria-invalid="true"to the input
aria-describedby(widely supported) or aria-errormessage (opens new window) (not yet widely supported)
role="alert"to the notification container
<title>if the submission causes a page reload or a new page load
aria-invalidattribute on required field prior to incorrect user data or attempted submission
aria-liveannouncements while the user is actively typing
aria-liveannouncement may conflict with the screen reader's attempt to read the next element which receives focus, causing some information to be interrupted or not announced at all
aria-describedbyin conjunction with
A user's ability to complete a form may be impacted if the validation notification is not displayed in a manner the user expects.
When providing inline instruction it is important to be non-disruptive, as enabling users to think less allows them to complete a form more quickly. We can help reduce a user's cognitive lift by adding any additional information to locations within their natural reading flow, either to the right of the form element or below it. Displaying all validation in a validation summary at the top of a page or top/bottom of a form will produce a poorer user experience than providing messaging inline as the user interacts with each form element.
Cedar recommends placing validation information below the form field for a couple of reasons:
There are three unique opportunities which can be targeted to provide notification updates:
"On input" validation provides instant feedback as the user types making it highly visible. However, it forces them out of a "completion" mindset and may cause frustration.
While useful for form fields with very strict input requirements, research has proven (opens new window) it to cause (opens new window) more user errors and take longer to successfully complete the form.
Instruction offered this way should focus on positive progressive cues and should not present error instruction. It should not be used to immediately communicate that the user has caused an error.
Use instant validation:
Don't annoy the user
"On Change" validation takes place after the user changes or removes focus from their current element. In most cases this is the best time to begin validating user data as the user will not need to locate or navigate back to the form field that contains the error. This informs the user that there are additional expectations but does not block them from moving on and working through the remainder of the form.
Providing validation instruction on change, and enhancing the validation on submit can ease the users through the form without blocking or frustrating them. We could for example, alter the the appearance of an element on change, which would warn or confirm the user's input and if needed on submit reinforce this change with additional validation instruction.
A user submitting a form will be expecting to move on or to be reminded of existing errors. They may be on a location of the page where they are unable to see individual invalidated form fields. It may benefit user of longer forms to be presented with a validation summary that can reiterate the errors and guide them to the locations needing work.
OnSubmit is a user-expected location to offer validation. While less optimal than onChange, this event is preferable to OnInput. Users in a completion mindset may knowingly move through a form, even once aware of errors, and wait to submit prior to addressing additional form needs. Consider pairing OnChange progressively with onSubmit validation. A user who receives errors after submitting the form may no longer be able to see the input errors due to page scroll or some other limiting factor, in this case they may find a validation summary useful or needed.
Client side or "inline" validation notifications can interact with the user as they are working through the form process. Inline validation allows us to interact with a user prior to the data being submitted to a server.
As this provides an enhanced user experience, inline validation should be used where possible.
This validation does not replace server validation, rather it enhances it with the ability to present instruction prior to submitting or refreshing the page.
When the user submits the form their information is sent to the server and validated. If validation did not take place prior to server validation or if there are additional errors, the response of the “validator” is sent back to the user’s computer.
Server-side validation notifications:
Validation Notifications provide the instruction on how to resolve the detected errors or confirm task completion. There are multiple types of validation notification which are applicable based on the validation technique being used, such as inline feedback and validation summaries. Detailed information about the types and requirements can be found on the Validation Notifications page.