Web checklist

Form element labels can be programmatically determined.

Forms can be an accessibility issue for someone who is blind if the form elements cannot be identified when they try to complete the form. There are two big accessibility issues with completing forms: understanding which text label describes each form field and understanding which fields are required to complete the form. When using a screen reader, you need to be able to tab through a form and understand the purpose of each form element.

The following resources provide additional information on accessible forms:

• Accessible Forms (link resides outside of ibm.com) from Jim Thatcher.
• Creating Accessible Forms (link resides outside of ibm.com) from WebAIM.
• If the form includes JavaScript, see checkpoint 2.1b: Scripts.

Back to top

Compliance with this checkpoint requires all of the following techniques be met. These techniques are defined in the WCAG 2.0 Level A Success Criterion Guideline 1.3.1 (link resides outside of ibm.com). These techniques are consistent with Section 508 guidelines for accessible forms.

1. Label elements: Using label elements to associate text labels with form fields.
2. Title attribute: Using the title attribute to identify form controls when the label element cannot be used.

Examples for HTML developers

1. Label elements: Using label elements to associate text labels with form fields.

To comply with this technique, all of the following examples must be implemented.

Some form field controls, such as submit buttons, are automatically associated with a label. But text fields, select menus, checkboxes and radio buttons must have an explicit label using the <label> element with the for and id attributes so that assistive technologies can communicate the purpose of the form element to the user. If the visual label has not been explicitly associated using the label element, a screen reader user may only hear "edit" and not know how to complete the form.

The value of the for attribute must be the same as the value of the id attribute of the associated control. In addition, each <label> element can only be associated with exactly one form control. However, a form control can have more than one <label> element associated with it.

Example 1

Use the <label> element for text fields.

Name

Name:

<form action="mailto:somebody@ibm.com">
<label for="name1">Name</label>
<input name="name" id="name1" size="30" />
</form>

Example 2

Label a select menu using the <label> element.

Select your shipping method

Select your shipping method Ground – 7 business days Air – 3 business days Next day air – 1 business day

<form>
<label for="shiptype">Select your shipping method</label>
<select id="shiptype" name="ship_method" size="1">
<option selected value="">Ground – 7 business days</option>
<option value="air">Air – 3 business days</option>
<option value="nextday">Next day air – 1 business day</option>
</select>
</form>

Example 3

Label required fields on a form.

If layout tables are used to align form fields, put the label and the character to indicate a required field in the same table cell. If the asterisk is in one cell and the label is in another cell, they will not be read correctly by assistive technology. This example shows how to indicate the field is required so it is accessible.

An * indicates required fields.

* Name:

...
<td> <label for="reqfield">* Name:</label></td><br />
<td><input name="Name" id="reqfield" type="text" /></td><br />
...

Note that the example uses an asterisk in addition to the color red to indicate a required field. In addition, the mechanism for identifying required fields is clearly labeled at the beginning of the form.

Refer to WCAG 2.0 examples for using the label element (link resides outside of ibm.com) for more examples of this technique.

Example 4

Label required fields on a form using the WAI-ARIA aria-required (link resides outside of ibm.com) property.

Note that WAI-ARIA examples are only supported in Firefox 3.0 or higher and JAWS 10 or higher at this time. If your product needs to be accessible in both IE and Firefox today, one or more of the required HTML/CSS specific techniques must be implemented as well as a WAI-ARIA technique. When WAI-ARIA becomes an approved W3C recommendation and IE fully supports WAI-ARIA, then WAI-ARIA techniques alone will be sufficient to comply with this checkpoint in both IE and Firefox.

An asterisk and footnote indicates to a sighted user that data is required for a particular form field. However, if the footnote explaining the asterisk is rendered at the bottom of a form or page, a blind user may not know that the asterisk indicates a required field until she navigates to the bottom of the form or page.

Adding an aria-required property to the input element below enables a screen reader to provide immediate feedback that a name is required. When aria-required is set to true, a screen reader will say "required" when the name field receives focus.

<td> <label for="reqfield">* Name:</label></td>
<td><input name="Name" id="reqfield" type="text" aria-required="true" /></td>

