Re: HEADERS, FOR whom - any ID?

leif said:
>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
>

in JAWS 8, XP, IE7 implicit labelling appears to work unless the label is
not placed where it is expected to be (eg to left for inputs, to right for
checboxes and radio buttons).
 for example:

with no label:

left label <input type="checkbox" value="2"> right label

JAWS announces "right label"

 <label>inside label <input type="checkbox" value="2"></label> outside label

JAWS announces "outside label"

when explicit labelling is used:

<label for="a1">inside label </label><input type="checkbox" value="2"
id="a1"> outside label

JAWS announces "inside label"

this suggests that JAWS ignores the implicit labelling and relys on its own
heauristics to decide what to announce unless the label is explicitly
associated.



On 08/08/07, Leif Halvard Silli <lhs@malform.no> wrote:
>
>
> 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
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org