aloha, jonathan!
you wrote, quote
your making me a little cross.You are using your preconceptions about
ordering to define a requirement you know nothing about.
unquote
what exactly is it that i know nothing about? my blindness is due to a
protracted meningeal encephalitis that caused damage to my optic nerve, to
my occipital lobe, and to the transfer point between hemispheres... as a
result, i, too, often experience cognitive difficulties -- sometimes quite
severe ones (especially during the frequent migraine episodes to which i am
prone as a result of the neurological damage i sustained as the result of
multiple viral infections... so, i have had an abundance of unwelcome
personal experience with disorders such as agraphia (a technical term for
thinking one thing and writing another), periodic bouts of alexia (an
inability to properly comprehend words -- or, more precisely, the structure
of language as it is spoken or read), and even, at times, slight aphasia...
so, please elaborate about my supposed preconceptions...
you also wrote, quote
Links by their nature are not predictable.
That is in part the nature of story telling .
unquote
that links are unpredictable is the fault of page authors... if the links
on the page that anne referred us to had linked to transcripts of the
songs, coupled with links that clearly indicated that one was about to load
a sound file, its format, and its playing time, how would that be
detrimental? as for the how, what would be wrong with encoding the link to
the sound clip thus:
<!-- begin snippet of HTML code -->
<a href="washing.wav"
title="Song About Washington: 2.8MB WAV file; playing time 57 seconds"
><img src="washgtn2.gif" border="0" width="65" height="78"
alt="Portrait of George Washington">Song About George Washington
(2MB WAV file; time: 57 seconds)</a>
<!-- end snippet of HTML code -->
and embedding it at the top of a transcript of the song? then i, you, and
everyone else would know:
a) the type of file being referenced
b) the format of the file being referenced
c) the size of the file being referenced, and
d) the duration (playing time) of the file being referenced
is this so unreasonable? and if so, why? not knowing what happens next
may be quote part of the story unquote, but we're not talking about
skipping to the end of the book to find out who done it, but, rather,
providing the visitor with sufficient information so that he or she can
make an informed decision _before_ following the link... there are a host
of reasons why such information is important -- whether or not the file
format is usable by the visitor, whether the visitor's system can handle
the file format, the amount of time the sound clip plays, and the size of
the file (an important consideration for those for whom accessing the
internet is much like getting into a cab -- the more time you spend online,
the more it costs) -- to name but a few...
the point is that navigation without orientation is not only meaningless,
it can be quite disastrous...
and, if mystery is part of quote the nature of story telling unquote, why
bother using hyperlink text or a clickable image at all? why not use an
anagram or rebus as the hyperlink text or image just to preserve the sense
of mystery?
you also stated, quote
To demand that links should go to sound via text is self evidently
ridiculous for a non-readers. You can work this much out on the fly.
unquote
self-evident? how? and what exactly do you mean by the term quote
non-readers unquote?
you also wrote, quote
I don't mean to be rude, I get driven to it.your thinking is all too
evidently that of a technician rather than a carer. Try coding from the
perspective of a non reader, and you'll realize that LYNX is not a product
they are likely to use. In fact if they are browsing unaided its almost
certain they must be using 5 or later else its not got enough multimedia to
entertain.
unquote
i suppose that i should be flattered to be called a technician, as i have
no formal training in technical matters of any kind whatsoever... by
training, i am a medievalist; by happenstance, i am someone who -- at the
age of 20 -- found himself functionally illiterate, due to the loss of my
sense of sight and the loss of sensitivity in my fingertips, which
precludes me from reading braille... i have taught myself quite a bit
about technology (enough to get gigs as a webmaster and as a system
administrator, as well as an invitation to participate in the Protocols &
Formats working group as an invited expert), and have benefited from the
advice, expertise, and patience of those far more knowledgeable than i, but
i am by no means a technician...
as for my not being a quote carer unquote, i'm not sure what to make of
that assertion... why would i devote over 30 unpaid hours a week
participating in WAI related work (participating in teleconferences,
participating in list discussions, monitoring developing activities and
working drafts, mocking up templates and test suites, reviewing and
contributing to working drafts and techniques documents, analyzing sites,
etc.) if i didn't care?
besides, jonathan, i'm not approaching accessibility from a theoretical
point of view, nor looking down on the unwashed masses from high atop an
ivory tower, but from a very practical and personal point of view... my
only philosophical tenet with regards web accessibility is a firm belief in
universal design and client-side transformations, which is the only type of
technology that i can envision (a) satisfying the needs of individuals on
an individual basis, and (b) keep the web from splintering into innumerable
mutually exclusive cyberghettoes...
yes, i know that a quote non reader unquote is not likely to use Lynx, but
if the visitor to the page anne referenced happens to be deaf, blind, and
has a cognitive disability, is it not possible that he or she might be
using Lynx, in conjunction with a refreshable braille display?
besides, the point of referring to Lynx was a means of illustrating the
shortcomings of coding for an exclusively visual rendering, without first
investigating the potential impact of the code being used... this is often
a by-product of using an authoring tool which allows one to visually slash
physically manipulate objects on a document, but which uses malformed,
illogically formed, and often invalidly formed code to produce the desired
visual effect... i'm not opposed to visual presentation -- as someone
who's interaction with a computer before becoming blind was limited to
using a point-and-click desktop publishing program on a mac, i know the
importance both of visual presentation and of a tool that allows one to
construct a document by visually and physically manipulating objects, but
as someone who has been blind for nearly a dozen years, i also know its
inherent limitations... there are techniques and methods that can be
employed to provide structure within a TABLE used for layout, which will
both preserve the intended visual rendering, as well as linearize
gracefully, and it is the intent of the Authoring Tool Guidelines to ensure
that, when a page is created using a WYSIWYG tool that, when tables are
being used for layout, those methods and techniques will be employed behind
the scenes by the tool... that i chose Lynx as my example is due to the
fact that there are several Lynx-simulators available on the web that can
assist authors in ensuring that their pages work equally well with TABLE
support and without TABLE support...
i also don't understand the point of your conclusion,
quote:
OK we'd like our product to suit all needs, but there's precious little
suitable content about, and the great need is for product, cross
compatibility is not an issue.
unquote
please elaborate... why is cross-compatibility quote not an issue
unquote? what constitutes suitable content? and what exactly do you mean
by product?
the entire point of my post to anne was that we shouldn't pit the needs of
one group against the other, but should attempt to find ways of expressing
information that works for all users... and, in practical terms, that
translates into:
(a) a lot of education and outreach,
(b) a lot of testing to ensure that a fix that addresses one group's needs
doesn't adversely affect another's
(c) putting pressure on authors to _think_ before they implement and to
test _after_ they implement
(d) putting pressure on the manufacturers of authoring tools in order to
ensure that they strive to comply with the Authoring Tool Accessibility
Guidelines (and the news from the AU WG on that front is, indeed, encouraging)
(e) putting pressure on browser manufacturers to:
(e1) support the accessibility features of the markup languages supported
by their products
(e2) incorporate client-side stylesheet-building wizard mechanisms into
their browsers, and
(f) exerting pressure on adaptive technology manufacturers to track W3C
activities more closely, so that users can actually benefit from the
accessibility features and cascade and switching mechanisms being built
into markup languages
signed, gregory, who is not at all cross with jonathan, merely confused by
his arguments, and who seeks elaboration
At 05:05 PM 3/15/00 +0000, Jonathan Chetwynd wrote:
>Gregory
>
>your making me a little cross.
>You are using your preconceptions about ordering to define a requirement you
>know nothing about.
>
>Links by their nature are not predictable.
>That is in part the nature of story telling .
>
>To demand that links should go to sound via text is self evidently
>ridiculous for a non-readers.
>You can work this much out on the fly.
>
>I don't mean to be rude, I get driven to it.
>your thinking is all too evidently that of a technician rather than a carer.
>Try coding from the perspective of a non reader, and you'll realise that
>LYNX is not a product they are likely to use.
>In fact if they are browsing unaided its almost certain they must be using 5
>or later else its not got enough multimedia to entertain.
>
>OK we'd like our product to suit all needs, but there's precious little
>suitable content about, and the great need is for product, cross
>compatibility is not an issue.
>
>
>jay@peepo.com
>
>Jonathan Chetwynd
>special needs teacher and
>web accessibility consultant.
>----- Original Message -----
>From: Gregory J. Rosmaita <unagi69@concentric.net>
>To: Anne Pemberton <apembert@crosslink.net>
>Cc: Web Content Accessiblity Guidelines Mailing List <w3c-wai-gl@w3.org>
>Sent: Wednesday, March 15, 2000 12:30 AM
>Subject: Re: Text equivalents
>
>
> > aloha, anne!
> >
> > while you made several salient and valuable points in your initial post
>and
> > your reply to william, the page which you referenced in your reply to
>william:
> > http://www.ih.k12.oh.us/ps/americana/Eberle/EBsongs.htm
> >
> > is a poor example for several reasons:
> >
> > 1. there is no prior indication that following a link will load a WAV file
> > -- why don't the pages point to transcriptions of the songs, which contain
> > a link which is clearly marked as referencing an audio clip (additional
> > information that would be useful would be the format of the audio file, as
> > well as the file size and approximate playing time) -- in that wise, a
> > child who is deaf or who is using a computer without a sound card (or
> > support for the proprietary format) could obtain the same information that
> > other children ostensively obtain when they listen to the audio
> > clips... this is also true of the link whose hyperlink text is "The
> > Star-Spangled Banner" -- there is nothing about the link (save for the
> > HREF) which identifies it as linking to a WAV file
> >
> > 2. there are no textual equivalents for the songs (i.e. transcripts of the
> > songs for those who cannot hear the WAV files)
> >
> > 3. the names of the persons whose pictures appear on the page are only
> > visually slash spatially associated with the pictures, and there are no
> > explicit captions associated with them, so unless you can see them
>rendered
> > exactly the way the designer of the page intended them to be rendered
> > (using a TABLE for layout purposes), they are actually quite useless...
>if
> > you doubt the validity of that last claim, try, for example, viewing the
> > page with Lynx, and you will see how easily a Lynx user might
>mis-interpret
> > the pseudo-caption as referring to the Lynx-generated placeholder, [LINK],
> > which follows most of the names when the table is linearized.. there are
> > several ways that a stronger, more explicit association could have been
> > defined for the graphic and its caption -- many of which are included in
> > the WCAG techniques document
> >
> > 4. none of the graphical hyperlinks on the page utilize ALT text, nor do
> > they provide LONGDESCs or D-links to describe the images (a blind or
> > deafblind child might, for example, want to know what george washington or
> > susan b. anthony looked like)
> >
> > gregory
---------------------------------------------------------------
BIGOT, n. One who is obstinately and zealously attached to an
opinion that you do not entertain. -- Ambrose Bierce
---------------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
Camera Obscura <http://www.hicom.net/~oedipus/index.html>
VICUG NYC <http://www.hicom.net/~oedipus/vicug/>
Read 'Em & Speak <http://www.hicom.net/~oedipus/books/>
---------------------------------------------------------------