Provide a valid label for form fields

Media Type Web > Forms
State Active
Advisory No

When on-screen labels are present, they must be programmatically associated with form fields. When on-screen labels are not present, form fields must be given an accessible label.

When form fields do not have a programmatic (accessible) label, assistive technologies may incorrectly render the label or provide no label at all to users. When labels are not present or are incorrect, users of assistive technologies may not be able to complete a form.

The HTML5 specification has a new form field attribute called placeholder. This represents a label or hint, such as a word or short phrase, that is assigned to a form field such as an input field. The label or hint appears within the form field and goes away when users start typing. When the placeholder attribute is used, the label or hint may not be detected by assistive technologies. Therefore, developers should provide off-screen text in the label element of the form field or provide a title

Compliant Example

<!-- Compliant example #1 (using label element): -->
<label for="ship1">Ship To:</label>
<input id="ship1" type="text" name="shiptoaddr1"
size="30">

<!-- Compliant example #2 (using title attribute instead of label element) visual label
exists but is not associated: -->

<span>Ship to:</span>
<input title="Ship to:" type="text" id="s1"
size="30">

<!-- Compliant example #3 (label has no "for" attribute but does wrap the
input element): -->
<label>Ship To:
<input id="ship1" type="text" name="shiptoaddr1"
size="30"></label>

<!-- Compliant example #4 (using meaningful title attribute): -->
...
<tr>
  <th scope="col">Select training</th>
  <th scope="col">Training</th>
  ...
</tr>
<tr>
  <td><input type=checkbox title="Select Training
ACL"...></td>
  <td>Training ACL</td>
  ...
</tr>
...

<!-- Compliant example #5 (aria-labelledby example): -->
<div id="d1">First Name:</div>
<input type="text" id="t1" aria-labelledby="d1" />

<!-- Compliant example #6 aria-label example): -->
<input aria-label="Search" type="text" id="search" />
<button id="b1"> Go </button>

<!-- Compliant example #7 (HTML5 placeholder attribute. Placeholder attribute should
not be a substitute for providing a label for the form field.): -->
<label for="name"><span
class="hidden">Name:</span></label><input
aria-label="name" type="text" name="name"
id="name" placeholder="Name:" >.

<!-- Compliant example #8 (using Angular.js)-->
HTML:
<section ng-controller="FormController as ssb">
<h3>{{ssb.heading3}}</h3>
<div ng-repeat="forms in ssb.formControls">

<div class="form-elements">
<label for="{{forms.id}}">{{forms.label}}: </label>
<input id="{{forms.id}}" type="{{forms.type}}" />
</div>

</div>
</section>

ANGULAR.JS SNIPPET:
app.controller("FormController", function(){
this.formControls=basicforms;
this.heading3="Basics- Using a Repeater";		
});

var basicforms=[
{
label:'First Name',
type:'text',
id:'txtFirstName',
},

{
label:'Last Name',
type:'text',
id:'txtLastName',
},

{
label:'Email',
type:'email',
id:'txtEmail',
},

{
label:'Date of Birth',
type:'text',
id:'txtDate',
hint:'mm/dd/yyyy',
hintID:'hintDate',
}, 
];

Non-Compliant Example

<!-- Non-compliant example #1 (no label or title, by position only): -->
Ship To: <input type="text" name="shiptoaddr1"
size="30">

<!-- Non-compliant example #2 (label tag is empty/null): -->
<label for="ship1"></label>
<input id="ship1" type="text" name="shiptoaddr1"
size="30">

<!-- Non-compliant example #3 (label has no "for" attribute; often occurs in
tandem with an "implicit label" violation that does NOT wrap the input element):
-->
<label>Ship To:</label>
<input id="ship1" type="text" name="shiptoaddr1"
size="30">

<!-- Non-compliant example #4 (Generic title attribute): -->
<tr>
<td><input type="checkbox" title="Click to
select"...></td>
<td>Training ACL</td>
</tr>

<!-- Non-compliant example #5 (HTML5 placeholder attribute) -->
<input type="text"  placeholder="Name" >

