Lotus Notes checklist

Checkpoint 5.2: Field labels

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

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".


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.

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.


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.

Access name

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.

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.

Document status: Draft, Final

Document status: Draft, Final

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.

Document status: Draft, Final

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.

Hot Spot pop-up

Required test techniques

Test the application to ensure that it complies with accessibility requirements.


Install the following tools to test this checkpoint:


The following techniques are required to verify this checkpoint:
Action Result


Manually test the Notes client application to verify the help descriptions are meaningful.




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.




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.



©2009 IBM Corporation

Last updated August 25, 2009.