- From: Robert Burns <rob@robburns.com>
- Date: Tue, 7 Aug 2007 14:27:01 -0500
- To: Ben 'Cerbera' Millard <cerbera@projectcerbera.com>
- Cc: "HTMLWG" <public-html@w3.org>
On Aug 7, 2007, at 4:51 AM, Ben 'Cerbera' Millard wrote: > > Robert Burns wrote: >> That is I can't imagine any reason to not place an INPUT inside a >> LABEL > > Having a control in content of it's own label is illogical, imho. > The label ends up being the thing it is a label for as well as the > text which labels it. :-P I'm not sure I understand what you're saying there. I did say I though the XForms approach mad more sense (placing |label| inside | input| for instance). Also, since everything inside the LABEL element is the label (except for he one INPUT or whatever control) it should unambiguously mean the same thing as the XForms approach. In other words an algorithm can be specified that says: extract everything from the LABEL except for the controls and consider that the label. Now present that visually according to the CSS property: "label-side" or whatever it would be called. This is an explicit and not an implicit association. To me it is a stronger explicit association than for=IDREF (or at least as strong anyway). This is not the same thing as implicitly determining a quotation must be related to a citation in the same paragraph because they share the same parent and they're near each other. This is an explicit association in the sense that nothing else inside the label is anything but a label (except for the control itself or controls themselves). Understand that I'm not arguing for removing the @for attribute, I was joining in a discussion that was focussed on forward looking approaches to make better sense of this in the future. To me that involves the explicit step of placing the label inside the control element or placing the control element inside the label element. That explicit association also mirrors the presentation where a label should be nearby (in whatever sense, logically, visually, aurally, tactiley) its control. The @for=IDREF approach allows this proximity to be broken (for flexibility) when I do not think there's much reason for that (I could imagine a reason for localication/ internationalization, but using @for and an IDREF doesn't really help with that; something like that would require XInclude or some other inclusion mechanism). > Not only, but also: > > * The most recent version of 3 popular screen readers (sadly not > named, but probably JAWS, Home Page Reader and either Window-Eyes > or HAL) did not support implicit label association at the times of > testing [1][2]. > * The for+id method (explicit association) is reported to work fine > in [2]. > * Internet Explorer 6 and below does not support implict labelling > [3]. The <label> does not become clickable. > * Clickable labels increase the clickable area of controls. This is > a usability aid to all users of pointing devices (Fitt's Law [4]). > * The significance of the clickable area will likely increases as > the accuracy of the user decreases. So a pointer user with a motor > disability [5] is helped to a greater degree by clickable labels. > * Expecting screen readers to associate text with controls merely > by proximity, without <label> markup for either implied or explicit > association, is reported as being unsuccessful [6]. > > I can ask around [7] for better references and more up-to-date > testing, if necessary. And you can search for them yourself, of > course. > > In the accessibility communities I visit, for+id is considered a > must-have feature for its compatibility with current devices and > the usability benefits it provides to such a wide range of users. > > [1] <http://blog.whatwg.org/?p=31#comment-3727> > [2] <http://www.jimthatcher.com/webcourse8.htm#wc8.3.2> (Find in > page: "For screen reader users".) > [3] <http://www.trovster.com/form-label.php#browser-support> > [4] <http://en.wikipedia.org/wiki/Fitts'_law> > [5] <http://www.webaim.org/articles/motor/motordisabilities.php> > [6] <http://www.visionaustralia.org.au/info.aspx?page=765> > [7] <http://www.accessifyforum.com/> As I said, I support the inclusion of @for for backwards compatibility reasons. The thread, as I understood it, was about forward looking approaches that were mostly designed to fix a presentation and not a semantic issue. This to me point to a deficiency in the presentation mechanism (such as CSS) and not in the semantic language such as HTML (just applying our separation of concerns design principle here). If the presentation was handled suitably, I cannot think of any need to not simply enclose a control inside a label or enclose the label inside the control. Take care, Rob
Received on Tuesday, 7 August 2007 19:27:16 UTC