Here’s what I have gleaned based on reading the references cited below.
1. Colons are hard to see on a screen. (Reference 1.)
2. W3C does not state a requirement for a colon after a label.
3. WAI recommends identifying a label with a LABEL tag and does not mention using a colon. (Reference 3.)
4. 508 Standards Information for Standards does not mention using a colon for labels.
5. Microsoft Active Accessibility (MSAA) software might require the colon. (Reference 2.)
6. According to Microsoft, screen-review utilities might use a colon to identify a control. (Reference 4.)
I suspect that using a colon after a label is a carry over from paper forms. Microsoft may need the colon. I do not know what “screen review utilities” are. Are they html validators? Are they accessibility validators?
What say you all?
---------------------------------------------------------------------------
Reference 1.
William Horton in his book “Designing and Writing Online Documentation” recommends avoiding colons and semicolons because they are hard to distinguish on a screen.
---------------------------------------------------------------------------
Reference 2.
Wright State University
http://www.wright.edu/web/access/standard_n.html
(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
WSU Web Accessibility Guidelines
WSU Information
Ensure that the user may interact with the form with a preferred input (or output) device, such as a mouse, keyboard, voice or head wand. If a form control can only be activated with a mouse or other pointing device, someone who is using the page without sight, with voice input, or with only a keyboard will not be able to use the form.
- Use "explicit labels" as outlined in the 508 Standards Information for Standard (n).
- Provide a phone number the Web visitor can call to verbally supply the requested information. An e-mail address should also be included.
- Preface each form element with a descriptive name followed by a colon. The Microsoft Active Accessibility (MSAA) software calls each form element by the word prior to and on the same line as the form element.
Example:
<label for="" Name:</lablel> <INPUT TYPE="text" name="firstname" id="first">
--------------------------------------------------------------------------------------
Reference 3.
Sarah Horton, Accessible Design Guidelines
http://www.dartmouth.edu/~webteach/resources/download/guidelines5.pdf
Pay attention to punctuation
Screen readers use punctuation cues to modulate the tone and measure of the reading, e.g., a colon will cause the screen reader to pause; a period will produce a cadence and pause. Be liberal with punctuation as these pauses and cadences greatly enhance the readability of your text. Without punctuation the reader continues without pause or change in inflection, so unpunctuated phrases run together into one long and jumbled sentence.
Also, avoid using text to convey visual information, such as using a “>” or “/”symbol as navigation to show the path to the user’s current location. The screen reader will read the symbol literally rather than interpret the visual meaning you wish to convey.
Label form fields
If you simply place a form field on a page and do not have a label associated with it, users who are read Web pages will have no way of knowing what the field is there for. Associate labels with their form fields by positioning them together on the page and by using the LABEL tag to associate the label text with its form field. Note that you need to include the ID attribute in your INPUT tags whenever you use the LABEL tag.
Use LABEL to associate fields with their labels
Example:
<LABEL FOR="" name: </LABEL><INPUT TYPE="text" NAME="firstname" ID="firstname">
<LABEL FOR="" name: <INPUT TYPE="text" NAME="lastname" ID="lastname">
--------------------------------------------------------------------------------------
Reference 4.
Microsoft Developers Network
http://msdn.microsoft.com/library/en-us/dnwue/html/ch15c.asp
Accessibility
Controls
Use standard Windows controls wherever possible. Most of these have already been implemented to support screen-review and voice-input utilities. However, the custom controls you create may not be usable by screen-review utilities.
Include a label for every control, even if you do not want the control's label to be visible. This applies regardless of whether you use standard controls or your own specialized controls, such as owner-drawn controls or custom controls. If the control does not provide a label, you can create a label using a static text control that you can define as hidden.
Follow the standard layout conventions by placing the static text label before the control (above or to the left of the control). Also, set the keyboard tab navigation order appropriately so that tabbing to a label navigates to the associated control it identifies instead of to a label.
To make sure that the label is recognized correctly, include a colon (:) at the end of the label's text string, as shown in Figure 15.1, unless you are labeling a button, tab, or group box control. Screen-review utilities often use a colon to identify the control. In cases where a label would be visually distracting, provide the label but do not make it visible. Although the label is not visible, it will still be accessible to a screen-review utility.
Text labels are also effective for choices within a control. For example, you can enhance menus or lists that display colors or line widths by including some form of text representation.
If providing a combined presentation is too difficult, offer users the choice between text and graphical representation, or choose one of them based on the system's screen-review utility setting.
