Re: LABEL in Techniques

to follow up on what nir dagan said:

> > I think this version has been tacitly emphasized because of 
> > what is implemented already in browsers.
> > 
> > Al
> 
> I see. I think that for the long run it is better to 
> show that using LABEL is very simple, if you don't use tables
> for layout. This way you'll get many more accessible forms 
> in the long-run.

Here is one way we could approach this.  The degree of focus, or
selectivity between short term and long term could be different
in the guidelines, the techniques, and the educational materials.
There is decreasing stability, increasing expected rate of
change, in the guidelines, then the techniques, then the training
materials.  Mostly in the last would there be a focus that
emphasizes one timeframe, and that should be short-term.

The guidelines would, in this view, state principles that apply
across short-term and long-term techniques.  The Techniques
document would expose all the techniques, whether short-term or
long-term.  It would not suppress techniques just because they
are effective only now or only then.  The EO materials could
emphasize what can be done in web content with today's browsers
in the field, but would need to be prepared to be rewritten to
emphasize different techniques as the become relevant.

> Instead of telling people: "look, if you don't use TABLEs for layout 
> it is very easy to add LABELs to your forms; just wrap the control 
> and its label with the LABEL tags, but if you insist using tables 
> then you'll also need to write for and id", you're saying: "to write 
> accessible pages you should work around what the WAI's favorite 
> browser does not support."
> 
> Also the method of "place holding characters" in text 
> fields ("type your name here") is not that good as it 
> reduces usability. The user wastes time deleting these 
> characters when filling the form. Now that we have LABEL 
> we can abandon this usability reducing technique.

I am not sure I agree with this usability assessment.  The LABEL
is at risk of being harder to understand than a fully-spelled-out
in-place instruction, and the erase field operation is simple.

But that is not for the techniques document to decide.  It should
err on the side of being inclusive of all techniques that work.

> 
> Regards,
> Nir.
> 
> > 
> > to follow up on what Nir Dagan said:
> > 
> > > Concerning the techniques doc.
> > > 
> > > In 2.12.2 the example uses LABEL with 
> > > for and id attributes where it is possible to 
> > > simplify and include the INPUT as content 
> > > of LABEL and forget about the for and id stuff.
> > > 
> > > Maybe it would be better to give both possibilities 
> > > in examples.

Yes.

> >  2.12.3 it says you should use the for attribute. 
> > > I can't see why. If there is one INPUT in a LABEL, 
> > > as the HTML4.0 spec. requires explicitly,
> > > there is no ambiguity. What's wrong with the HTML4.0 spec.?  
> > > One should use "for" in my opinion, only when it is impossible 
> > > to put the INPUT inside the LABEL (if they are in different table 
> > > cells for example).
> > > 
> > > Also I didn't get the idea behind writing the control 
> > > and its label in the same line when "for" is not used. 
> > > I am unfamiliar with a "line" concept in HTML.

The "line concept" is in how a true screen reader reads the
rendered Browser display, not the HTML entity tree.


> > > 
> > > Nir Dagan                            
> > > Assistant Professor of Economics      
> > > Universidad Pompeu Fabra
> > > Barcelona (Spain)
> > > 
> > > http://www.nirdagan.com
> > > mailto:nir@nirdagan.com
> > > 
> > > "There is nothing quite so practical as a good theory." 
> > > -- A. Einstein
> > > 
> > 
> > 
>

Received on Monday, 9 November 1998 11:09:48 UTC