Re: Audio Access

        Reply to:   RE>>Audio Access

Al's correct.  I should have qualified the "automatically."  However, is it necessary for there to be a spoken description of a sound effect caption?  I'll illustrate with yet another parallel to broadcast captioning and audio description:  if a program contains both closed captions and audio descriptions, (as some do on PBS and home video), the description track does not reflect the fact that captions are being displayed on the television screen.  In other words, the captions are not read as part of the descriptions.  Conversely, the audio descriptions are not reflected in the closed captions.  

Now, apply this to the Web.  If I were a deaf Web user, sound effects would be described to me visually, using a caption (or something like it).  And if I were a blind user, I wouldn't need a sound effect described aurally to me because I could already hear it.  Thus, you'd only need a sound effect *caption*, not a description.  That would eliminate the problem Al describes below.  Yes?

geoff

--------------------------------------
Date: 8/25/97 2:06 PM
To: Geoff Freed
From: Al Gilman
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


------------------ RFC822 Header Follows ------------------
Received: by wgbh.org with ADMIN;25 Aug 1997 13:15:19 -0400
Received: by www19.w3.org (8.8.5/8.6.12) id NAA11051; Mon, 25 Aug 1997 13:12:55 -0400 (EDT)
Resent-Date: Mon, 25 Aug 1997 13:12:55 -0400 (EDT)
Resent-Message-Id: <199708251712.NAA11051@www19.w3.org>
From: Al Gilman <asgilman@access.digex.net>
Message-Id: <199708251712.NAA24703@access2.digex.net>
To: w3c-wai-wg@w3.org (WAI Working Group)
Date: Mon, 25 Aug 1997 13:12:43 -0400 (EDT)
In-Reply-To: <n1340565829.96137@wgbh.org> from Geoff Freed at "Aug 14, 97 11:03:18 am"
X-Mailer: ELM [version 2.4ME+ PL15 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: Audio Access
Resent-From: w3c-wai-wg@w3.org
X-Mailing-List: <w3c-wai-wg@w3.org> archive/latest/358
X-Loop: w3c-wai-wg@w3.org
Sender: w3c-wai-wg-request@w3.org
Resent-Sender: w3c-wai-wg-request@w3.org
Precedence: list

Received on Monday, 25 August 1997 16:23:07 UTC