[whatwg] LABEL and radio/checkbox onclick

[Matthew Thomas]

On 21 Jul, 2004, at 3:28 AM, Matthew Raymond wrote:
> ...
>    The only thing about it that surprised me was that clicking on the  
> label did anything at all for textboxes and text areas, and that was  
> because I'd never clicked them. I hear a lot about how people will get  
> confused and accidently perform some action that is catastrophic, but  
> I'm not hearing a lot of people saying that actually happened to them.

Firstly, this mailing list is populated by Web geeks. Such people  
understandably have an unusually high tolerance for inconsistency,  
persistently underestimate the harm caused by user mistakes, and  
persistently overestimate the importance of a Web browser relative to  
other applications people use on the same platform.

Secondly, small problems like this are not the sort of thing people  
(other than whiny usability advocates) complain about -- because they  
don't know who to complain to (Web site author? browser developer? OS  
developer? nephew?), and they may not even realize what caused the  
mistake anyway.

> ...
>    Furthermore, all UI was originally never in an OS. You are once  
> again creating a blocking condition that prevents all new UI from  
> being incorporated into a browser before it's a native feature of the  
> OS.

GUIs with hypertext existed 21 years before Web browsers were even  
invented. And if browser vendors were really intending to introduce  
"new UI" by causing clicked labels to focus elements, why don't they do  
that in their preferences/options dialogs, print dialogs, add-bookmark  
dialogs, and so on? They're doing it just in HTML, not because they  
think it's good design, but because the HTML spec says they should.

>> Interface guidelines typically warn against only the most common  
>> mistakes made by developers. Very many wrong things are not expressly  
>> forbidden in the guidelines for a platform, because the platform  
>> vendor assumes that developers will not be stupid enough to try them.  
>> A platform vendor must take that approach, because if it did not, the  
>> guidelines would need to be much larger, more expensive, and harder  
>> to use themselves.
>
>    Hmm, I thought you were actually going to explain what is stupid  
> about label focus passing

It is inconsistent with the native GUI behavior. I had explained that  
three times previously in this thread, using different wording each  
time, and mistakenly guessed that I would not need to do so again.

> rather than just being sarcastic.

No, I was not being sarcastic in the least.

> ...
>    I'm sorry, other than picking apart my trivial choice of the word  
> "look", what was your point?

To respond to your objection. Since UAs try to make their HTML form  
elements look like native ones (even Gecko does that on some  
platforms), it is a mistake to require HTML form element behavior to be  
different from native form element behavior.

> ...
>    The label focus passing on any OS that doesn't support it is a  
> superset behavior. An otherwise functionless piece of UI is given a  
> function. How does that disrupt the user experience in any OS?

By breaking people's mental models of how labels work.

I should admit that while thinking this through, I realized my design  
for a datepicker  
<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/ 
001162.html> is bad for the same reason. It would make existing user  
actions (that are reasonably likely, either deliberately or by  
accident) do something markedly different (opening a menu) from what  
they do with a native datepicker, so it would break people's mental  
model of how datepickers work. It would be better for the  
day/month/year menus to be invoked from an adjacent menubutton (like  
the menubutton that is part of combo boxes), because that would be a  
visually obvious *addition* to the native datepicker, rather than a  
hidden variation in its behavior.

> ...
>>> http://www.w3.org/TR/WAI-USERAGENT/glossary.html#def-ua-ui
>> ... Which refers for "more information" to  
>> <http://www.w3.org/TR/WAI-USERAGENT/conformance.html#content-or-ua>,  
>> which says that "everything that is not content" includes "the user  
>> interface focus". Therefore, the user interface focus should observe  
>> operating environment conventions.
>
>    This is in the context of "user agent features only", and since the  
> feature is defined as part of HTML, it is not a feature specific to  
> the user agent.

<input>, <select>, and <option> are "defined as part of HTML" too. So  
why should a <label> be exempt from conforming to the guidelines, while  
"the control that it passes focus to does have to conform to the  
guidelines listed"?

>> On all widely-used platforms, it is a convention that clicking a  
>> label (other than a checkbox or radiobutton label) does not alter the  
>> user interface focus.
>
>    This is largely because the "label" in most of these UIs is merely  
> a text block. The text isn't next to a control because it is  
> associated with the control at the API level, it's merely placed there  
> by the programmer. The association between the text and the control is  
> all in the user's head.
>
>    Radio buttons and checkboxes are different. In those cases, the  
> "label" is part of the control, and has a direct, preprogrammed  
> association with the control.

If GUI toolkit designers had ever thought it necessary or even  
desirable for the label of a non-checkbox/-radiobutton control to have  
"a direct, preprogrammed association with the control", they could  
easily have done so, just like they did with checkbox/radiobutton  
controls. The various relative layouts of label and control could have  
been specified with one flag, or two at most.

> ...
>>>    My interpretation of the intent of the guidelines on this matter  
>>> are that web authors should be free to specify a behavior in the  
>>> content, but whatever UI is not specifically specified by the web  
>>> author is to be presented according to OS conventions. It would seem  
>>> to me that when using a <label>, you are specifying a behavior at  
>>> some level, or else what's the point of using <label> to associate  
>>> the text with the control?
>> Firstly, to identify the control for accessibility software.
>
>    Isn't that similar to the |title| attribute?

