Input assistance and errors: accessibility for designers

  • Author: Access iQ ®
  • Date: 4 Mar 2015
  • Access: Premium

Quick facts

One of the most common ways that people interact with websites is through web forms.

  • Help users avoid and correct mistakes.
  • Users don't appreciate technical feedback.
  • Helping users with errors increases completed form submissions.
  • People don't perform as well with time constraints.
  • Encouragement is a good motivator.

One of the most common ways that people interact with websites is through web forms. While forms are usually the domain of the developer, the designer has responsibility in describing the interactions expected for each state of the form inputs and is vital in ensuring important accessibility considerations are accommodated at early stages of a project.

A designer has great scope to ensure that for every form a user encounters, it is clear what is expected of them and how they need to use the form to best effect. Forms utilise an entire team for a web project, since it has to be planned and designed, has content writing requirements and needs to be developed and tested to ensure the interactions, design, and writing are useful for users.

Reducing friction

A key element of the design process is knowing all states of the user's interaction, any potential hurdles, barriers, or points of misunderstanding they may encounter and to reduce friction for them in order that they may complete any inputs successfully.

Labels on form elements

One of the first things that help with forms is having a clear and obvious form label. Developers understand how to code form labels so that they are related to the form fields. Form elements are covered in more detail in the topic on forms for developers.

There are three techniques for associating form labels with form fields:

  1. Using a form label in close proximity to the field, as in Example 1 below.
  2. Labelling a form control, like a button, so that the button name functions as a label.
  3. Using the title attribute of an element when the visual design cannot accommodate a label element.

The main HTML elements to know about are:

  • input
  • label
  • fieldset
  • legend

These are described in Example 1 below. Although these are more important to developers, knowing what they are and what they are called may help a designer to visually interpret the elements.

Example 1:

A form where each input had a label for its field and a legend for the fieldset.

As described in Example 1 above, each input has a label, and when several inputs benefit from being grouped together, they are enclosed in a fieldset that is labelled with a legend. The relationship between a form field and its label is similar to the relationship between a fieldset and its legend. A fieldset is a collection of related inputs that can be grouped together, like the ones in Example 1 above or for instance, an address which is a collection of separate fields but all related to the one postal address.

Success Criterion 3.3.2 Labels or instructions is the requirement for all user input to have a label or instruction, in order that people can understand what is required from them for each input requested.

There are three techniques for labelling form fields, the best and most common is the label element. In some instances, to save space or for simple one input forms, an adjacent button can label a field, as often occurs for search forms, as in Example 2 below.

Example 2:

A search box with a button to the right with the field label.

Avoid using the form field itself to visually label the input, as this breaches the Success Criterion 3.2.1 On focus that requires the field to not change context on focus.

Consider context-sensitive help for important information

On occasion, a user may need help to understand the purpose for the information requested or help in formatting the information in the manner required.

An example of such guidance might be to inform the user to exclude the http:// section of a URL in a form field. An example of instructions might be to inform the user they will need to collect several pieces of information before starting a form. In each case, it is a requirement that the information be present.

One way to disseminate instructions and guidance to assist the input of data is to place it contextually by locating it near the field requiring input. When doing so it is important that it is delivered before the field and not after it, so that the user has an opportunity to receive the helpful information before the field that it refers to.

Another option is to place a link between the field label and the field guiding the user to more information about the question.

Contextual help on focus

A common function to see in web forms is contextual help when a form field receives focus, but is otherwise hidden from view.

Example 3:

A form displaying contextual help when a form field receives focus.

Using this feature helps satisfy Success Criterion 3.3.2 but it is important to ensure that creating it does not infringe on other success criteria. It must therefore be highlighted to developers that any helper text activated when a field receives focus must be available to people with disabilities in accordance with this criterion.

Example 4:

A form displaying contextual help when a form field receives focus.

Provide clear instructions and assistance

It is common for websites with complex form specifications to place large introductions at the top of a form. This is useful in conditions when people have to get details and documents together but is largely ignored with most other forms.

It is important that instructions are brief and useful, and delivered in reasonably small chunks:

  • Describe required fields (form fields, instructions for accessible identification/styling).
  • Describe fields with special inputs (eg date fields) and give examples.

