Accessibility with forms, tables, labels and input fields

[Peter Foti]

For accessibility, labels should explicitly map to one input element. But
what to do when a text label pertains to three input fields, for instance
date of birth?

I have an html snippet:

<tr>
<th scope="col">
<label for="dobdd">Date of Birth (dd/mm/yyyy)</label>
</th>
<td>
<input type="text" name="dobdd" id="dobdd" />
<input type="text" name="dobmm" id="dobmm" />
<input type="text" name="dobyyyy" id="dobyyyy" />
</td>
</tr>

Now logically the label maps to all three fields, but the label
specification allows one id in the for attribute. Any suggestions of
clarifying this little oddity?

Perhaps something like this:
<label for="dobdd">Date of Birth (dd/</label><label
for="dobmm">mm/</label><label for="dobyyyy">yyyy)</label>

Regards,
Peter Foti

 

[Isofarro]

For accessibility, labels should explicitly map to one input element. But
what to do when a text label pertains to three input fields, for instance
date of birth?

I have an html snippet:

<tr>
<th scope="col">
<label for="dobdd">Date of Birth (dd/mm/yyyy)</label>
</th>
<td>
<input type="text" name="dobdd" id="dobdd" />
<input type="text" name="dobmm" id="dobmm" />
<input type="text" name="dobyyyy" id="dobyyyy" />
</td>
</tr>

Now logically the label maps to all three fields, but the label
specification allows one id in the for attribute. Any suggestions of
clarifying this little oddity?

 

[Isofarro]

Doh, that _should_ be scope="row" (serves me right for doing it from memory
rather than copy and paste).

Perhaps something like this:
<label for="dobdd">Date of Birth (dd/</label><label
for="dobmm">mm/</label><label for="dobyyyy">yyyy)</label>

Hmmm, I had considered that, and using titles to expand the dd, mm and yyyy
thusly:

Date of birth (
<label for="dobdd" title="Day of Birth">dd</label>/
<label for="dobmm" title="Month of Birth">mm</label>/
<label for="dobyyyy" title="Year of Birth">yyyy</label>)

 

[Nick Kew]

Now logically the label maps to all three fields,

Disagree. It doesn't map to any of them individually.

The structure you described looks to me like a fieldset, and your
label its legend. Within the fieldset, each of the three fields
has a label.

Now, consider the visual rendition of what you described:

<td>
<input type="text" name="dobdd" id="dobdd" />
<input type="text" name="dobmm" id="dobmm" />
<input type="text" name="dobyyyy" id="dobyyyy" />
</td>

Schematically, that's
________ ________ ________
which is no great help to anyone.

In the absence of further cues, that's seriously confusing. An american
will get it wrong if they assume their inside-out date notation. I'd
be inclined to pre-populate those fields with things like "dd" - and
perhaps use an onclick event to clear the preset values for convenience.

Or - ahem - make it a single field.

 

[brucie]

For accessibility, labels should explicitly map to one input element.

just something to think about: do labels really improve accessibility?
very few forms use them, do they cause unexpected behavior, do they
add confusion? is it best to leave them off so the form is just like
all the others out there? is it best to have the form behave like all
the others regardless if its "right" or "wrong"?

 

[Toby A Inkster]

just something to think about: do labels really improve accessibility?
very few forms use them, do they cause unexpected behavior, do they
add confusion?

Labels certainly don't harm any users -- in fact a lot of visual browsers
benefit from them.

<input type="checkbox" name="priv" id="priv">
<label for="id">Tick this box if you don't want us to sell your private
details to spammers.</label>

By clicking on the *text*, a tick will appear in the box. This behaviour
is consistant with non-HTML forms (for example, in application preference
dialogues)

But without the label:

<input type="checkbox" name="priv">
Tick this box if you don't want us to sell your private details to
spammers.

Clicking on the text does nothing.

 

[Toby A Inkster]

<tr>
<th scope="col">
<label for="dobdd">Date of Birth (dd/mm/yyyy)</label>
</th>
<td>
<input type="text" name="dobdd" id="dobdd" />
<input type="text" name="dobmm" id="dobmm" />
<input type="text" name="dobyyyy" id="dobyyyy" />
</td>
</tr>

What about:

<fieldset>
<legend>
Date of Birth
(<label title="Day" for="dobdd">dd</label>/
<label title="Month" for="dobnn">mm</label>/
<label title="Year" for="dobyyyy">yyyy</label>)
</legend>
<input type="text" name="dobdd" id="dobdd" />
<input type="text" name="dobmm" id="dobmm" />
<input type="text" name="dobyyyy" id="dobyyyy" />
</fieldset>

Then use CSS to style as desired.

In addition, it might be wise to follow Nick's suggestion of prefilling
the form values (for an example of prefilled form values, see the search
box on my page [link in sig]).

 

[brucie]

<input type="checkbox" name="priv" id="priv">
<label for="id">Tick this box if you don't want us to sell your private
details to spammers.</label>

By clicking on the *text*, a tick will appear in the box.

i bet you a nudie pic of yourself it doesn't

 

[Isofarro]

Now, consider the visual rendition of what you described:

<td>
<input type="text" name="dobdd" id="dobdd" />
<input type="text" name="dobmm" id="dobmm" />
<input type="text" name="dobyyyy" id="dobyyyy" />
</td>

Schematically, that's
________ ________ ________
which is no great help to anyone.

In the absence of further cues, that's seriously confusing. An american
will get it wrong if they assume their inside-out date notation. I'd
be inclined to pre-populate those fields with things like "dd" - and
perhaps use an onclick event to clear the preset values for convenience.

I'm lucky in a way that the website offers products for the UK only. So
inside out dates shouldn't be a problem. Although prepopulating the fields
with dd mm and yyyy are probably still very useful.

Or - ahem - make it a single field.

That's what I am going to recommend as a better solution. Although the
initial spec did have it as one field, then they split it into three - I'll
check the reasons behind that decision and see if they hold.

 

[Isofarro]

just something to think about: do labels really improve accessibility?

It does open up a useful possibility that within any field a user can call
up a "tell me the label" command in their browser, and out comes the
defined label. Although it seems to be functionally equivalent to reading
out any title attributes on the field. So there is quite a bit of cross
over.

And for simple one label one field forms done in a table, the table markup
will already map label text to their corresponding fields.

very few forms use them, do they cause unexpected behavior, do they
add confusion?

Hmmm... right, I'm assuming the use of labels makes the form easier to
understand. I'll try to check this out with IBM Homepage Reader this
weekend, see if there's any difference.

is it best to leave them off so the form is just like
all the others out there? is it best to have the form behave like all
the others regardless if its "right" or "wrong"?

Accessible forms are better for the user (than inaccesible forms)? Adding in
explicit labels is a Priority 2 issue (checkpoint 10.2 & 12.4). So a page
that's already Level A compliant has removed obstacles that make a document
impossible to access. Priority 2 issues are removing obstacles that make it
very difficult to access a document. So a form _should_ already be
accessible (albeit with difficulty) without labels. Labels should then
reduce the difficulty in using forms.

 

[Toby A Inkster]

i bet you a nudie pic of yourself it doesn't

Damn you! It doesn't! But it might have if I hadn't screwed up the for
attribute!

 

[brucie]

Damn you!

take a number

It doesn't!

you owe me a nudie pic

But it might have if I hadn't screwed up the for attribute!

subconsciously you wanted to send me a nudie pic

 

[Toby A Inkster]

you owe me a nudie pic

We never shook on it!

 

[Isofarro]

We never shook on it!

I think that's more than I really wanted to know.... ;-)