User Notifications

Status: This is an in-progress, unapproved draft.

Provide feedback to users on the results of their form submission, whether successful or not. This includes in-line feedback at or near the form controls, and overall feedback that is typically provided after form submission.

Notifications need to be concise and clear. In particular, error messages should be easy to understand and should provide simple instructions on how they can be resolved. Success messages are also important to confirm task completion.

Overall feedback

When a form is submitted, it is important that the user is notified whether the submission was successful or if errors occurred. Several of the following techniques can be combined.

Using the main heading

A common way to provide feedback is by using the main heading of the web page, usually the most prominently displayed <h1> or <h2> element. This technique is particularly useful when forms are processed by the server, but can also be useful for client-side scripting.

Code snippet: Error
<h1>3 Errors – Billing Address</h1>
Code snippet: Success
<h1>Thank you for submitting your order.</h1>

Note: The main purpose of the main heading is still to identify the web page that the user is currently on. When the user is sent back to the same web page because of an error, then a simple indication using the word “error” and possibly the number of errors is helpful.

Using the page title

It is often useful to also use the <title> element of the web page to indicate successes and errors. In particular screen reader users will receive this feedback immediately when the web page is loaded. This can be helpful when the main heading is located deeper within the content, for example, after the navigation menus.

Code snippet: Error
<title>3 Errors – Billing Address</title>
Code snippet: Success
<title>Thank you for submitting your order.</title>

Using pop-up dialogs

When the web page is not reloaded or when the content does not change after submission, using pop-up dialogs may be useful to notify users of the effect of their action. For example, “save” or “send” functions might not change the content of the web page, but the user still needs to be notified about the status. Sometimes simple clues, such as disabling the “save” button, might be sufficient. In other situations more prominent messaging may be necessary. For example, messages indicating that the system is busy “loading”, “saving”, or carrying out another function.

A modal pop-up requires the user to confirm the message in order to continue using the web page. This approach is useful because it cannot be missed, but it can also be quite obtrusive and disruptive to the task.

The example below shows a pop-up that is displayed when the user activates the “save” button. A message is displayed in a dialog box, and the web page is disabled until the user selects “OK”.

Example:
Code snippet: HTML
<button type="button" id="alertconfirm">Save</button>
Code snippet: JavaScript
document.getElementById('alertconfirm')
  .addEventListener('click', function() {
    alert('Thanks for submitting the form!');
  });

Note: In this example the alert() function uses the standard web browser dialogs, including default settings for font-size, colors, and language. After confirming the message in the dialog window, most web browsers will resume the focus back on the “save” button. This functionality would need to be matched for custom dialog windows.

Temporary pop-up

A temporary pop-up is displayed for a certain period of time before vanishing. This approach is less obtrusive but it can also be missed. In particular, users generally cannot control how long the message is displayed and may not have enough time to read it.

The example below shows a pop-up that is displayed when the user activates the “save” button. A message is displayed prominently in the center of the screen, and does not block the user from continuing to use the content.

Example:
Code snippet: HTML
<button type="button" id="temporarymessage">Save</button>
Code snippet: CSS
#popup {
  
  transition: opacity 2.5s linear;
}

Note 1: In the code for this pop-up, the displayed message is coded using a <div> element that has an aria-live attribute with the value assertive. The contents of this so called “live region” is conveyed to screen readers and other assistive technology. The value “assertive” emphasizes the importance of the message and causes screen readers to interrupt their current task to read aloud this message.

Note 2: The elements used for the pop-up window are dynamically added to the web page when the button is activated, and later removed when the fading animation is completed. This is to reduce the amount of unnecessary elements on the web page, for example when the web page is displayed using custom styling.

Listing errors

When errors occur, it is helpful to list them at the top of the page, before the form. The list should have a distinctive heading, so that it is easy to identify. Each error listed should:

  • Reference the label of the corresponding form control, to help the user recognize the control;
  • Provide a concise description of the error in a way that is easy to understand by everyone;
  • Provide an indication of how to correct mistakes, and remind users of any format requirements;
  • Include an in-page link to the corresponding form control to make access easier for the users.
Example:
Code snippet:
<h4>There are 2 errors in this form</h4>
<ul>
  <li>
    <a href="#firstname">
      The First name field is empty, it is a required field and must be filled in.
    </a>
  </li>
  <li>
    <a href="#birthdate">
      The Date field is in the wrong format, it should be similar to 17/09/2013 (use a / to separate day, month, and year).
    </a>
  </li>
</ul>

In-line feedback

In addition to overall feedback, more specific feedback at or near the form controls can better help users to use your form. This includes feedback to indicate correctly entered input as well as errors in the input.

