Technique F86:Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number
Applicability
General
This technique relates to 4.1.2: Name, Role, Value (Failure).
Description
This describes a failure condition of Success Criterion 4.1.2 where some or all of the parts of multi-part form field do not have names. Often there is a label for the multi-part field, which is either programatically associated with the first part, or not programatically associated with any parts.
A name does not necessarily have to be visible, but is visible to assistive technologies.
Examples
Example 1
A US telephone number consists of a 3-digit area code, a 3-digit prefix, and a 4-digit suffix. They are typically formatted as follows ([area code]) [prefix]-[suffix], such as (206) 555-1212. Often, forms asking for a telephone number will include 3 separate fields, but with a single label, such as:
Phone number: (<input type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">
The failure occurs when there is not a name for each of the 3 fields in the Accessibility API. A user with assistive technology will experience these as three undefined text fields. Some assistive technologies will read the punctuation as identification for the text fields, which can be even more confusing. In the case of a 3-field US phone number, some assistive technologies would name the fields "(", ")" and "-", which is not very useful.
Example 2
The same US telephone number. In this case, the label is not programatically associated with any of the parts.
Phone number: (<input type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">
A user with assistive technology will experience these as three undefined text fields.
Example 3
The same US telephone number. In this case, the label is programatically associated with the first part.
<label for="area">Phone number:</label> (<input id="area" type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">
A user with assistive technology will be led to believe that the first field is for the entire phone number, and will experience the second and third fields as undefined text fields.
Other sources
No endorsement implied.
- Microsoft Active Accessibility 2.0 SDK. Includes Inspect32.exe and other MSAA tools.
- Gnome Accessibility Toolkit documentation
- Microsoft Internet Explorer Developer Toolbar. Allows examination of script-generated DOM in Microsoft Internet Explorer.
- Firebug. Allows examination of script-generated DOM in Firefox.
Tests
Procedure
For each subfield in the multi-part form field:
- Check that there is a programmatically determined name for the field.
Expected Results
- If check #1 is false for any subfield, then the failure condition applies and the content fails the success criterion.