Not really. The title attribute ideally provides help and advice on  
using a control, whereas the label is much more brief. For example,  
<input id="collated" type="checkbox" checked disabled title="To print  
all copies of one page before starting on the next page, uncheck this  
box. Not available because the number of copies is set to 1."><label  
for="collated">Collate pages</label>. You would not want to hear/feel  
the title attributes when trying to navigating through a form quickly.

>> And secondly, as convenient markup so that labels in a form can be  
>> styled consistently.
>
>    That can be done with <span>,

Which isn't as convenient.

> and in many cases labels aren't styled at all.

Which is why (as I said in the part you snipped) UAs should do it by  
default. (By the way, in my CSS I should have said "font: caption", not  
"font-family: caption".)

>> ([...] using <label> for non-checkbox/-radiobutton form controls  
>> still makes consistent author styling easier.)
>
>    This is inconsistent. You want labels for one type of control to  
> behave one way, while for other controls it behaves differently, yet  
> you want the user to have no way of visually distinguishing between  
> these two functionally different label types. To me, that sounds like  
> bad UI.

If there is any bad UI in it, it's that native checkbox and radiobutton  
labels are clickable but don't look like it. My guess is that their  
clickability was added as a quick hack in the early 1980s, once testing  
revealed that the checkboxes and radiobuttons themselves were  
uncomfortably small target areas. The designers should have established  
a different appearance to advertise this different behavior, but they  
didn't. Perhaps they could have used a contiguous groove or ridge  
underlining both the checkmark/dot and the label, with no separate  
border around the checkmark/dot artificially belittling the target  
area.

The next time Microsoft or Apple or Trolltech or Symbian or the GTK+  
developers alter their toolkit's default appearance, that is something  
they could experiment with. In the meantime, for browsers to follow the  
OS behavior people are accustomed to would still be less surprising and  
aggravating than establishing a new behavior with the same appearance.

> ...
>> That was not an example of focus behavior. It was an example of how  
>> UA behavior in general can and should differ between devices.
>
>   No, device UI behavior in specific cases can and sometimes should  
> differ between devices. In general, device behaviors should always  
> retain at least a degree of consistency to that users don't have to  
> learn a new system from the ground up every time they get a new  
> device.

The vendors of speech and braille browsers would, I hope, disagree with  
you.

> ...
>> Simply that if different browsers can have different behavior even on  
>> the same platform, it is unreasonable to expect them to have the same  
>> behavior on different platforms.
>
>    Different browsers don't necessarily support the same standards.  
> Failure of a specific browser to be standards compliant is not  
> necessarily a good reason to change the standard.

Currently, the de-jure HTML standard behavior for <label>s established  
by the W3C conflicts directly with the de-facto GUI standard behavior  
for labels established by Apple and Microsoft. If UAs are to be  
compliant with both standards, one of the standards must change.

The former standard has been used sporadically by developers for 7  
years; the latter has been used heavily by developers for 20 years. The  
former is implemented inconsistently in browsers with noticable market  
share; the latter is implemented consistently in GUIs with noticable  
market share. A uniform change of the former would involve updating  
your browser; a uniform change of the latter would involve updating  
your browser, and almost every other graphical application on your  
computer, and the operating environment itself (which for most people  
means the entire operating system). So it's pretty obvious to me which  
should be changed.

> Furthermore, many browsers do obey HTML specs regarding label focus  
> passing, so are you suggesting that these vendors should have to  
> remove this support in order to be WF2 compliant?

Probably not ("should" rather than "must" would be used for something  
that cannot be changed in Internet Explorer). But that would be moot,  
since browsers would need to follow OS behavior to be WAI-UAAG  
compliant anyway.

>> That's right. <label> should be implemented in Safari. But that  
>> should not require contravening normal behavior for  
>> non-checkbox/-radiobutton labels.
>
>    You advocate the absence of a behavior for non-radio button and  
> non-checkbox controls. Therefore, what behavior are we contravening?

The native behavior of the platform on which the UA runs.

> ...
>    So, effectively, you're combining an unlikely nervous behavior

No, from my years of watching Internet users I'd say it's quite common.

> with the unlikely event that the user will click specifically on a  
> label by accident

No, that and the "unlikely nervous behavior" are one and the same  
event. By artificially dividing it you're making it sound less likely  
than it is.

> while at the same time not being aware of at least one existing OS  
> behavior and one browser behavior.

No, that was just one example (see my reply to Mikko Rantalainen).

> Recall also that labels are "apparently neutral" because that is the  
> default style in many browsers, not because it is in the  
> specification.

Certainly, UAs could visually explain <label>'s non-native focusing  
behavior by making it look clickable -- applying the same default style  
to <label> as they do to <button>, for example. But I think both  
authors and users would find the clutter of that appearance  
considerably more annoying than the annoyance (if any) suffered from  
HTML <label>s having focus behavior consistent with native labels.

-- 
Matthew Thomas
http://mpt.net.nz/