Input assistance, errors and required fields: accessibility for developers

  • Author: Access iQ ®
  • Date: 1 Feb 2013
  • Access: Premium

Quick facts

It must be clear to people with disabilities what fields are required, how to complete them according to your data needs, and how to respond to any errors discovered in the validation of their input.


  • Mark required fields using more than one modality
  • Identify inputs with specific requirements
  • Context sensitive help and error prevention
  • Error detection and feedback
  • Server and client-side validation

From an accessibility point of view, the most important parts of any website are the sections where the user interacts with the content.

Making plain text accessible to screen readers is not difficult when the words are plain text and there is a considered semantic structure to the webpage. Far more complex are instances where the user is required to provide information, comply with expectations on the qualities of that information, and be adequately notified of any errors that may have occurred during that information supply.

In other words, is it clear to people with disabilities what fields are required, how to complete them according to your data needs, and how to respond to any errors discovered in the validation of their input.

The processing of web forms, which is discussed in greater detail in the topic on forms for developers, is probably where improving accessibility has the greatest impact.

This topic will concentrate on the core issue for adequate accessibility in web forms: assistance provided to a person with disabilities needs to match the assistance provided to a person without disabilities.

We will discuss these three core qualities of web forms separately below.

WAI-ARIA

The Web Accessibility Initiative's Accessible Rich Internet Applications specification offers additional methods for ensuring fields are accessibly signified as required, and that errors are minimised through informative labelling that do not diminish the behaviour for people without disabilities.

More information on specific techniques is available through our WAI-ARIA article. Some of the examples below include some ARIA attributes for help. In many cases, adding ARIA properties to an element does not reduce availability to browsers that do not understand it.

Input assistance

When creating forms, it is best to consider both stages of the process that may have accessibility issues: filling in the form and processing the form. An accessible form should provide clear instructions and assistance before the form is submitted for processing and supply clear feedback for any errors detected.

Success Criterion 3.3.2 Labels or instructions states:

Labels or instructions are provided when content requires user input. (Level A)

Therefore, it is imperative that all required fields are adequately referenced. The most obvious input assistance, which benefits people of all abilities equally, is providing a label to every form field. It is not sufficient to place text near a form field; instead developers should ensure all form fields use the label element or title (when label is not possible) to describe all inputs.

Required fields

All forms should have at least one required field and it is considered safe to assume that a form with one field, like a search box, has only one required field.

However, most forms have several fields, only some of which are required. A problem occurs for people with disabilities when the method showing a required field is not accessible.

For example, a common method is to add an asterisk next to required fields, or to colour the text of required fields differently. In Example 1 below, a required field is signified with a red background.

Example 1:

An email form with required fields coloured with a red background.

This example presents several problems; the largest being that screen reader users will not know which fields are required since they cannot perceive the colour.

The use of colour to convey information in any context, including forms, is covered in Success Criterion 1.4.1: Use of colour:

Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

The intent of this Success Criterion is to ensure that there is an alternate way for people who cannot perceive colour. People affected buy this condition can be any one with a vision disability or who uses a screen reader to read websites to them. This can also include seniors, people using the site on a smartphone or tablet, and even people using the website in bright conditions.

If a user cannot understand which fields are required they might resort to filling out all fields or the fields that may not apply to them. They may submit the form without all required fields.

The time it takes for a person to fill out of a form could increase significantly if they aren't able to identify required form fields. They may resort to filling out every field in a form, or submit the form only to find they have missed filling out some required fields. Either way, this will slow them down and detracts from the user experience.

To prevent people with a disability from not clearly understanding which fields are required, there must be be a version that does not rely on sight or colour, and is available to assistive technologies like screen readers. For example, adding the word "(required)" in or after the form label will ensure that:

  • Screen reader users hear the word required when the label is read out.
  • People using Braille displays can detect that same text cue by touch, and;
  • People who are colour blind or use an alternate colour scheme can read the word and not have to rely on colour differences they may not be able to see.

There are a number of techniques to identify required fields in an accessible way:

  • Colour and text cue
  • Colour and image with appropriate alternative text

