- From: Al Gilman <asgilman@iamdigex.net>
- Date: Thu, 31 May 2001 15:12:40 -0400
- To: "Steven McCaffrey" <SMCCAFFR@MAIL.NYSED.GOV>
- Cc: <w3c-wai-ig@w3.org>
[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