Field labels

Lotus Notes checkpoint 5.2

Associate labels with editable fields on forms.

Rationale

Labels for editable fields such as text fields, checkboxes and radio buttons must be explicitly associated to ensure that assistive technologies can communicate the purpose of the field to a user. If the labels are not associated programmatically, screen readers cannot "see" the label next to the input field and will only say "edit" when the user tabs to the control. Someone using a screen reader will not know how to fill in the field.

Development techniques

The following techniques are the minimum required to meet Checkpoint 5.2 from the Lotus Notes Application Accessibility Checklist:

The techniques for associating labels with fields vary based on whether the application will be deployed on the Web or only via the Notes Client. Techniques for both types of applications are defined below.

Notes client applications

Notes client applications must identify the form labels using HTML Title and provide field level help for all editable form fields using the following techniques:

Use HTML Title to define the text label. The "Access Name" property is defined on the HTML tab of the Field Properties box. Most screen readers read the value of Access Name as the text label for an input field. At runtime, the Notes Client and Domino Designer scan immediately left or above an input field to "guess" the field label and put that value in the Access Name property. If the value of Access Name is not correct, you must explicitly update the label by entering the correct value in HTML Title using the steps below:

Open the form and select the editable field to be labeled.
Open the Field Properties box and select the HTML tab.
In the HTML Title field, enter text that matches the visual label the sighted user sees on the form. The example below shows the HTML tab on the Field Properties box. The HTML Title for the StartDate_1 field is Start by which matches the visual label for the field. Notice that the Access Name is also "Start by".

If the field is in a table, the two table cells to the left of the input field are scanned looking for a text label. If a text label is found in the cell immediately to the left of the input field, it is used as the Access Name value. If the cell immediately to the left is empty, the next cell to the left will be checked for a text label. If a text label is found in the second cell, it will be used as the Access Name value. If there is no text label in either cell, Access Name will be blank. Because it is difficult to automatically determine the label for fields in tables, you must verify Access Name and enter the correct label in the HTML Title field if Access Name is incorrect.
Define field help for each editable field.
- Open the Field Properties box and select the Advanced tab.
- Write a brief and unique description for each visible and editable field in the Help Description field. For example, if the form has a Home Address field and a Business Address field, the help description must be unique for each field. This enables the fields to be distinguished by someone using a screen reader.
- Provide meaningful help for all editable fields, including radio buttons. If the field help is "Select yes or no", the screen reader reads "Yes radio button checked. Select yes or no.". It is impossible to determine the purpose of the field, so the user cannot answer the question.
Make important static text on forms readable in edit mode. Forms that contain static or read only text, such as instructions on how to fill out the form, may not be accessible to blind users. When editing the form, the static text is not spoken by a screen reader because it is not in the tab order. To ensure important text is spoken, select the text and create a HotSpot pop-up.

Select the text, such as instructions to complete the form.
Go to Create - Hotspot - Text Popup. The HotSpot Pop-up Properties dialog is displayed.
The Popup text field can be left blank. By making the text a popup, you have accomplished the goal of putting the text in the tab order so it can be spoken by a screen reader as the user tabs through the form. Add text if you want to provide additional information about the field.
Select Hotspot style: None to maintain the visual look of the form.
Select Show popup: on Click so the popup is keyboard accessible.

Domino applications

Domino applications must identify the form labels using HTML Title and manually add the LABEL element using pass-thru HTML using the following techniques:

Provide an HTML Title for each editable control (e.g. text fields, checkboxes, radio buttons).

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. The example below shows the HTML tab on the Field Properties box. The HTML Title for the ProductStatus field is Product Status which is consistent with the visual label for the field.

Section 508 Web accessibility standards require using the LABEL element to identify the labels on form controls. Since Domino Designer does not support the LABEL element directly, use pass-thru HTML to add the LABEL element in the HTML Tag ID field on the in the Field Properties box.
In the example below, the following pass-thru HTML is used for the SendTo field on the Memo form:

