Some more thoughts re 3.3. etc.

A couple of ideas that were mentioned during the call, but perhaps not
adequately explored:
1) content/presentation
    A major theme of our work has been "separate content from presentation"
, it would perhaps be more accurate to say - When presentation has meaning,
so indicate. (the difference between <font size="larger"><b> and <h1> or <..
alt="go"> and < .. alt="">) The Guidelines/checkpoints then for the most
part focus on alternate/multiple means of presentation (aside: two
guidelines begin with the words DESIGN CONTENT ???).  In 3.3 we step over
that line and tell people what to do with content.
If we consider the web as if it were a large library*, even if all of the
materials in that library were available in alternate formats (Braille,
Audio, Transcripts) there would still be things I couldn't use (a book on
quantum computing, an illustrated guide to bird watching, ...)  If I am
lucky there may be something on Bird Song identification but I don't think
the author of the illustrated guide is in any way obligated to produce one.
If there was a standard picture vocabulary I can see requiring
<pict="magnifying glass"> where an end user can choose to see the  'picture
view' of things.  However, saying that I must use the word 'search' since it
is the most clear and simple and not [beat, comb, finecomb, fine-tooth-comb,
forage, grub, rake, ransack, rummage] (Hmmm, want to rummage through my
website?) seems to be going too far.  Exteam? Maybe, but it does seem to be
the way we are heading.

*A place in which literary and artistic materials, such as books,
periodicals, newspapers, pamphlets, prints, records, and tapes, are kept for
reading, reference, or lending.

2) Tools vs. Disabilities
     Ramps are not designed for paraplegics, quadrplegics, .....; they are
designed for wheelchairs (they work for a lot of other things too, but
that's another story).  Much of our work is really targeted at the tool, not
the disability.  A screen reader may be used by someone who is blind,
someone who is Low Vision and finds it easier than magnification techniques,
someone who is "print disabled" and finds the sound reenforcement useful,
someone using their eyes for other things at the time (driving a car?), and
probably lots more I haven't thought of.  The requirement for <... alt="go">
is targeted at the limitation of the screen reader, not the individual using
it.   If we had a screen 'pictifier' then the checkpoints needed to make it
function in a useful way would be relatively easy to write.
On Pictifying: The pictified version of a webpage might make perfect to
sense to some and be incomprehensible to others. Anybody remember a game
show where a common phrase was pictified and the object was to guess the
phrase? A picture of a man on a horse with a shield and sword might
represent the word night, or night could be represented by a cresent moon
and star. These are two very different ways of tackling the problem.  Asking
web authors, who may well belong to that class of people who find this type
of presentation incomprehensible, to provide this kind of illustration
really seems to be asking too much.  Maybe this requirement belongs first in
the User Agent Group?

Just my $.02
Marti

Received on Friday, 30 March 2001 06:34:42 UTC