[whatwg] Form Control Group Labels

[Ian Hickson]

On Tue, 13 Mar 2007, Elliotte Harold wrote:
>
> Currently in HTML 4, and apparently in Web Forms 2, there is a rule that 
> each label element applies to exactly one input field. 10 inputs, at 
> least 10 labels.
> 
> However looking at a number of tabular but not exactly repeating forms, 
> both on the Web and on paper, I notice that it common for the column 
> headers to essentially serve as label for the input fields. For example
> 
>             Homework 1  Homework 2 Homework 3
> John Smith    87           86         98
> Jane Jones   100           78         98
> Fred Wilde    89           65         69
> 
> What strikes me about examples like this is that the labels for the 
> input fields naturally apply to more than one input field. For example, 
> in the above each label covers three fields. I wonder if there's a 
> common use case to say something like
> 
> <label for="A1 A2 A3">Homework 1</label>
> <label for="B1 B2 B3">Homework 2</label>
> <label for="C1 C2 C3">Homework 3</label>
> 
> Currently this is not possible. The label's for attribute can only point 
> to one input element.

This seems to be a case where the <th> should be enough, no?


On Tue, 13 Mar 2007, Simon Pieters wrote:
> 
> We could just say that if a form control is in a table data cell, and 
> doesn't have a <label> associated with it, then the cell's header cells 
> are labels for the form control.

Do we need to explicitly say that, even?


On Tue, 13 Mar 2007, Robert Brodrecht wrote:
>
> I think the main problem with multiple IDs for labels is the usability. 
> How would it work and still make sense?

Indeed.


On Tue, 13 Mar 2007, Elliotte Harold wrote:
> 
> Pretty much like it does now I suspect. When presenting the form control 
> to a user, the software would assign it the label. It would just use the 
> same label more than once.
> 
> The for attribute is not new. What's being proposed is simply allowing 
> it to identify multiple controls rather than just one.

The problem is when you select the label, which control does it apply to? 
On some systems, we have to focus a control when that happens.


On Tue, 13 Mar 2007, Jeff Cutsinger wrote:
> 
> I'll second this. Given that the table is marked up correctly (that is, 
> using th and |scope| or equivalents), it should be usable for a blind 
> person without the labels. And the question is: what's the benefit of 
> having labels with multiple controls? When a label is associated with a 
> control it currently allows you to click the label to focus the control- 
> this is obviously absurd with multiple controls per label. I'd probably 
> just mark them up as labels without any |for|.

Agreed.


On Tue, 28 Oct 2008, Markus Ernst wrote:
> Ian Hickson schrieb:
> > On Tue, 31 Oct 2006, Lachlan Hunt wrote:
> > > There are workarounds using fieldset and legend for the question, like
> > > this.
> > > 
> > > <fieldset>
> > >   <legend>Gender:</legend>
> > >   <label for="m"><input type="radio" id="m" name="gender" value="m">
> > >     Male</label>
> > >   <label for="f"><input type="radio" id="f" name="gender" value="f">
> > >     Female</label>
> > > </fieldset>
> > 
> > That's not a workaround. It's exactly what you're supposed to do. 
> > <fieldset> lets you group a set of controls with a common legend, 
> > which is exactly the problem you described.
> 
> IMO Lachlans opinion about the fieldset solution being a workaround 
> reflects a basic problem with those form elements: they are highly 
> presentational. Your example:
> 
> <fieldset>
>   <legend>Gender:</legend>
>   <label for="m"><input type="radio" id="m" name="gender" value="m">
>     Male</label>
>   <label for="f"><input type="radio" id="f" name="gender" value="f">
>     Female</label>
> </fieldset>
> 
> serves the same purpose as this one:
> 
> <label for="gender">Gender:</label>
> <select id="gender" name="gender">
>   <option value=""> </option>
>   <option value="m">Male</option>
>   <option value="f">Female</option>
> </select>
> 
> Both provide a list of values, of which zero or one can be selected. The 
> only real difference is in the presentation, but structurally they are 
> totally different.

Right; indeed Web Forms 2 actually called this out explicitly.


> Now consider this:
> 
> <fieldset>
>   <legend>Sender:</legend>
>   <label for="n"><input type="text" id="n" name="n" value="">
>     Name</label>
>   <label for="m"><input type="text" id="m" name="m" value="">
>     E-mail</label>
> </fieldset>
> 
> This is structurally the same as the radio button example, except some 
> attribute values, but serves a totally different purpose. If you look at 
> it this way, calling the fieldset solution for grouping a group of radio 
> buttons (which are actually grouped by their common name attribute 
> value) a workaround does not seem totally wrong to me.

Why not? This seems like the exact same thing to me. It's a "compound 
control" for a "Sender" consisting of a name and e-mail address. The AT 
behavior seems correct in both cases.


> I consider a total re-thinking of select, input type="checkbox" and 
> input type="radio" elements as highly desirable, though I see that this 
> might cause more serious backwards compatiblity problems than for 
> example removing the font tag. One possible solution could be using the 
> select tag with a type attribute:
> 
> <label for="gender">Gender:</label>
> <select id="gender" name="gender" type="boxgroup">
>   <option value=""> </option>
>   <option value="m">Male</option>
>   <option value="f">Female</option>
> </select>

I don't understand what problem you are trying to solve here.


On Tue, 28 Oct 2008, Tab Atkins Jr. wrote:
> 
> I haven't given it serious thought, but as far as I can tell his 
> proposed solution (piling all four display types onto the <select> tag) 
> would work wonderfully as a semantic consolidation/simplification, and 
> be nicely backwards-compatible.  There are still good reasons to support 
> keeping the <input> types of radio and checkboxes, of course (frex, 
> wrapping a form around a list, and putting an <input> within each <li>), 
> but this proposal would simplify the most common case.

I don't see what problem this solves. What's wrong with what we have now?


On Tue, 28 Oct 2008, Thomas Broyer wrote:
> 
> Wouldn't aria-labelledby [1] be better-suited? (if and once ARIA is 
> added to HTML5)

ARIA is intended to be a patch for applying accessibility API bindings to 
content that couldn't use proper semantics, much like how style="" is 
intended to apply CSS rendering bindings to content for which proper 
semantics and a separate selector-based style sheet doesn't work.

ARIA is, in the most literal sense, only accessible to people who use 
accessibility tools. We want HTML authors to be able to write markup that 
is usable by everyone.

So ARIA is never an appropriate solution, it's only ever a workaround for 
when we haven't yet provided a real solution.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'