Errors

An error is the result of an unexpected condition. An error message explains what happened and what is needed to correct the error.
See also: Errors vs similar patterns

Also known as: Error Handling, Warning, Alert

Example

See the Pen Error Message by SHC-FED (@SHC-FED) on CodePen.0

Design Specs

Desktop/Tablet/Mobile

  1. The notification/message container has a background color of #fae7ea and a stroke color of #d01833. Stroke styling is a solid 1px stroke with a 3px border radius.
  2. Text within the message container is Open Sans Semi Bold. Text color is #d01833. Text should be left justified. There is 15px of padding around the text within the box.
    • For Desktop, the font size is 15px.
    • For Mobile, the font size is 14px.
  3. Within a form and upon error, the field level highlight changes to have a 2px stroke of #d01833. The field-level helper text is Open Sans Regular Italic and text color is #d01833.
    • For Desktop, the font size is 13px.
    • For Mobile, the font size is 12px.


Note: Design specs are for reference only. Developers should implement patterns using the Enterprise Framework whenever possible - see the Example section on this page.

Production Examples

  • Sears
  • Kmart

The Error pattern consists of 3 elements:

  1. Field-level highlight: 2 parts of the element in error change color to red; the stroke around the element and the label text. The word "required" does not change color.
  2. Field-level Helper Text: Add text per element in error to help the user resolve the failure.
  3. Notification/Message Container: contains error notification and summary. Include names of offending fields. Links are optional.

Mobile

Desktop/Tablet

The Error pattern consists of 3 elements:

  1. Field-level highlight: 2 parts of the element in error change color to red; the stroke around the element and the label text. The word "required" does not change color.
  2. Field-level Helper Text: Add text per element in error to help the user resolve the failure.
  3. Notification/Message Container: contains error notification and summary. Include names of offending fields. Links are optional.

Mobile

Desktop/Tablet

When Do I Use This?

Errors should be triggered and error messages displayed when:

  • A required fields is empty
  • An incorrect or invalid valued was submitted
See also: Errors vs similar patterns

Usage Guidelines

1. Single Error

Set focus behavior: no set focus behavior is necessary if the field-level error is within view and would be sufficient to call attention to the error.

With no entry

With no entry, check box.

With entry.

2. Multiple Errors

If multiple errors occur in a group OR if elements need to be addressed as a combined group (ex city/state/zip combination isn't valid) -- a summary notification is shown along with field-level messaging. Set focus on the notification container.

Form error with no entry

Form error with incorrect, invalid, or not allowed entry

3. Copywriting for Error Messages

The error messages’ job is to guide a user to a successful conversion / completion. Remember that users may already be in crisis mode and may be or become easily frustrated when an error is triggered.

The right tone is friendly and helpful, and not cute which if not used correctly can come off as flippant. Employ brevity, always using as few words as possible without sacrificing clarity. Think about what matters to the user – what do they need to know? Be deliberately clear. Say what went wrong (sometimes it is better to be generic than specific about our back end issues) and offer any next steps they can take to make the process go more smoothly.
Copywriting examples and more detail

4. Prevent errors with good design

  • Reduce quantity of fields, disable or hide selections rather than display an error on submission
  • Label all fields as required or optional to avoid confusion.
  • Be forgiving of inputs (see forms page) OR provide clear input requirements such as text examples or a description of a valid value.

5. Use effective messaging, interaction and visual design

  • Error identification: state what has occurred and what is wrong
  • Error suggestion: provide suggestions on how to correct when known
  • Set focus: Make sure an error message is placed in the user's current focus area. Example: an offending field / message outside of the current viewport needs focus set to ensure visibility.
  • Proximity: If the error area is not proximal to a user's current focus area, consider a supplemental notification; Example: if the CTA is to the right and the error is small and far to the left.
  • Use same page errors and not browser dialogs or page turns
  • Retain as much of the original entry as possible. A returning (2nd time) error message should work the same way

ADA Compliance

Errors should be prevented as much as possible. Errors are especially difficuly for disabled persons to manage; this includes reducing the number of fields.
W3C compliance requirements:

  • Error identification - identify an error has occurred and what is wrong
  • Error suggestion - provide suggestions to correct (when known)
  • ...in a way that can be exposed to assistive tech (generally text)
    Must work in both cases;
  • empty/omitted required field
  • incorrect/invalid/not allowed entry
  • ...in a way that can be exposed to assistive tech (generally text)
Source: W3C Guideline 3.3

Best practices:
A top of page/form error message is best for accessibility, because it is read first by screen readers.
  • Content of message: summary of error(s) w/ names of offending fields (links optional) to make finding the error location accessible
  • Must set focus appropriately on the message container and tabindex-1,0 as it will often not be the absolute top OR set focus on first error field and state error in inline text
Field level error message:
  • Ensures complete understanding, low cognitive load due to proximity
  • Helper text necessary in all cases due to colorblind (using red color only is not enough)
Additional Guidelines:
  • provide text examples of, or describe valid/correct entry
  • retain original entry, unless security concern
  • changing field label text is an option (i.e. using unique identifier like an asterisk, or adding "error:" to the label)
  • insert error message as part of label element in html source for screen readers, or use ARIA tags
  • best practice: ""error"" in page title element
Coding approaches:
  • option 1 - all users are presented with accessible solutions in HTML. philosophically: accessibility is better for everyone
  • option 2 - ARIA tags (i.e. when the above isn't possible)
  • How we validate is important -- solutions will vary; the above is all based on "on submit" validation approach.
Sources & Useful links:

Rationale

The solution was heavily researched, including an SHC audit, accessibility best practices and relationship with Forms standards
Specifics:

  • The color red is the industry convention, and is commonly associated with errors in the physical world
  • The use of a Notification Container and its styling helps visibility in context of a page. Our styling roughly follows Bootstrap styling and aligns to similar items our UI design system. All color contrast ratios are ADA compliant.
  • Top of form error message is best for accessibility, is read first by screen readers.
  • Field level error message ensures complete understanding, low cognitive load due to proximity.
  • This is perfect case where accessibility guidelines truly benefit everyone.

Research

Gift Registry Redesign

Proximity finding: "Error messages appear far to the right of the error’s location, making it more difficult to map the message to the error" - see page 16

view full study

Error Message Guidelines

"...Good error messages are polite, precise, and constructive... Make error messages clearly visible, reduce the work required to fix the problem, and educate users along the way."

view article

Google Material Design: Errors Pattern

Google's design guidelines for errors

view article

Designing Interfaces: Patterns

Textbook recommends Same-Page Error Messages over browser dialogs (problem: poor sync w/ the error location, cognitive load) or page turns where a user addresses only the offending elements. Note: content not accessible at this link.

view article

Checkout Redesign LIVE - Bug Bash November 2014

Input Formatting / error prevention findings:
Name field: auto correct entry if two spaces are placed between first & last name OR consider clearer error message
CC field: Consider auto formating cc number section to be chunked into 4 blocks of 4 numbers to help prevent errors.

Error messaging finding:
Zip error didn't explain source of problem or what steps can be taken to resolve

view full study

Post a New Comment

Your feedback will help us improve this page. If you have a comment about the content of this page, use the form below, and the Patterns Team will get back to you within a business day.

For general questions or assistance, email the Patterns Team directly.