2. Title attribute: Using the title attribute to identify form controls when the label element cannot be used.

To comply with this technique, all of the following examples must be implemented except the WAI-ARIA aria-labelledby example. The aria-labelledby example may be used when a screen reader does not announce a title attribute.

If a form field does not have a visible label, a sighted user can understand the purpose of the field by seeing the field in context with the rest of the page. The field will not be accessible to someone using a screen reader because they will hear "Edit" and not know how to complete the form. The title attribute can be used to identify form controls where there is no visible label. A "tool tip" is displayed when the mouse is positioned over the form elements that contain title attributes. The title attribute is spoken by screen readers.

Example 5

Use the title attribute for a group of radio buttons

This example displays a group of five radio buttons on a survey form with possible choices ranging from "Very Important" to "Not Important". To simplify the visual look of the page, only three of the radio buttons have visible text labels. A sighted user can see the intent of the unlabeled radio buttons, but a blind user will hear "radio button not checked" unless they are labeled. Because there are no text labels, the label element cannot be used. The title attribute provides information about the radio button to someone using a screen reader.

Very Important

Important

Not Important

A subset of the code for this example is listed below.

<label for="important">Very Important</label>
<input type="radio" name="important" value="5.0" id="important" />
<input type="radio" name="veryImportToImport" value="4.5" title="Very important to important" />

Example 6

Use the title attribute for input fields

In this example users enter their phone number into three separate fields. The first input field is labeled Phone, so the <label> element identifies the label. The other fields have no visual labels, so the title attribute provides information about the fields. Screen readers look for the <label> element, but if it isn't provided, they will read the title attribute.

Phone:  - - 

<input type="text" name="num2" title="Enter your 3 digit phone exchange" />
<input type="text" name="num3" title="Enter the last 4 digits of your phone number" />

Example 7

Note that WAI-ARIA examples are only supported in Firefox 3.0 or higher and JAWS 10 or higher at this time. If your product needs to be accessible in both IE and Firefox today, one or more of the required HTML/CSS specific techniques must be implemented as well as a WAI-ARIA technique. When WAI-ARIA becomes an approved W3C recommendation and IE fully supports WAI-ARIA, then WAI-ARIA techniques alone will be sufficient to comply with this checkpoint in both IE and Firefox. Please refer to the WAI-ARIA overview and WAI-ARIA Best Practices section: Providing Logical Layout Semantics using Structural Roles for more information.

Use the WAI-ARIA aria-labelledby (link resides outside of ibm.com) property when the HTML title attribute isn't spoken by a screen reader. The following example shows the two input fields from the previous example. However in this example, an aria-labelledby (link resides outside of ibm.com) property is used to provide information about the fields. A screen reader will always speak an aria-labelledby attribute.

<input type="text" name="num2" aria-labelledby="exchange" /> <input type="text" name="num3" aria-labelledby="lastfour" />

<div id="exchange">Enter your 3 digit phone exchange</div>
<div id="lastfour">Enter the last 4 digits of your phone number</div>

Example 8

Use label element, title attribute and correct table markup for forms in tables

This example uses the label element, the title attribute and correct table markup to show how to make forms in tables accessible to screen reader users.

Placing a form in a table is sometimes preferred to give a page a nice "look and feel". This table conforms to checkpoint 1.3e: Tables so all table headings are spoken. In addition, the label element and title attribute are used so the form is accessible if table reading mode is not used.

<th>Apparel</th>
<th>Size</th>
<th>Color</th>
<th>Style</th>
...
<th>Shoes</th>
<td>
<input type="text" name="ShoeSize" title="Shoe Size" /></td>
...
<td>
<fieldset><legend>Shoe Style:</legend>
<input type="radio" name="ShoeStyle" id="cshoestyle1" value="Sneaker"/>
<label for="cshoestyle1">Sneaker</label><br />
<input type="radio" name="ShoeStyle" id="cshoestyle2" value="Dressy"/>
<label for="cshoestyle2">Dressy</label><br />
<input type="radio" name="ShoeStyle" id="cshoestyle3" value="Casual"/>
<label for="cshoestyle3">Casual</label><br />
<input type="radio" name="ShoeStyle" id="cshoestyle4" value="Hiking"/>
<label for="cshoestyle4">Hiking</label>
</fieldset>
</td>

