How to Provide Accessible Form Error Identification

Overview

This post covers the basics of providing accessible form error identification to users with disabilities. Accessible error identification in particular benefits users who are blind or visually impaired and users with cognitive impairments. Good error identification has benefits to all users. The Web Content Accessibility Guidelines (WCAG) Level A and AA provide three main success criteria (SC) for accessible error identification.

• SC 3.3.1 Error identification 
• SC 3.3.3 Error suggestions
• SC 3.3.4 Error Prevention in legal and Financial transactions

Providing clear form instructions and labels (WCAG SC 3.3.2) is also critical to prevent errors before they occur. Review this success criteria for information about providing information such as indicators of required fields or exposing the format required for a date, etc.

There are two primary ways that errors are detected:

• Dynamically as the user enters data into the form via scripting
• When the form is submitted

Error detection that occurs when the form is submitted can be detected on the client-side (by scripting in the user’s browser) or server-side. These different techniques to make error identification accessible rely on the same accessibility principles.

Error Identification on Form Submit

After the user completes a form and activates the submit button, errors may be returned. These errors are often in the form of an error message at the top of the form and/or error messages throughout the form next to each form field in error. If there is no error identification at all then the mechanism is not accessible.

When an error message is provided it must be identified in certain ways to be accessible. These include:

• identifying each field in error
• providing suggestions (when known) to correct the errors,
• properly exposing this information to assistive technology.

When an error message appears at the top of the form, it can identify all errors such as in this example:

These fields listed can be links to the field in error but are not required to be links because the fields in error are already identified. Providing links can assist users in quickly jumping to the field in error.

Another sample error message may state:

An error has occurred. Please address all fields marked with a percent sign (%)

or alternatively:

An error has occurred. Please address all fields marked with “Error”.

These approaches to identify the fields in error directly in the field and not at the top of the form meet the requirements but may not be as clear to users as they must then go and find the error. Note that error identification should not rely on color alone to communication the error.

Either way it is important to remember that some sort of error message should generally appear at the top of the form.

This is important because after a form is submitted users of screen readers may be taken back to the top of the page. Error messages that appear below forms may not be easily detected by people with disabilities including people with low vision or cognitive disabilities. When an error message does appear at the top of the form the following is recommended:

• The error message statement is indicated as a heading or ARIA region/live region. This will assist users of screen readers in quickly locating the area.
• The error message itself is focused or form field errors are also indicated inline and the first field in error is focused. To focus text such as an error message, the container will need a tabindex="-1" or tabindex="0" (allows focus to be set and places the message in the focus order) attribute and focus can be set using the JavaScript focus() method.

Alert Box Error Messages

Another method of alerting users is an alert box. This can be either through a JavaScript alert which uses a platform based modal dialog or view an simulated modal or non-modal dialog that appears on-screen to warn the user. Alerts such as this have advantages but also disadvantages. For example, modal system alert boxes get the users attention and are detected by assistive technology such as screen readers. These boxes however can be disruptive and may require the user to then locate the error after the alert is closed. Non-system alert boxes are often implemented incorrectly and users of assistive technology may have difficulty locating their content. If simulated dialogs are used, the ARIA role alertdialog can be used to create a live region that cause the alert’s text to be announced by screen readers. Check out the sufficient technique ARIA18 for more information on how to create an alert dialog.

Inline form error indication

When form errors are identified inline after form submittal it is important to associate the error message with the form field. The most common technique is to add a piece of text by each form field that indicates the type of error and suggestions for fixing the error. This text should be associated with the form field either by including it in the label element associated with form field or by using the aria-labelledby or aria-describedby properties. The best method is to use the aria-describedby attribute to associate the error message with the form field without affecting the form’s label.

Dynamic Form Validation

When a form is dynamically validated without requiring the user to submit the form there are several things to keep in mind

• Focus management should be used to lead the user to field in error
• Keyboard focus must not be trapped
• Programmatically associate the error message with the form field for users of assistive technology
• Do not rely on color alone to communicate the error
• Provide suggestions how to fix the error
• Provide an explanation to the user when the submit button is not available

Focus Management and Keyboard Focus

If the user does not correctly complete a form field, focus can be returned to the field and an error message displayed. This typically happens through a pop-up tooltip. It is very important that the user be allowed to tab or shift+tab out of the field as to not create a keyboard trap. Many screen readers users may explore the form first by tabbing around without filling out data or users with cognitive disabilities may complete form fields they easily know first before completing fields to which they need more assistance with.

Programmatic Indication of Error

When pop-up error messages are used, an ARIA role of tooltip should be applied to the message. The message should generally be associated with the form field using the aria-describedby property.

If the message appears without a focus change an ARIA live region should be used to inform the user of screen readers about the error. If the message appears when the user leaves the field and the field is focused using the JavaScript focus() method then the tooltip will be announced automatically by the screen reader because it is indicated in the aria-describedby property.

Color, suggestions, and information about unavailable controls

Like other users of error messages, color alone should not be used. Color is a great tool to assist users with and without disabilities in indicating errors — so color should continue to be used, but the text of the error message should also indicate the error. In addition, any messages indicating the error should provide a suggestions for fixing the error. For example, in our example of the e-mail address field, the user is informed that the e-mail address field cannot contain a space. This assistive users with cognitive disabilities and all users in completing the form. For example, without the suggestion, the user may have not understood what was wrong with the e-mail field — just that some nebulous error existed. This is a particularly strong business case for organization that sell products — i.e. the goal of the form is to get the customer to buy something and you want to do whatever you can to help the user complete the form correctly so the sale can be made.

Some dynamic forms will make the submit button unavailable until the form is completed correctly. This can be very confusing to users if insufficient error identification is provided. There are a few options, keep the submit button available and provide traditional error messages when the form is submitted in addition to the dynamic form validation or provide a message next to the submit button explaining to the user that the submit button is not available until all fields have been completed in accordance with the error message indicated next to each form field. In this later case it is important to make sure this message is available to users of screen readers who may be tabbing around the form to locate the submit button. Thus, it is beneficial to place this message in the focus order so the user may locate it.

Error Prevention of Legal, Financial, and Data)

In the above examples we did not focus on WCAG success criteria 3.3.4. In short it requires the one of the following be available to the user:

• The user is given a chance to review/confirm the form details before submitting
• The user is able to reverse the transaction
• Error identification and checking is provided prior to submitting the form and the user is able to correct the errors.

These additional requirements are placed on legal and financial transactions as well as user controllable data based on the significance these transactions have to the user. When the error checking option is used, this error checking appears to go beyond normal error detection that might be used in a form to actually check the data beyond simply validate data. For example, a check might involve warning the user he/she entered a valid monetary value but the value exceeds a threshold that triggers extra charges.

Testing

Remember to test your error identification mechanisms with users that have disabilities using assistive technology in different browser combinations and on different devices including mobile devices. You will find that certain properties such as the HTML required attribute may not be well supported by certain combinations such as iOS and VoiceOver. Adjust your code to provide the widest support, for example, by adding ARIA properties such as the aria-required property when necessary.

Looking to advance your team’s knowledge of web accessibility best practices? Learn more about our expert-led onsite workshops and our e-learning portal.