Forms - Checkpoint (n)
The law states:
"When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues."
Forms must be created with accessibility and usability in mind, there are a number of factors that contribute to the accessibility and usability of forms, including layout, labeling and grouping. Different form elements need different kinds of markup to be accessible.
Form layout and element markup
All important information for forms, such as form instructions, must be presented before the form itself. The submit button must be the last form element contained within a form.
Screen readers and other adaptive technology access forms and other HTML content in a linear order. Once a screen reader encounters a submit button, the user generally expects that the form should be submitted. In cases where optional fields, such as radio buttons for changing search criteria, are presented after the submit button, the screen-reader user may not be aware that the options even exist, or will discover them after-the-fact.
Similarly, instructions for a form must be presented before the form. This includes statements about how required fields are denoted or information that the person should be aware of before submitting the form.
A best practice is to group common form elements using the fieldset tag.
Labels for Text Entry Fields
label tag to associate a meaningful text label with every text entry field. The text label is read by screen reader technology thus announcing the meaning of the text entry field that follows it. The text label description should be written in a way to help users understand the type of information they should input into each field. There are two methods for associating text labels with text entry fields.
One way is to have the
input tag encapsulated within the
label tag. This method will put the text label right next to the text entry field.
HTML Code: <label>First Name: <input type="text" /> </label>
If you need to have the text label and text entry field separate, use the
for and the
id attributes to connect the items together. The
id attribute of the input tag gives the form element an identification. The
for attribute of the
label tag connects the text label to the specific identification that was setup in the
input tag. You might need to do this when you are using tables for layout to put the label and text field in different columns or rows.
<label for="lname1">Last Name:</label>
<input name="lastname" id="lname1" type="text" />
<label for="fname1">First Name:</label>
<input name="firstname" id="fname1" type="text" />
Labels for Radio Boxes and Check Boxes
Radio buttons and check boxes work in the same way as text areas do. You can either have the
input tag inside the
label tag or use the
for and the
id attributes. Both methods produce the same look. Radio buttons and check boxes should have the input first then the label.
<input type="radio" value="male" id="male">
<input type="radio" value="female" id="female">
<label><input type="radio" value="male" id="male">Male</label>
<label><input type="radio" value="female" id="female">Female</label>
Field Set and Legend Tags
Group together multiple form elements that are of related information using the
fieldset tag, and label it with the
legend tag. For example, group radio buttons or check boxes in the same category. Visually, this makes more sense to viewers, but also, when a screen reader goes through a form grouped with the
legend tags, it will read the legend followed by the form element within the grouping. The form below will be read as: Personal Information, First Name, Personal Information, Last Name, Hobbies, Sports, Music, Video Games, Reading.
<legend>Personal Information</legend><br />
<label for="fname">First Name:</label>
<input type="text" name="first name" id="fname"><br />
<label for="lname">Last Name:</label>
<input type="text" name="last name" id="lname">
<input id="sports" type="checkbox" value="checkbox">
<label for="sports">Sports</label><br />
<input id="music" type="checkbox" value="checkbox">
<input id="video games" type ="checkbox" value="checkbox">
<label for="video games">Video Games</label>
<input id="reading" type="checkbox" value="checkbox">
Select Lists (Drop Down Menus)
- Keep select lists to minimum of one.
- Beware of using multiple selects. They are difficult for keyboard-only users and they obscure selections that have already been made. Instead, use check boxes for multiple select items.
- Limit the amount of text for each option
- Use of the <optgroup> tag - helps structure a list, but is not read by screenreaders
<label for="tshirtsize">Your T-shirt size</label>
<option value="xlarge" selected="selected">Extra Large</option>
Jump menus (select lists which activate as soon as the user selects an item) are totally inaccessible to screen reader users. A "Go" button needed to allow the user to execute the menu selection.
The following select list is accessible as it requires the user to click on the "Go" button:
<label for="jumpto">Quick links</label><br />
<input type="button" value="Go" />
To make regular HTML based forms buttons accessible, remember to use the value attribute. The text of the value attribute will be read by the screen reader technology. It is not necessary to use the <label> tag with form buttons. The text of the value attribute will also appear inside the button on the screen.
HTML Code: <input type="submit" value="Go!" />
If you use an image as a button, use the alt attribute to match the text in the image or to describe what the button does.
HTML Code: <input type="image" src="go_button.jpg" alt="Go!" />
When Form Fields are Required to be Completed by a User
On the web, it is common to indicate required form fields by color or bold text. However, neither of these is enough by itself. Not all screen readers distinguish bold text, and color alone is no help to a screen reader user or to a color-blind user. The most common solution is to include an asterisk as part of the label. But, some screen readers may not speak the * depending on the user setting.
- Inform the user first that certain form control fields are required to be completed. ALWAYS put messages before the form controls (e.g. at the top of the form)
- Use the word "required" in the <label> (using only an asterisk to indicate a required field is not sufficient)
If a form is to be validated, an error message should be displayed in an accessible manner (not in red alone) indicating precisely which form controls need to be corrected or completed:
- message should appear at the top of the form
- it should indicate which form controls are incomplete or need correcting
- it should provide an indication of how to correct problems such as phone numbers or email addresses that are incorrectly entered.
tabindex attribute arranges the tab order of elements on a web page. When a user presses the tab key, the cursor will move in the order you define. It was most often recommended with the use of form elements.
Initially, it was thought that tab indexing would be helpful to users by allowing them to skip to elements on a page that the page author deemed important to the user. However, in practice, tab indexes have been inconsistently applied and tended to create confusion by taking the user out of the normal flow of the document text. In essence, this creates an alternate "navigation" scheme on a page that presumably already has layout and navigation applied. This can be confusing to a user.
Tab Indices Summary
Web sites on which proper accessibility techniques have been implemented do not require the use of the tabindex attribute.
accesskey attribute allows your users jump directly to an element on which the accesskey attribute is specified. This technique was often used on form elements to help a user jump between elements. However, the accesskey attribute is no longer considered useful in this context for several reasons:
- Through the proper use of the label tag, form elements are clearly identified, and thus allows all users to more easily tab between and recognize form elements ( tabbing is a common practice).
- Screen reader technologies have advanced to the point of allowing users to use a "forms reading" mode to navigate form elements more easily.
- Screen reader applications use a large number of keyboard shortcuts and access keys could conflict with this.
- Because you (as the web developer) choose the access key combinations that you want available to your users, it is highly unlikely that the combination you choose will be familiar to your users. Your users will not understand the benefit that this is to them nor will they understand how to use them.
- Access keys are typically implemented inconsistently across web sites. This can confuse users.
Access Keys Summary:
The accesskey attribute shouldn't be needed on a web site that uses proper accessibility techniques such as headings, lists, skip links, and proper navigation.
If it looks like access key attributes are needed, then you should examine the larger of issue of why they are needed and consider modifying the page using proper accessibility techniques to eliminate this need.