The correct labeling of input controls on forms is typically the most important accessibility concern of the widget developer. A visually impaired user may use a screen reader to access the application. A screen reader is a software application that converts the text of a web page (or other application) into speech, allowing the user to hear what is present and respond appropriately. When using a form, the screen reader will inform the user of the input control that currently has the input focus. For example, the user may use the Tab key to move the focus to the text field with the label Date of Birth and the screen reader will announce "Date of Birth, edit"; adding the word "edit" to notify the user that the control is editable. This is only possible if the screen reader can associate the label of the field with the input control for that field.
All of the accessibility standards require that input controls on forms be identified by labels that can be used by a screen reader. The implementation guidelines for these standards often demonstrate the use of the HTML label element that allows the label text to be marked up with an element that defines the ID of the input control for which that text is the label. Some validation tools then enforce this particular implementation guideline to the exclusion of all others. The CDEJ does not use the HTML label element to associate label text with form input controls, it uses an alternative method. The HTML of a Cúram application page may fail an automated accessibility validation check for this reason, but this failure is erroneous and does not affect the accessible of the form input controls to a screen reader application.
The technique used by the CDEJ is the same technique that widget developers should use. The visible label of the input control is rendered separately and automatically by the CDEJ and the title attribute of the input element is set to the value of the label that should be read by the screen reader for that control. There are several reasons why this approach is used by the CDEJ instead of the often suggested label element:
- The label element displays its label as the visible label on the page for the form control. It is not possible to associate a single label element with more than one input control, as it may only have one ID value in its for attribute. For example, a UIM CONTAINER element is used and it contains two FIELD elements. One label, that of the container, will appear beside two input controls, one for each field. A search form may have a Surname label appearing beside a text field and a check-box. The user inputs the surname into the text field and checks the checkbox if the search should find names that sound like that surname. Using a label element, it is not possible to label these controls without displaying two labels on the page and that is not desired. However, it is easily achieved using the title attribute on the input elements for the text field and the checkbox. The values of the title attributes are set from the labels of the UIM FIELD elements, not the CONTAINER element, so the labels can be specific to each input control while the visual presentation is still uncluttered.
- Most browsers use the title attribute of an input control as the text displayed in a tool-tip shown then the use hovers over the control with the mouse pointer. This allows sighed users to identify controls even if the specific label for the control is not shown on the page. For example, the label of the Sounds Like check-box in the example above. Using the title attribute, therefore, makes the application more accessible to sighted users, too.
- For mandatory input fields, an icon is displayed beside the label of the field to alert the user to the fact that a value must be entered. This icon is not apparent to a screen reader application, as it is applied using a CSS style rule and is not part of the content of the HTML document. For accessibility, the word "mandatory" can be appended to the label value used in the title attribute of the input control while omitting it from the visible label that already has the visible mandatory icon. It is not possible for the visible label to differ from the input control label in this way if the label element is used.
- When rendering a page, the CDEJ renders the field label before invoking the widget's renderer plug-in for the field value (assuming labels of shown to the left of the values). As the CDEJ does dictate what input control will be produced by an edit-renderer plug-in, it cannot know in advance what the ID of the control will be and cannot set an ID in the for attribute of a label element. It is not possible, therefore, to use the label element while allowing widgets for the field values to be customized. This is not a problem, as the label element is not desirable for all of the other reasons described above.
These are the main reasons why the CDEJ uses and recommends the title attribute in preference to the label element. The application pages are equally, if not more, accessible to screen reader applications and users as a result. Any spurious errors from accessibility validation tools relating to the non-use of the label element can be safely ignored once the presence of the title attribute has been confirmed.