Validation notifications provide important feedback to users during and after form submission.
These notifications include in-line feedback at or near the form controls and overall summaries that are typically provided after form submission.
While error messages are the most usual and critical use for validation notifications, success messages are also important to confirm task completion.
This notification is an error detection response to incorrect or incomplete data entered into a form control, such as an input, checkbox, radio, or select.
Notifying the user of a form control's validation status can manifest in many ways, from adding iconography to signify success, altering the color of border text or background, and/or providing detailed instruction.
Regardless of the means they all have the goal of communicating information back to the user. To ensure this happens effectively the following requirements and best practices should be accounted for.
As instruction, once the form field or form group has been filled out by the user
As confirmation that a field requiring specific formatting is valid
In order to notify users of a potential problem that may require their attention
In an associated section of the effected required form field
Form groups are a collection of elements, defined by a shared label using the legend tag.
It is not recommended to require elements with a form group as logically there should be no incorrect answer for these elements.
They are either true or false. When designing a form where a user must make a selection consider a select control.
However, it is common to see these groups have the following needs:
Require the user to select one of the set of options
Require that the user select at least one but only to 'x' amount of options
As of now there seems to be no way to link one message to a group of controls with a form group that will communicate clearly to all users.
We need to do some extra work with these groups to make sure they work for all our users.
Tennon.Io's article on this topic(opens new window) found that the best solution for support
on a broad range of assisted tech solutions was achieved by dynamically injecting the error text into the legend. This forgoes the recommendation to add the aria-describedby attribute to the fieldset or legend.
Additionally the addition of aria-invalid to each control was not recommended as it may lead to user confusion.
Dynamically inject the error instruction as a span into the form-group legend
Add aria-describedby to the legend, linking to a span out of the form-group. This produces mixed results across the assisted tech matrix.
Use aria-describedby to the fieldset, linking to a span out of the form-group. This produces mixed results across the assisted tech matrix.
Add the aria-invalid attribute to form-group controls as this may cause user confusion on if all or just one item are required
Up to this point we have been going over best practices and requirements for individual form controls and form groups such as a singular text input or group of checkboxes.
This type of inline validation works well as users are provided feedback immediately.
However, for various reasons a user may lose sight of the problems needing remediation and become stuck on submit.
A validation summary outlines, informs and directs users to all existing errors that need to be fixed on the page.
The summary should be an additive error indication, summarizing pre-existing form control notifications.
As this may be the only error notification within a user's viewport, providing links to each specific error is recommended.
To provide additional visibility to validation notifications
Use aria-live(opens new window) to indicate that an element will be updated. It describes the types of updates the user agents, assistive technologies, and user can expect from the live region.
Use aria-atomic(opens new window) to indicate whether assistive technologies will present all, or only parts of the changed region based on the change notifications defined by the aria-relevant attribute.