- From: Al Gilman <asgilman@iamdigex.net>
- Date: Wed, 23 Jan 2002 11:25:16 -0500
- To: w3c-wai-ig@w3.org
- Cc: David.Cobb@rnib.org.uk
At 04:28 AM 2002-01-23 , David.Cobb@rnib.org.uk wrote: >Al, > >I must apologize for the value names on the aforementioned example, the >radio button example have now been updated. The radio button example was put >together for the purpose of this mailing list, however, the original search >facility (as tested with users) did work to the extent of using the correct >values, etc... AG:: Thanks for the explanation. I should have found a less tart way of saying that... > >What Liz is saying about not enough space with regards to radio buttons, >this is targeted at the fact that in the future we may want to incorporate >the facility to search other sub-sites as well. Hence, having 3 or 4 radio >buttons in a line could cause problems. > AG:: OK, I understand. She was referring to consuming too much layout space, and I misunderstood her to mean that there wasn't in the logical space enough distinguished places to put the labels. Based on what I know (as summarized before) I think you can safely use the "combo box" form and not bear the layout-space burden of radio buttons. As David Woolley pointed out, a User Agent could still be rendering the SELECT element as an array of radio buttons and be within the letter of the HTML Spec. But most of your users will indeed see the binding that you expect. At 04:28 AM 2002-01-23 , David.Cobb@rnib.org.uk wrote: >Isn't there a problem with surrounding an input field with labels? What >happens when a browser doesn't support labels, does it ignore the input >field? > .. and also At 05:36 PM 2002-01-22 , David Woolley wrote: >> <label for="rad1">Online Shop</label> >> <input type="radio" name="radiobutton" id="rad1" value="radiobutton"> > >Why didn't you use the implicit form: > ><label for="rad1">Online Shop ><input type="radio" name="radiobutton" value="radiobutton"> ></label> > AG:: Faulty browser behavior -- just what happens -- is something someone else will have to comment on. I do seem to recall that when HTML 4 first came out, that IE correctly implemented the explicit association and incorrectly implemented the implicit association and that is why we asked for explicit association in WCAG 1. The first reason why I used explicit association therefore, is habit -- stuck in that pattern having learned it then. As far as other reasons, At 05:36 PM 2002-01-22 , David Woolley wrote: > >The explicit form is only really intended for use where tables separate >the label from the control. In other contexts it just pollutes the >name space and introduces a cut and paste error risk. > AG:: I would be interested in knowing on what one would base the first assertion. Is there a basis in the specification or in accessibility impacts? My memory of the sense of the HTML Working Group at the time HTML 4 was released was that there were residual differences about design philosophy and that only the concrete provisions of the specification could be said to have consensus support. I am not aware that there is any theory along the lines of "is only really intended for use where" that would stand up to the test of evidence. In favor of the explicit-association form is that it can do anything the other can do. It simplifies what the author must learn. There is no need to learn the implicit form, which cannot do everything that one needs to do. The implicit association unnecessarily clutters the training curriculum of the format. Using a few powerful primitive structures and eschewing frills and optimizations is also important for minimizing the demands on assistive technology developers. This is an art we are still learning. I would tend to see a correlation in which the explicit form is closer to what screen readers have found time actually to implement, but this is conjectural. Screen reader apparently will pick out a label without any markup (and usually get it right), because they have to be prepared to do this for applications other than Web. Search out the Jim Thatcher comments on LABEL and form controls in this regard. But the concept of "pollutes the namespace" is intriguing. Can you explain this? Even if there are a few mnemonic tokens among the IDs in a page, there is lots of room within the uniqueToken space of IDs for lots of other symbols that don't interfere at all with the management of the mnemonic few. Al >Regards > >Dave Cobb > >-----Original Message----- >From: Al Gilman [<mailto:asgilman@iamdigex.net%5D>mailto:asgilman@iamdigex.net] >Sent: Tuesday, January 22, 2002 7:35 PM >To: EDixon@rnib.org.uk; w3c-wai-ig@w3.org >Subject: Re: advice sought for design of a search facility for a >sub-site > > >At 11:12 AM 2002-01-22 , EDixon@rnib.org.uk wrote: >>If you have a special area of a site that is distinct from the rest of the >>site for example a sub-site then what is the most usable and accessible way >>to display a search facility and search results that offers a scoped >>search? >> >>Please refer to the following two links for examples of a search facility >>offering a scoped search: >> >><<http://info.rnib.org.uk/script/wai/combo.html>http://info.rnib.org.uk/s cript/wai/combo.html><http://info.rnib.org.uk/scr>http://info.rnib.org.uk/scr >ipt/wai/combo.html >> >><<http://info.rnib.org.uk/script/wai/radio.html>http://info.rnib.org.uk/s cript/wai/radio.html><http://info.rnib.org.uk/scr>http://info.rnib.org.uk/scr >ipt/wai/radio.html >> >>I have carried out an evaluation on both radio buttons searches and combo >>box search with 25 users and have found that the combo box search was shown >>to be easier to use for people with serious sight problems and learning >>difficulties. I have been informed that similar tests have been carried out >>with very different findings therefore any comments would be greatly >>appreciated. >> > >AG:: I don't understand a couple of things. > >But first, thank you for offering side by side code samples to make your >question concrete. I hope lots of people will follow your example. > >I don't understand how you did the user testing given that the radio button >code wouldn't work. The two buttons have to have the same name and >different >values for the user selection to be communicated to the server. > >So, with a few more fiddles, where the code sample says > > > <td align="right"> <b>Search:</b> Online Shop ><input type="radio" name="radiobutton" value="radiobutton"> > RNIB ><input type="radio" name="radiobutton" value="radiobutton"> > >Consider instead it could say > > <td align="right"> <strong>Search:</strong> ><input id="abcd0001" type="radio" name="searchScopeConstraint" >value="storeOnly"> > <label for="abcd0001">Online Shop</label> ><input id="abcd0002" type="radio" name="searchScopeConstraint" >value="wholeRNIBsite"> ><label for="abcd0002">RNIB</label> > > >My impression is that the combo box is on the whole the superior solution. >Historically there was a feature added to Lynx to transform select elements >into series of radio buttons but this was in part because of the low level >of >communication between the curses screen and the DOS screen readers of the >day. >In today's screen reader climate it would appear that is a step backwards >for >most users. > >Contemporary screen readers generally deal effectively with the opening and >closing of the list box also known as select element if I understand >correctly. > >The one thing to be warned about is to avoid using onChange events in the >select element. > >A good model to benchmark your work against is the search interface to the >archives at Google Groups. I am not saying mimic it in all particulars but >if >you start there you will be in close proximity to where you want to wind up. > >I also don't understand the comment about how there is not code space for >enough labels for the radio buttons. See the above example for one possible >coding. > >However, see also Jim Thatchers's reasoning for why he suggests people >ignore >LABEL and just TITLE the elements with what you want to say. > >[apologies for not providing links, it's just a matter of a little time with >Google but I don't have that time right now.] > >Note I put the labels after the buttons as per visual convention. According >to >Thatch's report this is not a problem, and the screen readers read at least >checkboxes that way regardless of the textual order. This point is >currently >an open issue in the development of WCAG 2.0. But the direction of change >is >to allow the visual order and ensure association of label and control via >the >markup. The debate is about how fast or soon to change what the authors are >asked to do. > >Al > >>Thanks >> >>Liz Dixon >>iSys Analyst Evaluator, RNIB >> >> >> >> >>- >> >>NOTICE: The information contained in this email and any attachments is >>confidential and may be legally privileged. If you are not the >>intended recipient you are hereby notified that you must not use, >>disclose, distribute, copy, print or rely on this email's content. If >>you are not the intended recipient, please notify the sender >>immediately and then delete the email and any attachments from your >>system. >> >>RNIB has made strenuous efforts to ensure that emails and any >>attachments generated by its staff are free from viruses. However, it >>cannot accept any responsibility for any viruses which are >>transmitted. We therefore recommend you scan all attachments. >> >>Please note that the statements and views expressed in this email >>and any attachments are those of the author and do not necessarily >>represent those of RNIB. >> >>RNIB Registered Charity Number: 226227 >> >>Website: <<http://www.rnib.org.uk/>http://www.rnib.org.uk/><http://www.rnib.org.uk/> http://www.rnib.org.uk >> > >- > >NOTICE: The information contained in this email and any attachments is >confidential and may be legally privileged. If you are not the >intended recipient you are hereby notified that you must not use, >disclose, distribute, copy, print or rely on this email's content. If >you are not the intended recipient, please notify the sender >immediately and then delete the email and any attachments from your >system. > >RNIB has made strenuous efforts to ensure that emails and any >attachments generated by its staff are free from viruses. However, it >cannot accept any responsibility for any viruses which are >transmitted. We therefore recommend you scan all attachments. > >Please note that the statements and views expressed in this email >and any attachments are those of the author and do not necessarily >represent those of RNIB. > >RNIB Registered Charity Number: 226227 > >Website: <http://www.rnib.org.uk/>http://www.rnib.org.uk >
Received on Wednesday, 23 January 2002 11:25:27 UTC