Validation feedback

Validation feedback provides important information to users during and after form submission. These notifications include:

• In-line feedback at or near the form controls
• Overall summaries that are typically provided after form submission

While error messages are the most usual and critical use for validation feedback, success messages are also important to confirm task completion.

This notification is primarily an error detection response to incorrect or incomplete data entered into a form control, such as an input, checkbox, radio or select. Its goal is to communicate immediate feedback to the user.

Its purpose is to:

• Act as instruction, once the form field or form group has been filled out by the user
• Act as confirmation that a field requiring specific formatting is valid
• Notify users of a potential problem that may require their attention
• Notify users of successful task completion

Validation notification anatomy

1. Container
2. Instruction content

Container

Best practices

• Ensure the message container can receive focus
• Include the aria-live or role=”status” markup to announce the notification without interrupting the page flow of the user
• Use meaningful colors and iconography
• Ensure the container is visually and programmatically adjacent to the element
• Display the container within the context of the action
• Ensure the instruction is visible to all users by avoiding moving the form fields up and down when displaying validation. Display instruction at the right place:
• For a singular form element, directly below the field in error, replacing the bottom helper text if present
• For a group of elements such a form group of checkboxes, below the fieldset container

Options

Validation notification containers may be hidden until the user requests them if the notification instructions are not critical.

Instruction content

Best practices

• Provide suggestions (when known) to correct the errors
• Content should be available as programmatically-discernible text
• Ensure content is meaningful. Use clear, specific, and simple language
• Be as concise as possible
• Provide the state of the error, if using visual cues for error, warning, success, or info—that text should be provided via screen reader accessible text
• Clearly state errors by saying what happened, and what the next step the user should take to succeed
• Use language to convey REI's brand
• Confirm successful submission of data
• Use meaningful colors and iconography

What to avoid

• Relying solely on references to sensory characteristics (for example, "round button" or "button to the right")
• Relying solely on visual cues to indicate an error
• Removing incorrect data entered by the user
• Providing validation messages for unfilled inputs until the users attempts to submit the form
• Using technical language
• Shaming the user for the error
• Joking with the user about the error
• Using cute language
• Using uppercase text as it gives the visual impact of shouting

Options

Validation notification content may provide instruction that changes progressively to guide the user through the error process.

Grouping controls

Form groups are a collection of elements, defined by a shared label using the legend tag. Grouping controls should dynamically inject the error instruction as a span into the form-group legend.

Best practices

We do not recommend requiring elements within a form group, since 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 using a select control. However, it is common to see these groups require the user to:

• Select one of the set of options
• Select at least one but only to 'x' amount of options

What to avoid

• Adding aria-describedby to the legend, linking to a span out of the form-group. This produces mixed results across the assisted tech matrix
• Using aria-describedby to the fieldset, linking to a span out of the form-group. This produces mixed results across the assisted tech matrix
• Adding the aria-invalid attribute to form-group controls as this may cause user confusion on if all or just one item is required

A validation summary outlines, informs, and directs users to all existing errors that need to be fixed on the page. It is meant to help users who may have lost sight of the problems needing correction and have become stuck on submit. As this may be the only error notification within a user's viewport, we recommend providing links to each specific error.

Its purpose is to:

• Provide extra error indication, summarizing pre-existing form control notifications
• Act as a summary for multiple validation problems
• Provide validation instruction returned by the server

Validation summary anatomy

1. Container
2. Instruction content

Container

Best practices

• Ensure the message container can receive focus
• Move user focus to this summary when presented
• Focus can be set to the message with client-side scripting
• Include an anchor name in the URL for server-returned summaries
• Ensure the instruction is visible to all users
• Use meaningful colors and iconography
• Use role="alert" to assertively reiterate existing page errors if the summary is presented prior to page reload
• Present the container adjacent to the form when the summary is presented prior to page reload
• Present the container at the top of the page when the summary is provided post form-submit

Options

Validation summary containers may be hidden until the user requests them if the notification instructions are not critical.

Instruction content

Best practices

• Provide suggestions (when known) to correct the errors
• Content should be available as programmatically-discernible text
• Ensure content is meaningful. Use clear, specific, and simple language
• Be as concise as possible
• Provide the state of the error, if using visual cues for error, warning, success, or info—that text should be provided via screen reader accessible text
• Clearly state errors by saying what happened, and what the next step the user should take to succeed
• Use language to convey REI's brand
• Confirm successful submission of data
• Use meaningful colors and iconography

What to avoid

• Relying solely on references to sensory characteristics (for example, "round button" or "button to the right")
• Relying solely on visual cues to indicate an error
• Removing incorrect data entered by the user
• Providing validation messages for unfilled inputs until the users attempts to submit the form
• Using technical language
• Shaming the user for the error
• Joking with the user about the error
• Using cute language
• Using uppercase text as it gives the visual impact of shouting

Options

Validation notification content may provide instruction that changes progressively to guide the user through the error process.

Grouping controls

Form groups are a collection of elements, defined by a shared label using the legend tag. Grouping controls should dynamically inject the error instruction as a span into the form-group legend.

Best practices

We do not recommend requiring elements within a form group, since 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 using 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 the user select at least one but only to 'x' amount of options

What to avoid

• Adding aria-describedby to the legend, linking to a span out of the form-group. This produces mixed results across the assisted tech matrix
• Using aria-describedby to the fieldset, linking to a span out of the form-group. This produces mixed results across the assisted tech matrix
• Adding the aria-invalid attribute to form-group controls as this may cause user confusion on if all or just one item is required

<cdr-input 
  v-model="defaultModel" 
  :background="backgroundColor" 
  label="Input label" 
  :error="modelError" 
  @blur="validateInput" 

> 

  <template #helper-text-bottom> 
    Must be 4 or less characters 
  </template> 
</cdr-input>