W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2004

[whatwg] LABEL and radio/checkbox onclick

From: Sander <whatwg@juima.org>
Date: Thu, 22 Jul 2004 10:23:34 +0100
Message-ID: <1090488214.40ff87963036c@webmail.kouwenhoven.net>
>> If web authors don't want this to be the case, they should just use
>> text instead of <label>.
> 
> That doesn't produce the desired result if I style <label> (for
> example, label {font-family: sans-serif}), but I don't want labels to
> act weirdly (passing focus in a way that labels in native applications
> do not).
> 
> I could use <label> to label checkboxes and radiobuttons, and <span
> class="label"> to label every other kind of control, to make the labels
> behave properly, and then style both elements, but having to do that to
> work around a bug in the spec would be pretty annoying.
> 
> Therefore, my suggestion stands.

Can I assume your suggestion is solely to make labels non-clickable, rather
than to prevent automatic focus-shifting from labels to non
checkbox/radiobutton controls? The latter would break accessibility on
pretty much all CMSs I've created within the last two years. For l10n
purposes, I always bind the accesskey to the label rather than to the
associated input element itself, pretty much as is shown in this example in
the HTML specs -
http://www.w3.org/TR/html401/interact/forms.html#access-keys - and in fact
seems to be _recommended_ practice: "We recommend that authors include the
access key in label text or wherever the access key is to apply." (Yes, I
realize this could be interpreted in more than one way, but given the
example...)
I don't know how many developers out there will have followed this
recommendation (as after all I didn't know about it either until just now -
I simply arrived at the practice myself), but I imagine enough of them will
that the Web Forms spec requiring this behaviour to be broken would be a
really bad idea, completely regardless of the merits of the usability
argument.

Sander
Received on Thursday, 22 July 2004 02:23:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:35 UTC