Re: 10.4 Re: Checkpoints 10.4 and 10.5

[for new stuff skip to AG:: below]

At 02:24 PM 2001-05-31 -0400, Steven McCaffrey wrote:
>Hello Al:
>
>     Yes, I agree completely.  My screen reader and browser are fixed, so
this
is why I emphasized that I did not want to generalize.  For my versions of
screen reader and browser, it appears the label in the example I gave works. 
As for other screen readers I can't say.
>Even for other codings of the form, I can't say.  I never know what is a safe
>generalization.  
>
>
>An examnple that doesn't work for me
>is on the wired article page from a previous message
>(JFW 3.31 IE 5.0)
>
><http://www.wired.com/news/politics/0,1283,44062,00.html>http://www.wired.
com/news/politics/0,1283,44062,00.html>
>I hear (skipping some links)
>"Slash news slash image map link" then I tab and hear 
>"Edit"
>then I tab and hear
>"Combo box"
>then I tab and hear
>"Go button"
>
>If I hit enter on the Combo box to go into forms mode,
>then I hear
>"Look for combo box Wired news"
>(a pull down list)
>
>I think the "Look for" is supposed to be associated with the edit field and
not the Combo box, right?

AG:: Yes and no.  With the edit box, yes.  With the combo box, sorta.  Not
really "not with the combo box."  

[Warning: from here on I am going to call it a "list box" so as to save "combo
box" for something where you have more than one way to make the selection.
The
form composed of both edit field and list box is closer to a "combo box" in my
estimation.  And is also what "look for" is talking about, in the end.]  

Yes, this page would be understandable if they marked the "Look for" as a
LABEL
and said that the LABEL was FOR the edit field.  The list box pretty much
works
as self-explanatory.  The edit field absolutely requires some clue as to what
you are supposed to fill in.

On the other hand, the "Go" button following after the edit field and the list
box is really the bottom line, and "look for" actually makes sense as applied
to both the edit field and the list box.  The user wants to go to slash look
for some kind of information.  If they find a topic in the list box that is
what they want to look for, they go there.  If they don't find a topic that
fits their question, they just say what they are looking for and they go to a
search results page.  The "look for" legend fits in either case.  The
design of
this feature, at least in terms of how the designer optimizes it for the
visual
user, is ambiguous in terms of what the "look for" applies to.  It is
logically
more like a LEGEND on a FIELDSET but one can't use FIELDSET for grouping and a
TABLE for layout at the same time.  Note that this combination of topic list
plus text search as a navigation utility is common, a best current practice. 
Compare this one with the SEARCH tool prominently offered at the start of the
Amazon home page.

Reference:
Go to <<http://www.amazon.com/>http://www.amazon.com/> and text-search for
"search".

The immediate remedy in terms of today's technology is to make "look for" a
LABEL element pointing to the edit field.  End of short term story.

Over the long haul, it would be nice if it were actually possible to express
the branching logic here, which is 

Look for 
 either
  - one of our subtopics [indicate with list box], 
 or else
  - you tell us what [indicate in edit box].
and go.

[Note the order reversal.  I think the if-then-else structure is easier to
understand read aloud when laid out in the reverse order as compared with the
Wired News visual layout.  Amazon happens to have the fields in the other
order.  Visual users 'always' see both before the elect to use either one.]

Al

>This had me confused for some time.
>I'll try to find an example of what works.
>
>
>Steve
>
>
>
>
>>>> Al Gilman <asgilman@iamdigex.net> 05/31/01 12:29PM >>>
>
>
>Both good news and bad news are informative.  It would help to have
>examples of
>what works and also of what doesn't work.  You and David seem to believe that
>we still need explanatory text, or at least some text, in the edit boxes for
>best practice at the moment.  This is an "until user agents" provision in the
>WCAG.  So for objectivity and consensus, it helps to know what the actual
user
>agents do with actual pages.  
>
>To sell this to web authors as the general rule of what to do, it helps to
>have
>chapter and verse documentation explaining in what situations alternatives
>don't work.  Target page, OS, Browser, Screen reader with versions.  It
helps.
>
>Al
>
>At 11:15 AM 2001-05-31 -0400, you wrote:
>>Hello Charles:
>>
>>     Good question.  I don't want to generalize, so let me just give an
>example that does work.  The example in section 11.2 of the 
>>HTML Techniques for Web Content Accessibility Guidelines 1.0 works fine.  I
>hear
>>"First name colon edit"
>>then I hit tab and hear:
>>"Last name colon edit"
>>which is fine.
>>The snipet for the first name is:
>>
>>   <LABEL for="firstname">First name: </LABEL>
>>   <INPUT type="text" id="firstname" tabindex="1">
>>
>>Note my comments above are not about grouping form controls which is the
main
>point of 11.2.  I am just commenting on the label element.
>>
>>
>>Steve
>>
>>
>>>>> Charles McCathieNevile <charles@w3.org> 05/31/01 09:50AM >>>
>>If they have labels (using the label element) does this improve things?
>>
>>Charles McCN
>>
>>On Thu, 31 May 2001, Steven McCaffrey wrote:
>>
>>  Hi Charles:
>>
>>
>>       I'm using JFW 3.31.  I will just hear "edit".
>>
>>  Steve
>>
>>  >>> Charles McCathieNevile <charles@w3.org> 05/31/01 08:43AM >>>
>>  Thanks Steven, Dave.
>>
>>  Can you please explain what software you're using, and what happens?
>>
>>  cheers
>>
>>  Chaals
>>
>>  On Thu, 31 May 2001, Steven McCaffrey wrote:
>>    Hello:
>>         I agree with David in that it is still an issue.  The
consequence is
>>    that I will hear only "Edit" but will not know what type of
>information is
>requested.
>>
>>    Steve McCaffrey
>>    Information Technology Services
>>    NYSED
>>    >>> "David Poehlman" <poehlman1@home.com> 05/31/01 07:49AM >>>
>>    it is still an issue although many have solved it.  even though you have
>>    to rub the text out, it is best to have something telling you where to
>>    write because some renderings still confuse labels with edit boxes.
>>
>>    ----- Original Message -----
>>  ...
>>
>>    the rationale for this one was that there were assistive technology and
>>    browser combinations that would skip over empty form controls. I am not
>>    certain, but I believe that this is no longer an issue. I will ask the
>>    Web Content Accessibility Guidelines group to address this question as
>>    fast as possible.
>>
>>
>>
>>-- 
>>Charles McCathieNevile   
><<http://www.w3.org/People/Charles>http://www.w3.org/People/Charles><http:
//www.w3.org/People/Charles>http://www.w3.org/People/Charles  phone: +61
>409 134 136
>>W3C Web Accessibility Initiative    
><<http://www.w3.org/WAI>http://www.w3.org/WAI><http://www.w3.org/WAI%A0%A0
%A0>http://www.w3.org/WAI    fax: +1 617 258 5999
>>Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
>>(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex,
>France)
>>  
>  

Received on Thursday, 31 May 2001 15:11:55 UTC