W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2000

Re: Text equivalents

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Wed, 15 Mar 2000 14:45:56 -0500
Message-Id: <4.2.2.20000315134525.00bf9400@pop3.concentric.net>
To: "Jonathan Chetwynd" <jay@peepo.com>
Cc: "Web Content Accessiblity Guidelines Mailing List" <w3c-wai-gl@w3.org>
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/>
---------------------------------------------------------------
Received on Wednesday, 15 March 2000 14:36:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:01 GMT