<label for="sendto">To:</label>

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.

Recommended techniques

The techniques above are required; the following techniques are recommended to enhance accessibility:

Field help should be 5-8 words in length. If the help is too long, it interrupts the reading of the rest of the document. For example, the help text to enter the name of an interview candidate should say "Interview candidate's name." instead of "Enter the name of the person interviewing for this job".
Start the description with "Required" if the user must fill in the field to save the document.
Say "Select" if the field requires making a choice instead of entering data.
Provide keyboard support to tab from a rich text field to the next field on the form. In the Field Properties box select the Field Info tab. Select the option "Press tab key to move to next field". This enables users to use the keyboard to tab to the next field on the form.
Set the tab order to ensure you can tab to each field in a logical order. Someone who is blind must use the keyboard to tab to each field, if the tab order of the form is not logical it is difficult to complete the form, even when field help and labels have been provided. To set the tab order:
- Open the form and select the first field.
- Open the Field Properties box and select the Info tab.
- Go to the Tab Key section and in the field "Position in tab order" enter a 1. Continue with each field, going in a logical order from top to bottom. Setting the tab order is particularly important within a table. If a table has multiple columns, by default the tab order will go from left to right and top to bottom. This may not be the logical order for your application.

Testing techniques

Test the Web site to ensure that it complies with accessibility requirements.

Tools

Install the following tools to test this checkpoint:

A screen reader for testing with the Notes Client user interface or the Domino Web interface.
An object inspection tool such as Inspect Objects.
A Web accessibility checking tool.

Techniques

*The following techniques are required to verify this checkpoint:*
	Action	Result
1.	Manually test the Notes client application to verify the help descriptions are meaningful. Display field help in the Notes window by selecting "View-Show-Field Help" from the menu bar. Open the document in edit mode. Press `Tab` to move to each editable field on the form. If a field is not editable (e.g., computed or read only fields), you cannot tab to them and field help is not required. Read the help description displayed on the bottom of the application window and verify that the help text is meaningful.	Pass: All fields have descriptions that are meaningful. This includes edit, radio button and check box fields. Fail: One or more fields do not have a description. One of more fields have a description, but it is not meaningful. For example, the Home phone and Office phone fields both have the description "Enter your phone number". This is not useful because you cannot distinguish between the home and office phone field.
2.	After you have tested for the presence of meaningful field help, test the Notes client application with a screen reader to verify label text is accessible through HTML title. Start the screen reader and press `tab` to move to each field. The visible text label should be spoken. If the label is not spoken, use the appropriate screen reader key command sequence to instruct the reader to say the label.	Pass: The screen reader reads the visible text label for all fields on the form. Fail: The screen reader does not read the visible text label for one or more fields. If the screen reader does not read the label, continue with next step to see if the field has been enabled for accessibility. If the object inspection tool shows that the field is enabled (i.e., the label is provided), then the screen reader is at fault, and the test passes.
3.	This step is required only if the screen reader above failed to read a field label. Press `Tab` to reach each field for which the screen reader did not read the label, and verify that the "Name" parameter in the Inspect Objects output provides information that is equivalent to the visible label for the field.	Pass: The Name parameter provides information equivalent to the field label. The field is enabled for accessibility, so the screen reader failure in the previous step is not considered to be a test failure. Fail: The Name parameter does not provide equivalent information to the field label.
4.	This step applies only if the application uses the Web interface. Test each page of the application with a Web checking tool to verify that the LABEL element has been defined for all editable and visible fields.	Pass/Fail: See documentation for your Web checking tool to test accessibility of form fields.
5.	This step applies only if the application uses the Web interface. Read the page with a screen reader. Verify the screen reader announces labels for input fields, text areas, and select menus.	Pass: The screen reader announces the labels of the input elements and text areas. The screen reader announces the label of select menus. Fail: The screen reader does not read the label for input elements in text areas, or the label for select menus.

Last updated February 08, 2008.

Checklist