Forms and Error Handling for Accessibility

In the earlier article from Accessibility best practices, We have learnt how to build an accessible form. In this article I will provide the major points to consider while handling the error validations. Don’t expect too much javascript validations methods and events, I am not a developer!!!

Error identification

The first change that happens when the form is submitted is the validation. Once the validation is done user should be intimated with a success or failure message. This message in most cases will not be exposed to assistive technologies like screen readers. This behavior will be frustrating in case of form submission failure scenarios. The user focus remains on the submit button, a message will be displayed somewhere else on the screen. Users who use screen readers will not understand if the form is submitted or not. In some cases the message will be displayed for a few seconds and disappears. By the time low vision users or users with cognitive difficulties identify and read it disappears.

In some cases the identification of the error will depend on sensory characteristics such as color, visual queues. Eg: The fields in error will be marked in red. This kind of error identification requires vision and will cause trouble for non visual users. In certain cases an error icon will be displayed to intimate fields in error. It is important to provide the error message in pure text as assistive technologies such as screen readers will not be able to read the content on images or at least an error icon having proper alternate text with error message in pure text.

Error Suggestion

Once the user is aware that the form submission is unsuccessful with appropriate error message, it is important to intimate which all fields caused the problem. The errors could be because of the following reasons in general.

  • Information that is required by the web page but omitted by the user,
  • Information that is provided by the user but that falls outside the required data format or allowed values.

In the first case user can be intimated well in advance about the mandatory fields. Read the article Mandatory fields and accessibility to understand how to do it. Sometimes even after proper intimation users may omit filling the field. In such cases providing appropriate error message that contains the suggestion to correct the field should be provided. Eg: “The email address field cannot be left blank” along with any error icons.

In the second case users may provide the information in an invalid format, or data that falls outside of the allowed range. Eg: Providing an email address without @ (at the rate) symbol, Providing the date of journey before the current date for booking a travel ticket , providing alphabets in zip/pin code text fields etc. In these case providing error message that intimates the suggestions to correct will help the users in making mistake again.

For an e-mail id field, a generic error message can be “Incorrect format”. A better suggestion could be “Provide the email in a correct format”. Date of journey could not be before the current date”, “Enter the date of journey in mm/dd/yyyy format” etc.

However content authors should be aware that the suggestions for corrections should be carefully provided if it would jeopardize the security or purpose of the content. Eg: Suggestions for a password field should be generic such as “Password should contain a special character, it could not be specific such as the password is combination of your first and last names. This allows any visitor to guess the password.

Focusing on to the field in error

There are many ways of displaying the errors.

1. On form submission all the error messages are displayed in a list on top of the form providing each error message as a link, allowing the user to jump directly to the error field from error message.

Screenshot showing group of error messages as links before the form

2. Providing error message near to the field in error. Only when the user navigates to the field with screen reader or magnifier then the error message will be observed or read aloud while visual users can find it at a glance. For screen reader users who navigate with tab key of keyboard the error message should be read along with the field, so bind the field with the error message using aria-describedby. In this case once the user hits the submit button the focus should jump on to the first field in error reading the error message for screen reader user.

Screenshot showing error messages before each field in error

In the third case the error message is popped-up as an alert. The challenge in this technique is the only one field will be validated at one instance. So the user has to correct the error field and re-submit the form until all the fields are entered correctly. Once the submit button is hit the focus should move on to the alert dialog announcing the error message. Once the user hits the ok button in the alert the focus should move to that particular field allowing the user to correct it.

Screenshot showing the error message in an alert dialog

WCAG 2.0 checkpoints effected

  • 3.3.1 Error Identification. (Future Link)
  • 3.3.3 Error Suggestion. (Future link)
  • 2.4.3 Focus Order

WCAG 2.0 Techniques