Developers can define form labels using the label element whenever an on-screen label is present. The label element's value is then explicitly associated with the relevant form field using the for and id attributes, or the label element can enclose (wrap) the form field for an implicit association (but see the note below about Dragon's lack of support for this "implicit association"). Use of the label element provides an added benefit as it increases the target area that users can click to focus the form field. In certain instances, however, it is impractical or 'undesirable' to use an explicit label for a form field; this is largely driven by the fact that the value between the opening and closing label tags must, by definition, be a block of displayed text.

When on-screen text is not available or can not programmatically be contained in a label (such as when a field is placed in a data table with with a column label and a row label) - developers can use another method to provide an accessible name such as by using the title, aria-label, or aria-labelledby attribute to provide the label (see below for details on using aria-labelledby and aria-label). Note: When an accessible name exists from an explicit label, aria-label, or aria-labelledby AND a title attribute is used -- the title attribute will act as the accessible description for the input field and does not override the accessible name. The aria-describedby property can also be used to provide a description for the input field such as to associate instructions or error messages with a field.

The accessible name must sufficiently indicate the purpose/usage of the form field as conveyed by the visual label and/or the visual layout. This is important because some users of assistive technology such as speech recognition software may interact with a form field by speaking the field's visual label. When the programmatic label does not match the visual label or obstacle may be created for users of speech recognition software. Furthermore, to prevent confusion with AT to know which programmatic information to use as the accessible name, title, label, or ARIA based names should be used in a mutually exclusive fashion unless title is acting as the accessible description..

The aria-label and aria-labelledby attributes can also be used to provide a label or labels for form fields to assistive technology that supports ARIA. The aria-labelledby attribute must contain one or more ids of elements that label the form field. Note: for multiple labels to properly be rendered in older versions of Internet Explorer it may be necessary to set tabindex="-1" on the elements designated as labels. The aria-label attribute should only be used when on-screen labels can not be used. Developers should place the string that labels the form field in the aria-label attribute. Note: The spelling of aria-labelledby is the British spelling with two "l"s.

Notes:

