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
About this Technique
This technique relates to 4.1.2: Name, Role, Value (Failure).
This failure applies to all technologies.
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 programmatically associated with the first part, or not programmatically associated with any parts.
Note
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 three-digit area code, a three-digit prefix, and a four-digit suffix. They are typically formatted as follows ([area code]) [prefix]-[suffix], such as (939) 555-0113. Often, forms asking for a telephone number will include three 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 three 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 three-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 programmatically 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 programmatically 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.
Related Resources
No endorsement implied.
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.