For additional information, refer to WCAG 2.0 examples for using the title attribute to identify form controls when the label element cannot be used (link resides outside of ibm.com).

Back to top

Examples for Dojo developers

This section provides specific examples to implement the Web techniques for accessible Dojo labels.

1. Label elements: Using label elements to associate text labels with form fields.

To comply with this technique, all of the following examples must be implemented.

Example 9

Dojo input controls must be given explicit labels using the element with the for and id attributes so that assistive technologies can communicate the purpose of the control. If a visual label is not explicitly associated with an input control, a screen reader user may only hear "edit" and not know how to respond to the control.

The value of the for attribute must be the same as the value of the id attribute of the associated control. In addition, each element can only be associated with exactly one form control. However, a form control can have more than one element associated with it.

The following example shows how to label a Dojo Textbox widget.

<label for="name1">Name</label> <input name="name1" id="name1" dojoType="dijit.form.TextBox" />

Example 10

Currently, screen readers do not read Dojo Slider text labels properly when specified with VerticalRuleLabels and HorizontalRuleLabels. However, numeric labels specified with VerticalRuleLabels and HorizontalRuleLabels are read. Therefore, avoid using text labels that are specified with VerticalRuleLabels and HorizontalRuleLabels. Numeric labels specified with VerticalRuleLabels and HorizontalRuleLabels may be used. The following examples demonstrate the correct and incorrect way to specify VerticalRuleLabels and HorizontalRuleLabels for a Dojo Slider.

Correct way to specify labels (numeric values are used):

<dojoType="dijit.form.HorizontalSlider">
...
<ol dojoType="dijit.form.HorizontalRuleLabels" container="topDecoration">
<li>20</li>
<li>40</li>
<li>60</li>
<li>80</li>
</ol>
</div>

Incorrect way to specify labels:

When non-numeric text labels are used, a screen reader will incorrectly announce “one, two, three, four" which doesn't make sense in context of the following example.

<dojoType="dijit.form.HorizontalSlider">
...
<ol dojoType="dijit.form.HorizontalRuleLabels" container="topDecoration">
<li>high school</li>
<li>associate's degree</li>
<li>bachelors degree</li>
<li>advanced degree</li>
</ol>
</div>

2. Title attribute: Using the title attribute to identify form controls when the label element cannot be used.

To comply with this technique, all of the following examples must be implemented.

Example 11

The Dojo InlineEditBox appears as inline text so it is likely that the widget will appear without a label. If the InlineEditBox is not given a label, a title attribute is required in order to make the widget accessible. The following InlineEditBox example uses a title to inform a screen reader user that the heading is editable.

<h3 id="editable" dojoType="dijit.InlineEditBox" title="editable level 3 heading" onChange="myHandler(this.id,arguments[0])">Table of contents </h3>

Example 12

Currently, screen readers do not read a label associated with a Dojo Slider widget. Therefore, a title attribute is required to enable blind users to identify a Dojo Slider. The following markup renders a Dojo Slider widget with a title to indicate to a screen reader user that a difficulty level should be selected.

<div id="horizontalSlider" dojoType="dijit.form.HorizontalSlider" title="Select a difficulty level using the slider"> ... </div>

Back to top

Examples for Flash developers

1. Label elements: Using label elements to associate text labels with form fields.

To comply with this technique, all of the following examples must be implemented.

Example 13

Use the Flash components (Windows — Components) that are native to Flash when possible.

Those planning on using any of the component types (form elements) listed below will first need to enable the accessibility object by using the ActionScript command enableAccessibility(). This includes the accessibility object with the component as the movie is compiled. By default, the accessibility object is turned off. However, once you enable the accessibility object on the component, any of the following form elements will then have access to the Accessibility Panel:

1. Button
2. Check Box
3. Radio Button
4. Text Input
5. Text Area
6. Combo Box
7. List Box
8. Data Grid
9. Tile List