Whenever a form field is required, or some other form of constraint applies, developers should ensure the "required" indicator (typically an asterisk *) is included in the accessible name, the label, title attribute, aria-label, or content referenced by aria-labelledby. A better solution is to use the aria-required attribute to indicate that a form field is required.
Also, assistive technologies such as screen readers can become confused by the presence of formatting markup between the opening and closing label tags, resulting in the incorrect reading of its text value. Examples include the emphasis elements strong and b, and the line break element br. Developers should move any desired formatting markup outside the label block, rather than inside it, or verify that the usage is rendered correctly in screen readers. (This does not apply to the use of form input labels put in the input's title attribute.)
There should be no more than one label explicitly associated to a given form field.
HTML5 placeholder attribute should not be used as a substitute for the label of the form field. If the HTML5 placeholder is used as a label of the form field, an alternative method must be provided. For example, an explicit label, a title attribute or the CSS off-screen text.

Some assistive technology may not support implicit form labels that wrap an input field. For assistive technology such as Dragon Naturally Speaking speech recognition that does not support this another method should be provided. An implicit label that wraps label text and a form field but that does not contain an explicit for and id relationship is a valid technique for providing an accessible name and is supported by nearly all assistive technology with the exception of Dragon.

Organization Standards

§ 508-1194.22 Web Sites and Applications
- (n) Ensure electronic forms are accessible
Section 508 and 255 (Revised 2017)
- Chapter 3: Functional Performance Criteria
  - 302.2 With Limited Vision
  - 302.1 Without Vision
  - 302.7 With Limited Manipulation
  - 302.8 With Limited Reach and Strength
WCAG 2.0 Level A
- 1.3.1 Information and relationships conveyed through presentation
- 3.3.2 Labels or Instructions
- 4.1.2 Name, Role, Value
WCAG 2.1 Level A
- 1.3.1 Info and Relationships
- 2.5.3 Label in Name
- 4.1.2 Name, Role, Value

Other Mapped Standards

§ 508-1194.21 Software Applications and Operating Systems
- (d) Information about a user interface element must be textually available
- (l) Ensure usability of electronic forms
§ 508-1194.21 VA Testing Checklist - Software Applications and Operating Systems
- (d) Information about a user interface element must be textually available
  - (d.1) Do user interface elements, including custom controls and informative graphics, provide a textual name, description, role, state, and value?
- (l) When electronic forms are used, 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.
  - (l.1) Can all areas of the form be completed, and can the form be submitted, using only the keyboard?
§ 508-1194.22 VA Testing Checklist - Web Sites and Applications
- (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
  - (n.1) Are buttons labeled using a value attribute or other accessibility supported method (e.g. aria-labelledby) that describes the purpose of the button?
  - (n.2) Are form fields explicitly labeled using unique and meaningful labels, title attributes, or other accessibility supported method (e.g. aria-labelledby) that provide important information (such as â€œRequiredâ€ when this information is not provided by another method e.g. the required or aria-required attribute) and the expected input format)?
§ 508-1194.31 Functional performance criteria
- (a) Ensure access for blind and visually impaired
- (b) Ensure access for low vision users
- (f) Ensure users with mobility impairments can use application
47 CFR 14. Advanced Communication Services
- 47 CFR 14.21 Performance Objectives
  - (b) Accessible
    - (b)(1) Input, control, and mechanical functions shall be locatable, identifiable, and operable
      - (b)(1)(i) Operable without vision
    - (b)(2) All information necessary to operate and use the product
      - (b)(2)(i) Availability of visual information
BITV 2.0 (Priority I)
- 1.3.1 Informationen und Beziehungen
- 4.1.2 Name, Rolle, Wert
Baseline Tests for Software & Web Accessibility (v2.0.2 2017)
- 11. Forms (associated instructions)
DHS - Section 508 Compliance Test Process for Application (v 4.0)
- 1.2 Labels for Assistive Technologies
  - 1.2.2. Web: Forms
    - 1.2.2 A. A Web form field has no markup to associate it to its complete instructions and cues
    - 1.2.2 B. If 'Label for' and 'ID' are used but are not valid HTML
HHS HTML 508 Checklist (2019)
- Section J: Sites containing Forms
  - J1 Are all form fields correctly coded with descriptive and accurate labels?
HHS HTML 508 Checklist (Pre 2019)
- HHS Web 508 Checklist (n)
  - (14.1) Does each appropriateÂ inputÂ element or form control have an associated and visibleÂ labelÂ element or titleÂ attribute?
JIS X 8341-3: 2004 - Technical Standards Subpart 5
- 5.3 (b) Ensure form fields are operable and clearly labeled
KWCAG
- 3-3 - Ensure forms are accessible
  - 3-3-1 - Ensure use label on each element for form control
Mobile Web 1.0
- 5.5 User Input
  - 5.5.3 Labels for Form Controls
NFB Certification
- Forms
Telecommunications Act Accessibility Guidelines
- 1193.41 Input, control, and mechanical functions.
  - (a) Operable without vision. Provide at least one mode that does not require user vision.
- 1193.43 Output, display, and control functions.
  - (a) Availability of visual information. Provide visual information through at least one mode in auditory form.
WCAG 1.0 Priority 2
- 12.4 Associate labels explicitly with their controls.
WCAG 2.0 Level A & AA Baseline
- 10. Forms
WCAG 2.1 Level A & AA Baseline
- 10. Forms
WCAG 2.2 Level A
- 1.3.1 Info and Relationships
- 2.5.3 Label in Name
- 4.1.2 Name, Role, Value
WCAG 2.2 Level A & AA Baseline
- 10. Forms

Severity
10 (red)
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
in range of 1 to 10
Noticeability
6 ()
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
in range of 1 to 10
Tractability
2 ()
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
in range of 1 to 10

Provide a valid label for form fields

Compliant Example

Non-Compliant Example

Organization Standards

Other Mapped Standards

Severity

Noticeability

Tractability