- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Wed, 21 Jul 2004 22:17:03 +1200
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 is a mailing list for 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 making clicked labels 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 in HTML not because they think
it's good design, but because the HTML spec says they must.
>> 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, and guessed that I would not
need to do so again. In retrospect, that was a silly mistake on my
part.
> 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 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 change to 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="checked" disabled="true"
title="To print all copies of each page before starting on the next
page, uncheck this box. Not applicable 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.
> ...
>> 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 system itself. 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>. 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/
Received on Wednesday, 21 July 2004 03:17:03 UTC