It is best to attach this enableAccessibility() code to the first frame of the movie. Once the accessibility object is enabled, you will then be able to open the Accessibility Panel for all instances of that type of component. For more information on the enableAccessibility() command, see Components and Accessibility (link resides outside of ibm.com), on Adobe's website.

Example 14

Use descriptions in Flash to inform the user about the status / purpose of any controls that are used, and make this information available to the screen reader.

Example 15

Use Auto-labeling in Flash.

2.Title attribute: Using the title attribute to identify form controls when the label element cannot be used.

To comply with this technique, all of the following examples must be implemented.

Example 16

Selecting the Flash auto-label checkbox doesn't always work seamlessly with a screen reader.

Testing your forms is very important to ensure that your controls are correctly labeled. If the auto-labeling does not read correctly with a screen reader, you may give the control the same name attribute as the text that you are using as a label for the form. Then make the text itself invisible to a screen reader. This is an acceptable work-around for labeling controls if the auto-labeling causes difficulty for a screen reader.

Back to top

Examples for Domino developers

1. Label elements: Using label elements to associate text labels with form fields.

To comply with this technique, all of the following examples must be implemented.

Example 17

Associate text labels with form fields in Domino.

• Open the form and select the editable field to be labeled.
• Press Shift-F10 or right click the field and select Field Properties.
• Select the HTML tab. Go to the HTML Tags – Other field.
• Enter the text that matches the visual label the sighted user sees on the form. For example, if the text label is Date, enter Date in the field.

Example 18

Do not use HTML title to add the label for radio buttons and checkboxes in Domino.

Domino only supports a single title attribute for all the radio buttons in the group. This means a screen reader will read the same title for each radio button and the field will not be accessible.

At this time, it is not possible to create radio buttons and checkboxes that are fully compliant in Domino. You can use the following technique to create radio buttons and checkboxes that are read correctly by JAWS, but they will fail WebKing because there is no element or title attribute. If there is no title attribute or element, a screen reader will automatically read the value of the radio button and the state of checked or not checked.

• Open the form and select the editable field to be labeled.
• Press Shift-F10 or right click the field and select Field Properties.
• Select the HTML tab. Go to the HTML Tags – Other field.
• Be sure there is no text in the Other field, it must be blank. If Designer has filled in a value, delete the text.

Example 19

Add the element to associate text fields, but it must be done with pass-thru HTML.

Do not use this technique with radio button or checkbox fields in Domino.

• Open the form and select the editable field to be labeled.
• Press Shift-F10 or right click the field and select Field Properties.
• Select the HTML tab. Go to the HTML Tags – ID field.
• Add the element in the ID field that matches the visual label the sighted user sees on the form.

Example 20

Pass-thru HTML is used for the SendTo field on the Memo form: To:

On the HTML tab of the Field Properties box, the ID is set to the value "sendto". The HTML Title is set to the value "To:" for consistency with the visual label on the field.

Example 21

Use HTML title and correct table markup to make a form in a table accessible.

Since the form below is in a table, requirements in Web checkpoint 1.3e - Tables must be implemented. In addition, the form fields must follow the requirements of this checkpoint for accessible forms. Someone using a screen reader will be able to navigate the table in Table Reading mode or Forms mode to complete the information.

The Column headers were set for Size, Color and Price as shown in the screen shot below of the Table Properties box. Row headers were defined for Shoes, Shirt and Pants.

The HTML title has been defined for all fields except the checkboxes. The screen shot below shows the Field properties for the shoe color field. HTML title has been set to Shoe Color. When in Forms reading mode, the user will hear HShoe color. Combobox. Black. One of four." In Table reading mode, you hear “Row 2. Column 3. Shoe Color. Black. One of four."

For the checkboxes, the HTML Title field has been left blank. As explained previously, there is no way to make radio buttons and checkboxes fully compliant in Domino at this time without writing pass-thru HTML. The HTML Title field is blank, so the screen reader will say “Small. Checkbox not checked." Table reading keys can be used to determine whether the cell is for shoes or jackets.

2. Title attribute: Using the title attribute to identify form controls when the label element cannot be used.

