More Tips for Creating Accessible Forms

Following on from a blog post written about rules for creating accessible forms, I am going to be providing more tips to help you make your forms more accessible.  In this post I will be covering a few more common issues that I have come across when evaluating forms for accessibility conformance and providing techniques for improving their overall accessibility. The aspects I will be focusing specifically on:

1. Answer options;
2. Error messages.

Answer Options

Quite often, a form will have a question followed by a number of radio buttons or checkboxes representing answer options as shown in the screenshot below, taken from MoneySuperMarket.com when applying for a car insurance quote.

Figure 1: Multiple questions with ‘Yes’ or ‘No’ answer options on MoneySuperMarket.com

To a sighted user, the relationship between the question and the answer options is clear. However, it may not be clear to someone who cannot see the page and so therefore uses assistive technology such as a screen reader to navigate the web. Depending on how the user navigates the page, a screen reader may not always announce the question, and will only read out answer options. This is because there is no programmatic relationship between the question and the answer options. If there is no relationship in the HTML, then the screen reader cannot convey it to the user. So how can we create this relationship? We can’t use a label for the question, like with text form fields, as we cannot associate a label with multiple inputs. Our recommended approach to this situation is to use the fieldset and legend elements to group the question with the answer options, as shown below:

This means that, when the users focus is on the answer option, the question (“Do you like ice cream?”) is read out before the label and the status of the radio button (“checked” or “not checked”).

Error Messages

Another area of forms that is often not implemented correctly or completely is error messaging. Sometimes it is not made clear which form fields are required, and sometimes no error messages are provided and when you click on the ‘Submit’ button, the page simply reloads, giving no indication as to why the form didn’t submit.

Required Fields

It is important to let users know which fields are required and which ones are not. If the form is submitted with an empty or invalid required field and the user does not understand why, they can become confused and frustrated when trying to complete the form. There are numerous approaches for marking up required fields, however, generally required fields should be indicated with either text or a symbol positioned inside the label element:

Required fields are indicated with *

Surname *

This will help to ensure that the required field is highlighted to the screen reader user when the question is read out. Alternatively, text (e.g.: “required”) can be hidden off-screen and replaced by a visible icon or asterisk. If an icon alone is used to identify required fields, its relevance should be stated at the top of the form as shown in the example above. Required fields can be enhanced with the use of the ‘aria-required’ attribute on the input field, as shown below:

  Surname * 

This ensures that the screen reader will convey the fact that the field is required to the user. Alternatively, you could include the HTML5 ‘required’ attribute:

  Surname * 

Instructions

Providing instructions for form fields can help users to complete forms without errors, especially if a particular text format or set of values is required, such as a date or email address. When providing instructions for individual fields, it is important to associate the instruction text with the related form field. One of the ways this can be achieved is by using the ‘aria-describedby’ attribute on the input element, for which the value is the ID of the element containing the instruction text. For example:

  Email (Required)  Please enter your email address, e.g. name@domain.com

Providing Helpful Error Messages

When a form is submitted with errors, it is important to tell the user why the form failed and identify the specific fields which caused the form to fail. Many forms that I have come across simply reload the page without any error messages, or provide a simple “There are errors in this form” message, which is not particularly useful. Error messages should clearly inform the user as to what the error was and preferably give advice on how to fix it. If a form is submitted with empty fields which are mandatory, the error messages should identify fields that were not completed. Form fields that returned an error because they require a specific format, such as a date, should explain why the format given was incorrect and provide an example of valid formats. Additionally, error messages should be positioned above the field they relate to in the HTML of the page, to ensure that screen readers inform the user of the error before they reach the corresponding form field. If the error message is below the form field in the HTML, it would be announced after the form field, and so may cause confusion as to which question the error message relates to: the question before or the question after? Below is an example of how error messages can be marked up accessibly:

   First name Please enter your first name    

Figure 2: Good – Error messages for the Microsoft Live login page are positioned above the input field they relate to.

The Microsoft live login page provides error messages that are positioned correctly, and also an example of what format the email address should be in, making it a good example of an accessible error message.

Figure 3: Bad – Error messages on Facebook are only displayed one at a time and are not positioned above the input field they relate to in the HTML.

The Facebook account creation form provides only one error message at a time, which is only displayed when the user is focusing on that input field. If I click away from the form, I will not be able to see any error messages at all.

Conclusion

So to summarise:

• Use fieldsets and legends to group question and answers for related input fields;
• Indicate required fields using text or an icon;
• Provide instructions to help users to complete your form without errors;
• Provide error messages that are informative and will help users correct their mistakes.

Using the techniques outlined above will help you on your way to making your forms accessible and therefore help everyone, not just those with physical or cognitive impairments, to use your forms. Please read “Three rules for creating accessible forms” for more information about why it is important to keep your forms accessible, the consequences of not keeping your forms accessible, and for more tips on how to do this.