W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2003

Ouch!!! (was: RE: Nielsen's Latest Alertbox & a personal protest)

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>
Message-ID: <GKEFJJEKDDIMBHJOGLENOEHHEHAA.foliot@wats.ca>


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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:13 GMT