- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Wed, 15 Mar 2000 14:45:56 -0500
- 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 UTC