- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Tue, 11 Nov 2003 13:20:42 -0500
- To: <carl.myhill@ps.ge.com>, <w3c-wai-ig@w3.org>, "Jesper Tverskov" <jesper.tverskov@mail.tele.dk>
Hang on a second here... one of the issues here is terminology... as has been pointed out, there is the visual labeling of the form input, and then there is the <label> element. I don't care how much Jacob makes a day as a consultant, the WAI Guidelines (which despite their name *are* defacto standards) are very clear... form inputs should have the <label> element asociated with them. If a developer wants to style away the display of the text output, have a party.... but not adding labelling text *is* against the Standards... > Bobby is also quite well respected and the guidelines from Bobby are very > similar to WAI and 508 so I don't have a whole lot of problems with that > either. I have no expertise in accessiblity so if Bobby tells me to do > something for reasons of accessibility, I will try to comply as best I can > since it usually only changes my design a very little. - Carl Myhill > Carl, I'm not sure where you are getting the "well respected" line from... Bobby is but one of a number of tools available on the market that perform mechanical accessibility checks; Nick Kew's Web Valet is also a great tool, as is AccVerify from HiSoftware, A-Prompt from the University of Toronto, WAVE 3 at WebAIM, etc.. INnsHO, Bobby is an "also ran" (at least in it's erlier incarnation - truthfully I have not looked at where they stand these days); might have been one of the first in the market place, but certainly not the best. At any rate, all of these tools use the WAI Priority 1,2 and 3 and Section 508 Standards as the benchmark(s) to which they measure sites... Bobby should be more than "similar", it should be dead accurate against these Standards... that's the whole point now isn't it? My single largest issue about Bobby is the "Bobby Icon"... all too often that icon "pasted" onto a site has no relevance to the code/site/page being delivered, but hey, it's an icon (remember the days when everybody and his uncle had an icon you could paste onto a site.... "Fred's Site of the Day"). There are so many "useless" Bobby icons out there that they have diluted their worth and validity... heck I can download the icon and paste it on any site, whether I have run the tool or not. Without accountablity and/or another form of adherance reporting, it's just another pretty picture. Finally Carl, slavish adherance to doing anything a tool says without understanding the "why" of it, is also, IMHO, a dangerous place to be. If any checking tool recommends that you do something, find out why... there are loads of people on this list who would be only too happy to expand on a topic, or offer reasoning as to why a certain "recommendation" be implemented. ************ > Here we have a conflict between usability and accessibility. And in this > case usability should win. - Jesper Tverskov Why? How is accessibility different than usability? (Rhetorical question - no answer required...) If I can't access something on a page, how is it "usable"? Jesper, I believe that in all instances that accessibility = usability. And in the case of governmental requirements (and their associated web pages/sites), we as developers do not have the luxury of picking and choosing. Section 508 Standards are not suggestions... they are mandates. So too with the Canadian Common Look and Feel Standards (which mandates conformance to Priority 1 and 2 WAI Guidelines); the same also holds true for other countries and territories around the world. If it's your personal site, you get to decide; if it's a governmental site (we the people <grin>) you do not have the choice. Accessibility must *always* win... > Jakob simply says: if you use a search field it is enough that the button > says Search. You don't need a heading or a paragraph telling users that this > is a Search field. - Jesper Tverskov Hmmm... why not? If I can "see" the button, then it's not a problem... but what if I can't see? No, we don't need an <Hx> element, but we *DO* need to associate form inputs with clearly defined, "understandable" labeling, even if it is not visually rendered on most desktop machines. That's one of the beauties of CSS... > We want a search field, so common on so many pages, to be as simple and > clean as possible. The button with the name Search is more than enough > thank you. > > Some users need more. Their user agents should be able to give them what > is needed by using the word Search in the button. - Jesper Tverskov Jesper, you have argued yourself into a box... yes, some users need more, that's why we as developers must include the <label> element, so that those users, with their adaptive technologies/user agents, can access the required *more*. Once the W3C wrote the standards (OK, guidelines, but that's for another day...), the software developers have a bench mark to develop to... the <label> element. Their task is to deliver/render that element properly, ours is to simply employ it - always. ************ Don't get me wrong, Jacob Neilson often makes some very valuable points, and he is a marquee name, no doubt about it. But sometimes his opinion is based upon his concept and knowledge of usability, and not always based upon the Standards (Guidelines) we here at WAI support. For that reason, I am also occasionally disappointed with Jacob, either because sometimes he doesn't "get it" or because, with his "powerful voice", he sometimes makes poor recommendations. I guess that for me, while I value his *opinion*, I put more faith in *standards*. Just my 4.5 Canadian cents... JF
Received on Tuesday, 11 November 2003 13:20:45 UTC