Required form fields need to be clearly specified by:

  • Adding "required" text to the form field label.
  • Signifying in more than one mode that a field is required, perhaps with colour in addition to text.

One example would be to describe at the top of the form that some fields are required for the form to be submitted. Additionally, label clearly, and in text, which fields are required next to each field that is required.

In medicine it is said that Prevention is the best cure, which is equally true in form design. The easier it is for a user to complete a form, the more likely they have a positive view of the website and the less likely they will abandon the process. Therefore what is considered most useful for people with disabilities, which additionally benefits the population in general, is to:

  • Describe the purpose of the form clearly.
  • Provide assistance as near the respective form fields as possible.
  • Locate any error messages clearly and contextually.
  • Assist the user to overcome any errors they may encounter.

Instructions and assistance must also adhere to all the accessibility criteria the rest of the site must, for example, to:

  • Not depend on any single sensory characteristics for example, stating "required", in red text, in the label for required fields.
  • Ensure sufficient colour contrast.
  • Be machine readable, for example, by being in text and not an image.
  • Be well labelled with a clear, meaningful text label that is not repeated elsewhere on the page.
  • Be keyboard navigable by not interfering with input element focus and by using clear links, buttons and controls.

Identify, describe and assist with errors

If a field is required, label it "Required" in a manner that will be accessible as described above in the section Provide clear instructions and assistance. It is useful for the developer to be notified, through the designs, that you have chosen your method of signifying required fields to comply with Success Criterion 3.3.1 and 1.1.1 and all the other criteria for the compliance Level A, AA, or AAA, as required by the project specification.

  • The form should check for all errors at the same time and not deliver different error messages later.
  • The user should be made clearly aware an error has occurred, and the form has not been submitted.
  • The user should be made aware the scope and qualities of the errors encountered. As shown in Example 5 below.
  • All errors should be clearly identified to the user as shown in the example below.
  • The error should be clearly described, preferably in text.
  • Any error for a field that has a requirement must be clearly described, possibly with an example.
  • All data previously entered, including the error, must be retained.

Relate error messages to their fields

If an error occurs, the error should be clearly associated to the field with the error. This is outlined in Example 5 below, where the form has been submitted and the following page has been returned. There is a simple message at the top, explaining the form has not been submitted due to errors occurring. It then lists all the errors, in the same order as presented in the form. The error message contains an obvious link, taking it to the label of the corresponding field. If the field has a requirement, for example it must be a valid formatted email address, the label has a message describing that. Any other useful information that will help the user complete the form is present and available at that field.

Locate error messages contextually

For all required fields and fields that have a data type expected, it is considered best practice to validate in the browser as well as on the server and for both validation patterns to check for errors in exactly the same way. In addition, it is best to test for all conditions at once, preventing the situation where one error is fixed from the first round of validation only to encounter another error from a second validation process.

Therefore make it clear in any designs for error checking to occur concurrently, since the necessary error messages should all appear at once. The code for this, of course, is the responsibility of the developer but when the designer makes clear the location, colour, style, font, size and tone of voice of the error messages, it simplifies the tasks of completing this for both the developer and the content author.

Example 5:

A form with required fields marked in red and an explanation of the data type of each field.

Following this design pattern helps the developer understand the intention of the design and can code with minimal need for clarification or speculation, as well as assisting the content writer understand the scope for the error messages encountered in the process.

Legal and financial transactions have extra requirements

For any forms that cause legal commitments or financial transactions for the user, or affect data in data storage systems, an extra requirement exists to prevent damaging or expensive errors for people with disabilities. Success Criterion 3.3.4 Error prevention (legal, financial, data) stipulates that for any forms that fall under these conditions should provide at least one of the following conditions to prevent incorrect information being processed or important data being destroyed.

Forms with legal implications, financial consequences or user-controlled data must satisfy one of the following conditions. They must be able to be:

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

Therefore when creating a form with this sort of condition, ensure you have a stage in the process that allows at least one of these conditions to be satisfied. It is up to the designer to stipulate which process is more appropriate for each form. If a form is to update your email address to a local sports club, being able to return to the form at any time to confirm, correct or update it, being Reversible might be sufficient for that case. If presenting another credit card to be added and stored by an online merchant, Checked or Confirmed might be appropriate.

WCAG 2.0 references

Related Techniques for WCAG 2.0