In all cases, appropriate instructions for completing the form, including information about how a user can identify a required field, should be included in text at the beginning of the form, preferably just before the form element or within a form element label or fieldset legend.

Colour and text cue

One method for identifying required fields is to use colour with a text cue such as "(required)". It is important that the text cue is included within the label element so that screen readers notice it.

Including "(required)" as part of the form label ensures that people can identify the required fields as they receive focus. At the moment they are read without relying on colour, screen reader users can listen for the text cue and people using a Braille display can detect that same text cues by touch.

Using an asterisk as a text cue to denote a required field is not recommended. As noted in Technique H92: Including a text cue for coloured form control labels, screen readers may not read out the asterisk in all reading modes. In addition, asterisks may be difficult for people with low vision to see because they are generally displayed smaller than default text size. At best, it is recommended that the asterisk is displayed very large or as an image, but since asterisks are commonly used to reduce visual elements, making asterisks larger defeat that claim.

Example 2 below demonstrates the use of colour with the text cue "(required)" to identify required fields. The instructions for completing this form indicate, "All required fields are marked with (required)."

Example 2:

<style type="text/css">

  .required {

    color: red;

  }

</style>

<label for="firstname" class="required">First name (required): </label>

<input id="firstname" type="text" size="25" value=""/>

Colour and image with appropriate alternative text

Another option for identifying required fields is to use colour and an image with appropriate alternative text using the alt attribute. Like the previous technique, it is critical that the text cue is included within the label element. If you apply this technique, a required form field "First name" could be displayed in red and an image, such as an image of a star, includes the text alternative "required". This technique ensures that assistive technologies such as screen readers and Braille displays will read out the text alternative to the user verbally or by touch to users.

Example 3 demonstrates the use of colour with an image with the alt attribute value of "Required". The instructions for completing this form indicate, "All required fields are displayed in red and marked with an icon with the alternate text Required."

Example 3:

<style type="text/css">

  .required {

    color: red;

  }

</style>

<label for="firstname" class="required">First name <img src="http://www.accessiq.org/filename.gif" alt="Required" />: </label>

<input id="firstname" type="text" size="25" value=""/>

As with any accessibility solution, it is important to test the implementation with several browsers, screen readers and preferably, people with disabilities for whom the solution is designed to help.

The WAI ARIA improvement to this form would be to add the aria-required attribute to the input field, as: <input id="firstname" type="text" aria-required=”true” size="25" value="" /> as an extra feature for screen readers that understand ARIA attributes. It is worth noting that fields with labels that already state "required" in text will not benefit from an aria label as screen readers may read "required" out twice, but if a visual method is used for labelling required fields, ARIA may help cover some screen readers.

Identifying inputs with specific requirements

Ways in which this criterion can be met include providing default field input that is formatted correctly as an example to the user, applying visible and hidden labels to fields, giving explicit text instructions with each field that requires it and preventing duplication in field names and labels.

One focuses on supporting users to avoid making mistakes by offering context-sensitive help during the submission process, while the other aims to help the user amend errors by offering suggestions before the information is finally submitted.

WCAG 2.0 Level AA conformance requires satisfying Success Criterion 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 jeopardise the security or purpose of the content. (Level AA)

Advising the user that they have made an error can therefore be improved by telling them how the error should be corrected. This is particularly relevant for people with cognitive and learning disabilities that may prevent them from understanding what others take for granted. Also, people with visual impairments may need assistance to perceive what others may find obvious from the visual presentation or context.

If a user is expected to enter data in a specific format or pattern, they should be clearly and accessibly notified both before the field and in any error messages subsequently presented if they entered the information incorrectly.

For example, if you provide default text to demonstrate the required format prior to submission and the user replaces your example with data in the wrong format, you should still respond to the error after submission with another example of the correct format.

Using intelligent scripting, and depending on the nature of the user input process, you may be able to have your system make suggestions based on the incorrect information submitted. To illustrate, if a user is required to enter the month in text format but enters the numeral "6", your system may ask the user if they meant to enter "June". This could also apply to simple and common spelling errors, e.g. suggesting "December" when the user enters "Decemeber".

Note: Your ability to do this may be limited by the programming and coding skills available to you, but also by the implications for data security and user privacy.

Context sensitive help

