- Common form issue #1: Not providing a required field indicator as part of a field's label.
- Common form issue #2: Not including explicit labels for each form input.
- Common form issue #3: Not programatically associating fields with labels.
- Common form issue #4: Not testing forms with a keyboard to make sure all functionality is clear.
- Common form issue #5: Form validation that is not accessible.
It is important to provide a required field indicator as part of a field's label. For example, a common way required fields are indicated is to include an asterisk as part of the label. For example,
Most screen readers will read this label as "First name star". Historically, asterisks have been used as required field indicators for so long that users of assistive devices have learned that "star" means "required." Another option is to include the word "required":
First name (required):
A third option is for a developer to include the asterisk as an image, and provide an alt attribute for the image that is required:
<label for="firstName">First name<img src="img/asterisk.gif" alt="Required field" /></label>
This will appear to a sighted user like the first option above, but the screen reader will read the alternate text ("Required field") instead of saying "star". It's slightly more usable than the first approach. Of course there are many ways of achieving this goal. The main rule is that when you test with an assistive device, the fact that a field is required should be stated.
A common approach that is not accessible is to make a statement at the top of a form that all fields are required. The problem with this approach is that the statement is generally marked up within a paragraph tag in the html. Content marked up as a paragraph will be bypassed by individuals tabbing through the site with their keyboard, so the text will never be read by a screen reader. Only links and form fields can have keyboard focus and be read by the screen reader.
This causes the irritating scenario in which an individual may leave certain form fields blank, thinking they are not required, but then will be unable to submit the form without understanding why. Often designers prefer to design forms this way because they prefer the aesthetic of form fields without asterisks. I encourage designers to err on the side of a form being usable, because that is what a form is for. It is there to be filled out, so whatever can make it easier to be filled out is what we should do.
Always include a label
The case for search bars
<span class="screen-reader-text">Search for:</span>
<input type="search" class="search-field" placeholder="Search …" value="" >
- Wrap the label around the field:
<input type="search" class="search-field" placeholder="Search …" value="">
- Programmatically associate the label with the field using the "for" and "id" attributes:
<label for="search-bar">Search for:</label
<input type="search" class="search-field" placeholder="Search …" value="" id="search-bar">
Once a form has been developed, try using it with your keyboard. First try simply tabbing through the form with your keyboard, and ensure that all of the following criteria are met.
- You can see where the keyboard focus is on the form. There should be some kind of an outline around the field that is in focus to show you visually where you are. If your cursor gets lost, there is a problem.
- You can tab through the form fields in an expected order. Focus should not jump randomly between the fields, and nothing should be skipped. For example, in a login form, the user should be able to tab through the username field, password field, forgot password link, and submit button. This seems obvious but many times the forgot password link is mistakenly placed outside of the flow of the form. The next figure shows the expected order for a user to tab through fields in an example form:
- The cursor should never get trapped within a field. For example, if you will not let someone leave a form field until the format of the data passes a validation rule, that is not accessible. Let the user leave the field then return to it later if they need to.
- Visible tooltips should also be read by the screen reader. This goes for any information on the form, including formatting information for a field. An easy way to do this is to include the formatting information within the field's label so that it will automatically be read by a screen reader. See an example of an accessible tooltip in my accessible form demo
- Fill out the form with intentional mistakes. When you try to submit the form, does the keyboard focus move to the first field with an error? Does an error message appear?
Then try the same exercise but without looking at the form. Use only your keyboard and a screen reader. See if the flow of the form makes sense, and the labels are descriptive enough, when you're not looking at them. Again intentionally fill out the form with mistakes. Does your keyboard focus go to the first field with an issue on form submit, and is the error message read out by the screen reader? Read on for more details on how to make sure form validation is accessible.
Form validation paradigms
There are two main paradigms for form validation, and one of them is more accessible than the other.
- Traditional form validation on submit: In this scenario, a user can tab through form fields, filling them out, then hit the submit button at the end. At that point, the form will be validated, and error messages will appear on any fields that have issues. The user can try to submit the form at any time because the submit button is always enabled:
User can attempt to submit the form at any time:
This method of form validation is more accessible, because the user can receive instant feedback on any potential issues once they try to submit the form. When developed correctly, the first issue on the form will receive keyboard focus when the form is submitted.
- Modern form validation on tab out: In this scenario, each form field is validated as the user leaves the field. Typically a visually highlighted error message will appear next to the field that has the issue. The submit button is not available (it is disabled) until all form fields are free of errors.
Some experiences disable the submit button until all fields are free of error:
This method of form validation is not accessible because once a user tabs out of field, they may not realize that they filled out the field incorrectly. A sighted user will see the error messaging, but a non-sighted user will not. Even worse, when the submit button is disabled, it cannot receive keyboard focus at all. The user will continue to tab and will never hear the word "submit".To use this strategy, it is more accessible to not actually disable the submit button. If absolutely necessary, the button can appear disabled through style properties, but a keyboard user should still be able to access it (it should still be able to receive focus).
Making error messages accessible
To ensure that non-sighted people using a screen reader can hear error messaging, it is important to programmatically append error messages to the field's label on form submit. Here is how it should work:
- User fills out form fields and tries to submit form.
- The form is validated programmatically, and there are some issues that need to be resolved before the form is submitted.
- Any field that has an associated error should have a descriptive error message appended to that field's label.
- Focus should then be placed on the top-most field in the form.
Here's how this will feel to a user:
- User fills out form, assumes everything is correct, and tries to submit the form. In reality, they have missed one of the fields (in this case, "First name").
- Focus is also placed on that field's label. By default, when a field has focus, a screen reader will read the label. The label will now be: "First name star, you must enter your first name." See how the error message is now read along with the label?
- Then they must tab through the rest of the form to get back to the submit button again. If there are any other fields with problems, error messages for those fields will also be read out with the field's label, so the user will be made aware.
- See this in practice on my accessible form demo.
Thanks for reading, and for caring about form accessibility. Leave a note in the comments if you have other ideas for making forms accessible.