Re: Audio Access

to follow up on what Geoff Freed said:

> 
> [Decorative sounds should always carry a description-- on
> television, closed captions display *sound effect* captions to
> alert the viewer to important non-verbal information.  The same
> should be true on the Web.  Again, this information should be
> automatically displayed.  

I believe that the "automatically" should be one of the things
that the viewer/browser lets the user control.

For those using synthetic speech to access text, there are
potential problems when the sound effect, and/or the spoken text
of a description of the sound effect, collides (in the audio
delivered to the user) with the presentation of spoken text
extracted from the page.

At the meeting in Boston I was left with the following idea:

We need to make sure that the media that are used to carry
streaming content are infiltrated with enough control hooks so
that the user can, if need be, peruse the content piecewise.  As
part of this, the user needs the capability to unbundle the
nominally "synchronized multi-" media as required to resolve
conflicts over user sensory capabilities.

Today the Web Author composes what she thinks is a threaded heap
of magazine pages or cereal boxes, but the user needs the
capability to navigate it as asynchronous radio.

Tomorrow the author creates a movie but the user needs the
capability to access it as a talking book.

I have not read the SAMI spec yet.  I suspect that it provides
the most-needed basic capabilities: timing tracks for the audio
and video and some method of cross-linking between tracks via a
sync track.

Possible areas for accessibility improvement in that case are to
look at whether there is enough markup in the sync track to
reconstruct a full script _if you need it_.

For adapted access, the multimedia data bundle should encode the
script structure in player-comprensible language; not the script
text in flat text.

--
Al Gilman

Received on Monday, 25 August 1997 13:12:47 UTC