Lotus Notes checklist

Associate labels with editable fields on forms using field help or HTML TITLE.

• Applicable user interfaces

• Rationale

• Required development techniques

• Recommended development techniques

• Required test techniques

Applicable user interfaces

This checkpoint only applies to Lotus Notes applications viewed through the Notes client.

Note: Applications that support both the Notes client interface and the Web interface must complete both the Web checklist and the Lotus Notes checklist. When completing the Web checklist, related techniques and examples for Domino applications are found in Web checkpoint 1.3d – "Forms".

Back to top

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.

Back to top

Required development techniques

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

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:

1. Use the HTML title to define the text label.
2. Define field help for each editable field.

Examples:

1. Use HTML Title to define the text label.

Screen readers read the value of Access Name as the text label for an input field. The Access Name property is defined on the HTML tab of the Field Properties box. 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:

1. Open the form and select the editable field to be labeled.
2. Open the Field Properties box and select the HTML tab.
3. If the Access Name value has the correct text, no further action is needed.
4. If the Access Name does not have the correct text, tab to the HTML Title field and enter the text that matches the visual label the sighted user sees on the form.

Example 1:

The first example shows the HTML tab on the Field Properties box. The value of the Access Name property is Address which matches the visual label for the field. The HTML Title does not need to be modified.

Example 2:

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. In the first example, the text label and input field are in the same table cell, but the asterisk indicating it is a required field is in a separate cell. The screen shot shows that Access Name is set to "Vendor name", so a screen reader user does not know it is a required field.

The second screen shot shows the HTML Title field set to "* Vendor name" which also updates the Access name. Now a screen reader user will know it is a required field. Be sure to put a space after the asterisk so it reads correctly.

2. Define field help for each editable field.

Field help is required for accessibility because it provides additional information to help users fill out forms. While required for all fields, it is especially important for radio button and check box fields. Field help provides the only way that a blind user will have sufficient information to select the correct response.

Use the following steps to add field level help.

• Select the field you want to edit.
• 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.

Example 3:

Screen readers read the radio button value and status. In this example, a typical screen reader might say "Draft radio button. Not Checked." The visual label, "Document Status", might not be read by the screen reader even though it was defined correctly in the Access Name property. Someone using a screen reader would typically query the field help to understand the purpose of the radio button. Most screen readers have a keystroke, for example Ctrl+Shift+H, to read field help. In this example, the screen reader might read, "Document status". The field help combined with the radio button information tells the user it is the Document Status field and they can choose Draft or Final as the options.

Example 4:

Radio buttons with Yes/No values are a more difficult problem for someone using a screen reader. The screen reader says "Yes radio button. Checked." The screen reader user has no idea how to respond. Provide field help that makes the purpose of the radio button or checkbox field clear to someone who cannot see the visual label on the field.

Back to top

Recommended development 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:
  1. Open the form and select the first field.
  2. Open the Field Properties box and select the Info tab.
  3. 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.
• 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.
  1. Select the text, such as instructions to complete the form.
  2. Go to Create - Hotspot - Text Popup. The HotSpot Pop-up Properties dialog is displayed.
  3. 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.
  4. Select Hotspot style: None to maintain the visual look of the form.
  5. Select Show popup: on Click so the popup is keyboard accessible.

Back to top

Required test techniques

Test the application 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
• An object inspection tool such as Microsoft Inspect Objects. (link resides outside of ibm.com)

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. If the field is a radio button or checkbox, the label is only read if you use the appropriate screen reader command sequence to read the field help.	Pass: The screen reader reads the visible text label for all fields on the form. If the field is a radio button or checkbox, the screen reader reads the label when you press the key command to read the field help. Fail: The screen reader does not read the visible text label for one or more fields. When you tab to the field, the screen reader just says "Edit" if it is a text input field. This could be a problem with the screen reader. Verify you are using a current level of the screen reader. 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. If the field is a radio button or checkbox, the Description parameter provides the information defined in the field help which is equivalent to the field label. Fail: The Name parameter does not provide equivalent information to the field label. If the field is a radio button or checkbox, the Description parameter does not provide equivalent information to the field label.

Back to top

©2009 IBM Corporation

Last updated August 25, 2009.

Checkpoint 5.1	Lotus Notes checklist	Checkpoint 5.3