WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: for and id in label and input

for

From: Birkir R. Gunnarsson
Date: Aug 12, 2016 11:48AM

There are a couple of angles to this.
Every form needs:
- a visible label (WCAG SC 3.3.2) and
- an accessible name (WCAG SC 4.1.2)
There are 3 ways you can satisfy both of these conditions:
1. Using html labeling techniques (that come in 2 flavors):
Explicit labeling (where the for attribute of the label matches the ID
of the input field):
<label for="inp1">Your name</label>
<input type="text" id="inp1">
or implicit labeling (where the label tag is wrapped around the input
field and the label text:
<label> <Input type="text"> your pet's name</label>
HTML labeling tecchniques are best, because they are most widely
supported and most browser move focus to the input field when user
clicks the label (making the click target larger, and that is good for
users with fine motor control problems).

2. Using inverse labeling relationship through aria-labelledby:
You give the label element an ID and associate the input to that ID
using aria-labelledby:
<label id="lbl1">Your favorite vacation spot?</label>
<input aria-labelledby="lbl1" type="text">

This is supported on most modern browsers and a.t. combinations, and
does not require duplicating text, but it does not allow for the
enlarged click target unless you use Javascript.

3. Providing a visible label close to the form field and duplicating
its text in the title or aria-label attributes of the field.
<label>Who's yo momma?</label>
<input type="text" title="Who's yo momma?">
or
<input type="text" aria-label="Who's yo momma?">
This technically works, but causes extra verbosity for screen reader
users, does not allow the enlarge click target and is just sloppy
code.
Also, if when updating the visible label people often forget to update
the invisible label, getting them out of sync.

A title or aria-label attribute alone satisfies 4.1.2 but not 3.3.2
because they are not always visible.

There are exceptions, such as when there is a group label for multiple
fields (like phone number or social security number). Then title or
aria-label is enough to provide accessible name to individual input
fields in that group, but a visible label for those fields is not
required (as long as the label for teh group is visibly close).

And, finally, a visible label located close to the input field without
html or ARIA associations or duplication with title or aria-label
passes 3.3.2 but fails 4.1.2:

e.g.:
<label>Who's yo daddy?</label>
<input type="text">
ditto if you match the for attribute of the label tag with the name
attribute on the input field (I still see this occasionally). This is
only ok if the input field also has an id attribute with same value
<label for="n1">what is going on here</label>
<input name="n1" type="text">
(bad)
<input name="n1" id="n1" type="text">
(good)

Hey, who said accessibility was simple?
-B

On 8/12/16, Trafford, Logan < <EMAIL REMOVED> > wrote:
> The following is copied from achecker's documentation (input type of text).
> Step 3 indicates that achecker is making the correct association.
>
> Steps To Check
>
> Procedure
> 1. Check all input elements that have a type attribute value of "text".
> 2. The input element must have an explicitly associated label using one or
> more of the following methods.
> 3. The input element has an id attribute value that matches the for
> attribute value of a label element.
> 4. and/or
> 5. The input element has a title attribute.
> 6. and/or
> 7. The input element is contained by a label element.
> 8. Check if the label text describes the purpose or function of the
> control.
>
>