To comply with this technique, all of the following examples must be implemented.

Use the HTML Title attribute in the Field Properties box to associate the text label with the form field for editable text, rich text, listbox, combobox, number and date/time fields. This technique is not accessible when used with radio button or checkbox fields.

Example 22

Provide an HTML title for each editable control in Domino (e.g. text fields, listboxes, comboboxes) using the following steps:

• Open the form and select the editable field to be labeled.
• Open the Field Properties box and select the HTML tab.
• Add a title that matches the visual label the sighted user sees on the form.

3. Provide a descriptive title for every form.

Example 23

In a Domino application, the title of the form or page is displayed in the title bar in the browser window. For example in Internet Explorer, if the window title is "Inspection form", the browser title is displayed as "Inspection form - Microsoft Internet Explorer". If the window title is missing, the browser will display the URL for the form or page as the title instead of a meaningful title. Use the following steps to add a window title to forms:

• Open the form or page and select "Event: Window Title" in the design pane.
• Enter a window title (enclosed in quotes) in the formula window.

Back to top

Implementation of recommended techniques is not required to comply with this checkpoint, but these techniques should be reviewed since they can improve the accessibility and usability of the application.

1. Use WAI-ARIA aria-describedby

Note that WAI-ARIA examples are only supported in Firefox 3.0 or higher and JAWS 10 or higher at this time. If your product needs to be accessible in both IE and Firefox today, one or more of the required HTML/CSS specific techniques must be implemented as well as a WAI-ARIA technique. When WAI-ARIA becomes an approved W3C recommendation and IE fully supports WAI-ARIA, then WAI-ARIA techniques alone will be sufficient to comply with this checkpoint in both IE and Firefox.

Often help text is associated with a form field and rendered by activating an image link beside the field. When help text is initially hidden and then exposed via CSS, a screen reader doesn't always read the text.

This problem may be overcome by associating the form field with the help text via a WAI-ARIA aria-describedby property. The following example exposes help text to sighted users when the help icon is clicked. Blind users hear the same help text when the help icon receives focus. The field is associated with its help text by setting the aria-describedby property to the id attribute value on the help text container div.

Name:   

Help 

<img onclick="showHelp();" src="help.gif" alt="help" aria-describedby="nameHelp" tabindex="0"/>
<div id="nameHelp" style="visibility: hidden;">
This is a long description of the name field...
</div>

2. Use the optgroup element.

The optgroup element is used to group options in a drop-down list under the select element. Use optgroup when the user must choose from a long list of options. Groups of related choices are easier to grasp and remember than a single long list of options.

Accessibility Options

Accessibility Options: Web Software Java Hardware

...
<label for="menu">Accessibility Options:</label>
<select name="select" id="menu" >
<optgroup label="Checklists">
<option value="Web">Web</option>
<option value="Software">Software</option>
<option value="Java">Java</option>
<option value="Hardware">Hardware</option>
</optgroup>

3. Adding invisible labels using alt text.

While using the title attribute is preferred, alt text can also be used to add labels for fields where the label element cannot be used. This technique uses a spacer image with alt text to describe the field label. For example, the following set of radio buttons could be coded using this method rather than using the title attribute.

Here is the code for the radio buttons using a spacer image with appropriate alt text.

Very Important

Important

Not Important

<label for="veryi">Very Important</label>
<input type="radio" name="1,300" value="5.0" id="veryi" />
...
<label for="vii">
<img src="images/clearpixel.gif" height="1" width="1" border="0"
alt="Very important to important" /></label>
<input type="radio" name="1,300" value="4.5" id="vii" />

See WCAG 2.0 Additional Techniques (Advisory) for 1.3.1 (link resides outside of ibm.com) for a further list of techniques and examples.

4. Recommended techniques for Domino developers

Define a window title that changes based upon the status or use of the document. For example, a different window title should be defined for new documents. Once the document has been created, the window title can include helpful information such as the date it was created or the status of the document.

Back to top

The following test tools and techniques are required to test this checkpoint.

1. Test tools
2. Required accessibility verification test techniques

Back to top