Ontario.ca homepage
Français

Ontario Design System

Our npm namespace has changed. Developers should update their projects to continue accessing our components.

Live validation

Use live validation to flag input errors on difficult web form questions.

  • Content: 
    @use '@ongov/ontario-design-system-global-styles/dist/styles/scss/1-variables/global.variables' as globalVariables;
@use '@ongov/ontario-design-system-global-styles/dist/styles/scss/1-variables/spacing.variables' as spacing;
@use '@ongov/ontario-design-system-global-styles/dist/styles/scss/1-variables/colours.variables' as colours;

.ontario-error-messaging__content {
	margin-left: spacing.$spacing-2;
	max-width: globalVariables.$standard-width;
}

.ontario-input__error {
	border-color: colours.$ontario-colour-dark-red !important; // overrides default border color on .ontario-input class
}

.ontario-checkboxes__single-option .ontario-checkboxes__error {
	.ontario-checkboxes__label:before {
		border-color: colours.$ontario-colour-dark-red;
	}
}

.ontario-error__hidden {
	display: none !important; // hides the error container
}
  • URL: /components/raw/live-validation/live-validation.scss
  • Filesystem Path: fractal/components/patterns/live-validation/live-validation.scss
  • Size: 838 Bytes
  • Content: 
    .ontario-error-messaging__content{margin-left:.5rem;max-width:48rem}.ontario-input__error{border-color:#d81a21 !important}.ontario-checkboxes__single-option .ontario-checkboxes__error .ontario-checkboxes__label:before{border-color:#d81a21}.ontario-error__hidden{display:none !important}
  • URL: /components/raw/live-validation/live-validation.css
  • Filesystem Path: fractal/components/patterns/live-validation/live-validation.css
  • Size: 286 Bytes

Guiding principle: Help the user be successful the first time.

About this pattern

Live validation happens when the user focus leaves a web form element and they have not submitted the form yet.

You might use live validation for:

  • username or password generation fields
  • strict formatted fields (for example, postal codes, driver’s license numbers, credit card numbers)
  • complicated fields that users struggle with (based on testing)

When to use this pattern

Start with our standard error messaging guidance and consider enhancing it with live validation.

Live validation requires advanced logic, so only use it if your research shows that it solves more problems for users than it causes.

Before you use live validation, consider these approaches first:

General guidelines

  • Validate your fields after the user has entered data and moves focus to the next field (on blur). Avoid prematurely validating the fields if the user is just tabbing or clicking through without entering any data.
  • If a user input triggers your defined error criteria, indicate an error has occurred by providing an inline error message above the field and updating the field to its red error state.
  • When the user returns to correct their input, re-validate the field once the user has completed the field and moves focus out of the field (on blur):
    • keep the error message if the same error still exists
    • update the error message if a different error has occurred
    • remove the inline error and restore input fields to their default state when the error criteria is satisfied

These are general guidelines and may not work for all form elements.

Best practices

Do

  • Match your live validation error messages to your server-side error messages.
  • Remove error messages for correct fields (it is not necessary to show positive validation).
  • Combine multiple error criteria into one sentence (for example, “PIN must only contain numbers and must be at least 6 characters”).
  • Use server-side validation once the user submits the form.

Don’t

  • Add an error summary when using live validation.
  • Validate when the user passes through (clicks or tabs) empty fields before any data is entered.
  • Use live validation on form elements that don’t require user text input (such as radios, dropdowns and checkboxes).
  • Use live validation on keystroke as this can cause unwanted behaviors with assistive devices

Optional fields

Avoid including optional fields in your form design. Only ask users for information needed to provide a service.

If you need to include an optional field and it has strict formatting (such as postal code, phone number, etc.), then make sure to:

  • provide live validation when the field has been filled out by the user
  • allow it to be submitted empty

Validation on only some elements

Use clearly definable sections (or pages) on forms where you use live validation on some form elements, but not all.

This helps to avoid the confusion of some form elements not displaying any live validation.

Accessibility

  • Ensure keyboard focus is not trapped. The user should be able to navigate out of the element using their keyboard.
  • When an input is invalid, apply the aria-invalid attribute to it. Remove the attribute once the input is valid.
  • Programmatically associate the error message with the form field for users of assistive technology and update using the aria-live property.
    • Using the value “assertive” emphasizes the importance of the message and causes screen readers to interrupt their current tasks to read this message aloud.
    • The message is then read aloud before the next element is announced to the user.

If you have any questions or feedback, please get in touch.