WCAG 2.0 Level AAA conformance requires satisfying Success Criterion 3.3.5 Help:

Context-sensitive help is available. (Level AAA)

Providing help text that displays information related to the function currently being performed gives users the opportunity to understand the requirements at each point where user input is requested. Providing text guidance for a form in general, and for each specific field is one way to satisfy this criterion.

Also, supplying links to detailed help, providing built in spell-checking, displaying examples, and JavaScript confirm(); alerts can also be employed to make forms usable and accessible. Ensure that not only the help and assistance is accessible, but also the means of reaching that help. There is no point having a heal feature if the button or link cannot be perceived by the person with a disability.

Error prevention

Success Criterion 3.3.4 Error prevention (legal, financial, data) states:

For webpages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)

  1. Reversible: Submissions are reversible.
  2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
  3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalising the submission.

It is a good general rule to provide these steps with all online processes that include the submission of financial data or incur financial or legal obligations. Let the user check the information they are submitting, let them change the information they have provided, and let them confirm that they agree to the information they have provided being submitted.

In addition, best practice suggests you should allow the user to cancel the process at any stage before submission, and to reverse the process after submission.

Note: For a website to reach Level AAA conformance, Success Criterion 3.3.6 Error prevention (all) requires that these user options be made available when a user is submitting any kind of information, regardless of the legal and financial implications.

Preventing serious consequences

Some errors have larger consequences than others. While it may be annoying to have to correct several form fields, the implications are larger when errors can lead to serious financial or legal implications.

A simple example might be a user putting in a wrong date of birth because they entered it in MM-DD-YYYY format when DD-MM-YYYY was required, an error that could prevent the user from qualifying for a benefit to which they are entitled.

While this is an issue for all users, it is fair to say that people with some kinds of disabilities — including visual impairments, motor difficulties and cognitive limitations — are more susceptible to these kinds of errors while the consequences of getting an online form wrong or failing to complete it properly may be more severe.

The key to addressing this critical issue is to make appropriate and adequate information available to the user about how to complete a form correctly, and then also providing a means by which the user can review and correct their input before final submission.

Error detection and feedback

If a user makes an error while submitting information via on online form, they are typically advised what and where the error is, for example by reloading the page with the field requiring attention marked with a red border. This method is not accessible as it depends on colour to convey meaning, which fail Success Criterion 1.4.1 Use of colour.

Additionally, Success Criterion 3.3.1 Error identification states:

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)

There should always be error notification messages in text. You may continue to provide error message in other ways, so long as there is a text version that can receive focus to be useful for people with disabilities.

For example, an online form has 15 fields and the user makes an input error on the 14th field. On submit the system detects an error and returns the user to the form with the 14th field marked with a red border and bold text with a friendly "Whoops, please fix this error" message next to the field requiring attention.

A sighted user will likely scan the whole page and quickly spot the problem field and correct the input. However, a screen reader would reload and re-read the entire page to the user, who won’t know there is an error until they come to the 14th field. The person with a disability has not been given a similar experience to the person without a disability.

One solution to this situation would be to load the page with a list of the errors at the top of the content area, each linking to an error requiring attention using the field id as the anchor. The error message should refer to the field label and describe why the information was not accepted.

An email form with a list of the errors at the top of the content area and required fields left blank coloured with a red background.

For very short forms this type of linked error identification may not be necessary, but would still be helpful if it is following the same error messaging procedures on other areas of the site, in order to present a consistent experience to users.

For a long form, however, it makes sense to use text at the top of the page to let a user know an error has been detected. While this should be enough to tell any user that there is an input error, it would clearly be helpful to tell the user where the error is, and provide a way for the user to go straight to the error in order to correct it.

Including WAI-ARIA

The aria-invalid state can be delivered as a result of processing a form to supplement error messages delivered back to the browser. Setting the aria-invalid attribute to true for a given field during client-side processing helps reduce errors delivered to the server.

Server and client-side validation

This is covered by WCAG 2.0 in an advisory technique that suggests using either server-side validation to check and reload the form with appropriate text instructions and a link to the error, or client-side error checking to load a new window or a new page with text details of errors and links to the errors on the original form.