RE: Text equivalents

Anne,

I think Gregory's point is that we should be looking for model pages/sites
that meet your and Jonathan's expectations that are *ALSO* P1 compliant.
There is not much virtue to addressing cognitive issues if such
accommodations break the pages for other users.

I would also point out that text equivalents (i.e., machine readability)
will still be important for the next- next-generation of browsers.  Those
products could incorporated significant artificial intelligence that
provides highlighting of salient points and selective self-voicing prompts,
hints, and guides.  The very thing you wrote about doing as a human looking
over the shoulder of one of your clients!  Those smart user agents will
gracefully handle text long before they can deal effectively with graphics.

If this discussion is going to be productive, someone who is a content
expert in this field (i.e., you or Jonathan) needs to lucidly address Gregg
V.'s last question:

> Is there something that you think we should do besides:
> 1) making sure all text is electronic (so that it can be read to the user
by
> their browser)
> 2) encouraging the use of graphics on a page  and
> 3) keeping the language as simple as possible


> -----Original Message-----
> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org]On
> Behalf Of Jonathan Chetwynd
> Sent: Wednesday, March 15, 2000 12:05 PM
> To: Anne Pemberton; Gregory J. Rosmaita
> Cc: Web Content Accessiblity Guidelines Mailing List
> Subject: Re: Text equivalents
>
>
> 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
> >
> > --------------------------------------------------------
> > He that lives on Hope, dies farting
> >       -- Benjamin Franklin, Poor Richard's Almanack, 1763
> > --------------------------------------------------------
> > Gregory J. Rosmaita <unagi69@concentric.net>
> >     WebMaster and Minister of Propaganda, VICUG NYC
> >          <http://www.hicom.net/~oedipus/vicug/index.html>
> > --------------------------------------------------------
> >
> >
>
>

Received on Wednesday, 15 March 2000 14:12:19 UTC