Techniques for WCAG 2.0

On this page:

-

# G139: Creating a mechanism that allows users to jump to errors

## Applicability

Content that accepts user data input, with restrictions on the format, value, and/or type of the input.

This technique relates to:

- Success Criterion 3.3.1 (Error Identification)
  - How to Meet 3.3.1 (Error Identification)
  - Understanding Success Criterion 3.3.1 (Error Identification)
- Success Criterion 3.3.3 (Error Suggestion)
  - How to Meet 3.3.3 (Error Suggestion)
  - Understanding Success Criterion 3.3.3 (Error Suggestion)

## Description

The objective of this technique is to help users find input errors where the information supplied by the user is not accepted. This includes fields with missing required information and fields with incorrect information. When users enter data input that is checked, and input errors are detected, a link to that error is provided so that the user does not have to search for it. One approach is to use server-side validation, and to re-display the form (including any previously entered data), and a text description at the top of the page that indicates the fact that there was an input error, describes the nature of the problem, and provides a link the field(s) with a problem.

## Examples

### Example 1: Server-side error checking

The user inputs invalid data on a form field and submits the form. The server returns the form, with the user's data still present, and indicates clearly in text at the top of the page that there were not accepted. The text describes the nature of the error(s) and provides a link to the field that had the problem so the user can easily navigate to it to fix the problem.

### Example 2: Client-side error checking with a popup

The user inputs invalid data on a form field and attempts to submit the form. Client-side scripting detects the error, cancels the submit, and modifies the document to provide a text message describing the error, with links to the field(s) with the error. The script also modifies the labels of the fields with the problems to highlight them.

### Example 3: Client-side error checking with no popup

When the user submits a form, instead of taking them to a new page, a script automatically sets focus to a text link that says "Errors have occurred." The link goes to the first item in an ordered list of descriptive error messages." Each list item is a link to the control where the error had occurred. And there is a link from the error back to the ordered list of descriptive error messages. The process is repeated as needed.

## Related Techniques

- G83: Providing text descriptions to identify required fields that were not completed
- G85: Providing a text description when user input falls outside the required format or values
- SCR18: Providing client-side validation and alert

## Tests

### Procedure

1. Fill out a form, deliberately leaving a required (mandatory) field blank, and make an input error on another field and submit the form.

2. Check that a text message is provided that identifies the field that is missing required data.

3. Check that a text message is provided that identifies the field with the input error.

4. Check that there is a link to each field that has is missing required data from the missing data message

5. Check that there is a link to the list of errors from the error message.

Note: Success Criterion 3.3.2 requires that if an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user.

### Expected Results

- If #2 is true, then #4 is true.

- If #3 is true, then #5 is true.

- Top
- Contents
- Intro
- Previous: Technique G138
- Next: Technique G140