Typically a combination of messages and visual cues are used to provide in-line feedback. For example, valid input can be indicated by a checkmark (✓) and green border, while errors can be indicated by an error icon (like a red ✗ or an exclamation mark) and red border. Error messages should also provide guidance on how to correct mistakes. The concepts for such error messages are essentially the same as for providing instructions.

After submit

The example below shows a form with two input fields. The first input field, “username”, is used to register a username. The second input field, “expiry date”, is used to provide a date for when the registration expires.

When the form is submitted, the entries are checked and feedback is provided to the user. Appropriate success and error messages are displayed for each input field to help the user complete the form.

Example:
Use the format MM/YYYY.
Code snippet: HTML
<div class="success">
  <label for="username">
    <strong>OK:</strong> Username:
  </label>
  <input type="text" name="username"
    id="username" value="spaceteddy13"
    aria-describedby="userDesc">
  <span id="userDesc"></span>
</div>
<div class="error">
  <label for="expire">
    <strong>Error:</strong>
    Expiry date:
  </label>
  <input type="text" name="expire"
    id="expire" value="03.2015"
    aria-describedby="expDesc">
    <span id="expDesc">Use the format MM/YYYY.</span>
</div>
<div>
  <button type="submit">Submit</button>
</div>
Code snippet: CSS
.error   { color: #900; }
.success { color: #090; }
.error   input { border: 3px solid #900; }
.success input { border: 3px solid #090; }

During typing

Instant feedback during typing can be extremely helpful. For example, checking the availability of a username in the previous example required the user to resubmit the form – possibly multiple times. Providing feedback while users are typing allows them to experiment more easily until they find a suitable username. However, client-side scripting is required for such functionality, and not all situations may be suitable for such feedback.

Binary messages

In the following example, the availability of a username is checked instantly while the user is typing text in the input field. Corresponding success and error messages are displayed without the user needing to submit the form.

Example:
Code snippet: HTML
<div>
  <label for="username">Username:</label>
  <input type="text" name="username" id="username">
  <span id="username_feedback" aria-live="polite"></span>
</div>
Code snippet: JavaScript
document.getElementById('username').addEventListener('keyup', function(){
  function setError(el, msg) {
    el.parentNode.querySelector('strong').innerHTML = "Error:";
    el.parentNode.className='error';
    el.parentNode.querySelector('span').innerHTML = msg;
  }
  function setSuccess(el) {
    el.parentNode.querySelector('strong').innerHTML = "OK:";
    el.parentNode.className='success';
    el.parentNode.querySelector('span').innerHTML = "&check;";
  }
  var val = this.value;
  if (val !== "") {
    if (taken_usernames.indexOf(val.trim())+1) {
      setError(this, '&cross; Sorry, this username is taken.');
    } else {
      setSuccess(this, '&check; You can use this username.');
    }
  } else {
    document.getElementById('username_feedback').innerHTML = '';
    document.getElementById('username_feedback')
      .parentNode.className = '';
    document.querySelector('[for="username"] strong').innerHTML = '';
  }
});

Note: The displayed message in this example is coded using a <span> element that has an aria-live attribute with the value polite. The contents of this so called “live region” is conveyed to screen readers and other assistive technology. The value “polite” de-emphasizes the importance of the message and does not cause screen readers to interrupt their current tasks to read aloud this message. Thus the message is only read once when the user stops typing rather than on every keystroke that the user makes.

Scaled feedback

The example below illustrates a range of possible types of feedback in addition to success and error messages. In the example, the strength of the password is checked as it is typed by the user. The feedback indicates a scale of how strong the password is. The feedback is indicated using several cues, including color coding, a barometer, and label “Weak”, “Okay”, and “Strong”, as well as the time that would be needed to crack the password.

Example:

See commented example code in full.

On focus change

In some cases it does not make sense to check input as it is being typed by the user, because it would display error messages most of the time. This is often the case when data needs to be entered in a particular format, such as a date.

In the example below, the user is expected to provide an expiry date. The input is checked when the user leaves the form field. That is, when the focus is removed from the form field and the “blur” event is triggered for the element, for example, when the tab key is used to move to the focus to the submit button.

Example:
Code snippet:
<div>
  <label for="expire"><strong></strong> Expiry date:</label>
  <input type="text" name="expire" id="expire" value="03.2015" aria-describedby="expDesc3">
  <span id="expDesc3" aria-live="assertive"></span>
</div>

Note: The displayed message in this example is coded using a <span> element that has an aria-live attribute with the value assertive. The contents of this so called “live region” is conveyed to screen readers and other assistive technology. The value “assertive” emphasizes the importance of the message and causes screen readers to interrupt their current tasks to read aloud this message. Thus the message is read aloud before the next element that received the focus is announced to the user.

Success Criteria:

  • 3.3.1 Error Identifications: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)

  • 3.3.3 Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)

Techniques: