Forms & error handling

Many websites and web apps have forms where users can login, register, order products, or leave comments. These forms often provide error handling.

A form with error handling in action

The following simple contact form shows how error handling works - in his case, when the user submits the form. The screen reader NVDA is turned on to show what non-visual users experience.

Video description

A screen reader user tabs to a simple contact form on the site nomensa.com.

  • On focussing the field Your full Name, the programmatically associated label is read, followed by information that the information is required.
  • The user supplies his name.
  • The user tabs to the email field and enters his email address.
  • The user skips the field Your telephone number and moves on to the Enquiry textarea.
  • The user writes a short message and his phone number into the field Your enquiry.
  • He submits the form.
  • An error message is displayed at the top of the form, with a link to the field that is missing an entry.
  • The user follows the link, and focus is set to the Telephone number field.
  • The user now enters the number in the right field.

Typical forms & error handling usability problems

There are various issues with forms for users with disabilities.

Low vision users have a harder time to locate forms and once they have found them, work out their meaning when the labels are truncated or have bad contrast.

A common problem for screen reader users is that the label is not announced when they focus a field. Error handling can be particularly difficult for blind users when it is not clear that errors have occured or where they have occured. On many sites, error messages or hints are only shown visually, leaving the blind user guessing and searching for 'what went wrong'.

Form also often cause cognitive problems. When labels are not easy to understand, users struggle. There are many cases where websites use technical jargon in labels, or fail to provide hints or helpful input examples. In other cases, the site does not specify the expected input format.

As in most human activities, errors occur when users fill out forms. This is why good error handling is so important. Here are some examples of errors:

  • The user misses one or more fields where information is required
  • The user does not want to provide information in some fields and leaves them intentionally blank
  • The user misspells input in a field that is checked (such as an invalid email address, or a password repeat field where the input does not match the input in the password field)
  • The user provides input in a format not accepted by the form (for example for a field Date of birth, the user types 27.10.1995 and not 27/10/1995)

1 Low vision use: Search form not found because of unusual placement

In this example, a magnification user is looking for the search field in the top right corner, and misidentifies something else as search until he zooms further in and realizes his error.

Video description

A low vision user tries to locate the search form on the haw-hamburg.de web site on his mobile phone.

  • He opens the home page.
  • He uses the browser's pinch zoom and pans to the top right corner.
  • He identifies some text (Selfservice) which he thinks is the search field.
  • He zooms in further, using the phone's zoom function in addition to verify his guess.
  • He realizes that this is not the search field.
  • He expresses his opinion that search should always be in a standard location (top right).

2 Low vision use: Difficulty of identifying a search form due to bad labelling

In this example, a magnification user is tries to identify a search field. The field is only labelled by a low-contrast, truncated placeholder text.

Video description

A low vision user tries to identify the search form on the haw-hamburg.de web site on his mobile phone.

  • He seaches across the page for something resembling a search input field.
  • He comes across a Quicklinks dropdown menu, then he guesses that the field to the left might be the search field.
  • He zooms in, complaining about the bad contrast of the placeholder text.
  • He spells out the not meaningful – and in addition truncated – placeholder text, "Benutzerde"
  • He activates the field to get final confirmation that it is indeed a search field.
  • The placeholder text is repaced by a blinking text insertion cursor.
  • The user is now confident that he has found the search field.

3 Low vision use: Form field placeholder text without sufficient contrast

Often, the placeholder text of form fields has insufficient contrast. On mobile phone layouts, this is often the only way the fields are labelled.

Video description

A low vision user tries to read the labels of a search form in the yellow pages section of München.de on her mobile phone.

  • She opens the yellow pages section.
  • She recognizes something that looks like input fields, but cannot read the text due to insufficient contrast.
  • She uses the iPhone zoom magnification to zoom further into the page.
  • She now manages to read the labels.

4 Cognition: Obscure or technical labelling of form elements

In this example, a form for reporting technical failures of traffic lights has labelling in a technical jargon that the user cannot understand.

Video description

A screen reader user tries to report a traffic light failure on the site hhva.de, and struggles to identify the right error category.

  • Arrowing down, the user reaches the heading of the fault report section, which is broken in two by a line break element.
  • Three radio button labels for the error categories to choose are read on receiving focus, one after the other.
  • The user can't make sense of the categories – she expresses that she is not sure where to report the failure.

Note: For the substance of the problem here, it does not matter if the user is  a screenreader user or not, although the penalty of making a wrong choice is much higher for her (it took a long time to find the right section on this page).

5 Screen reader use: Visual hints without screen reader output

In this example, the password field shows a hint that a user password must have at least 8 letters and must contain a number or a special character. This information is not available to blind users.

Video-Beschreibung

  • A blind user fills in the PayPal registration form and focuses the password field.
  • A hint about password requirements is shown, but not spoken by the screen reader.

Accessibility tips for forms and error handling

  • Make sure all form inputs have a descriptive and clear label or name. Show the expected format next to the input where this makes sense (such as DD.MM.YYYY for  a date input).
  • Place the label close above or to the left of the input (right for checkboxes and radio buttons).
  • Ensure that labels are programmatically linked to inputs - for example, by using the label element referencing the input labelled via the for attribute.
  • Do not use placeholder text as the only label of a text field. The placehoder attribute disappears when the user writes into the field. If you have to save space, use accessible floading labels (see the Resources section).
  • Use fieldset with legend to provide context to labelled fields where necessary - e.g., to distinguish billing and shipping address, or provide context to groups of radio buttons which are not clear based on the labels alone.
  • Use the HTML type attribute on fields where users supply certain typed information, like phone number, email address or password.
  • Do not rely on HTML5 automatic error handling via the required attribute - these error messages are generic and disappear after a short time.
  • Do not rely on colour alone to indicate inputs with an error (for example, by just rendering the label text red).
  • Ensure good contrast of error message text. Use colour or additional icons to make error messages stand out.
  • If you generate error messages close to the inputs, ensure they are programmatically linked to the input (update the label element or link messages via aria-describedby) so they are spoken by screen-readers when the input is focused.
  • If you display error messages after submission, set the focus to the first field with an error if you have no separate list of errors at the beginning of the form.
  • If you present a list of errors after submitting the form, insert it before the form, set the focus to the beginning of the list, and link each error message to the input that needs correction.

New accessibility requirements for forms in WCAG 2.1

In the latest version of the Web Content Accessibility Guidelines, WCAG 2.1, there are two new requirements that particularly affect forms.

Purpose of controls

The new Success Criterion 1.3.5 Identify Input Purpose requires that the purpose of input fields that gather information about the user (such as name, address, telephone number etc.) communicate their purpose programmatically. The idea behind this is that assisitve technologies can then support users better. For example, they could show an image representing the purpose of a field in addition to the text label. An example is the image of a telephone for a telephone number input field. Visual cues are important for people with certain cognitive disabilities.

Currently, the best way to identify input purpose is using the HTML5 autocomplete attribute. The Understanding text for 1.3.5 Identify Input Purpose provides more details. Techniques for this new Success Criterion are under development.

Status messages

Sometimes, page content can change dynamically when users interact with forms. The page then often shows visual status messages. An example is "Thank you, the form has been submitted".

Another example happens when users filter search results by adding search terms or ticking options. A visual status message then often tells users how many search entries were found based on the filters set. The new Success Criterion 4.1.3 Status Messages requires that these visual messages must also be programmatically determinable so that non-visual users will notice the change. This can be done by using the aria-live attribute on the status message. The Understanding Text for 4.1.3 Status Messages provides more details.

Resources for forms and error handling