Re: HEADERS, FOR whom - any ID?

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