Re: HEADERS, FOR whom - any ID?

On 2007-08-07 11:51:45 +0200 "Ben 'Cerbera' Millard" <cerbera@projectcerbera.com> 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
> 
> Not only, but also:

Well, it is mark-up's nature to enclose things. ;-) 

One can also make *more* accessible controls if one do so (and one can of course use both FOR= and place the control inside the LABEL - which you have to, if you wan to be compatible). With the LABEL around the control, you can increase the clickable area to both sides of the control. In a left-right script, the text of the LABEL will typically be on the left side of the control - and you will keep the mouse on the right side of the control, to not disturb the reading. If you e.g. use style="display:block;" on the LABEL, then you can click on both sides and also :hover{selectors} will light up the LABEL/control without you disturbing the reading etc.
 
> * 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].

According to WCAG 2 Jaws supports both implicit and explicit LABEL-ing, as does Home Page Reader, while Windows-Eyes did not support it - but could use it to the extent that it was not without purpose. <http://tinyurl.com/yqpq6z>

To your second reference, that page says that, «When the prompt and the input element are required **for design purposes** [my stressing] to be separated (by table cells, for example), then the label element with the for attribute must be used.» Later on it says that we should rely on FOR=, because putting the INPUT inside LABEL is not dependable. However, he also says that placing the LABEL around the INPUT is the natural idea (my phrasing) because a) that _should_ work (and does many times), and b) because that also fulfils another of his requirements, namely that the LABEL-text should be as close to the control as possible. I will also remind you that WCAG 1 recommends implicit labeling/placing the text near the INPUT «Until user agents support explicit associations», which I think we should read as an advice to fall for the temptation of separating LABEL and control, until all screen readers understands the FOR= attribute (<http://tinyurl.com/ywj936>). (Which, again, must mean that WCAG1  do/did not agree with your second reference in that even FOR is allways safe.) He does not mention the option that he can use both containership and FOR= at the same time - but it follows that this should be safest thing of all.

We must consider that this subject is probably heavily affected by the epoch of TABLE layout designs: Creating FORMs without the use of TABLE was long considered impossible. The «design purposes» were usually not «design purposes», but simply workarounds or adaption to the TABLE based page designs. Yeah, even if your first reference (from WHATwg blog) contains complains that LEGEND is difficult to style etc (and a proposal to make LEGEND optional).

Neither HEADERS= nor FOR= should be an excuse for making «free form» designs.

> * Internet Explorer 6 and below does not support implict labelling [3]. The 
> <label> does not become clickable.

Can someone verify that IE 7 does support it? When I tested, I did not get it to work.

> * Clickable labels increase the clickable area of controls. This is a 
> usability aid to all users of pointing devices (Fitt's Law [4]).

And if contained within the LABEL you can increase it even more.

> * 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].

Here you points us to a TABLE-based form, without any LABELs at all. No wonder it doesn't work.

> 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.

It's the same as HEADERS= used on every cell: It is/can be a necessary for compatibility. But to use FOR= as argument for not enclosing control inside LABEL is something I cannot support.

> [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>
-- 
leif halvard silli

Received on Tuesday, 7 August 2007 23:44:56 UTC