SMIL Boston comments

                           Subject:                         Time:   8:46 AM
                           SMIL Boston comments             Date:   8/5/99

A few comments on section L, "SMIL Timing and Synchronization:

3.1.3 says...
A pause functionality has been proposed as an option on exclusive time containers.  With this, instead of stopping an element when another begins, the first element would be paused while the new element plays.  When the new element completes, the previoiusly playing element would resume.

GF:
While SMIL Boston suggests this would be most useful for commercials, it has great implications for accessibility for blind users-- specifically, the improved implementation of audio descriptions.  In the current broadcast model, which can be implemented in SMIL 1.0, audio descriptions are squeezed into the natural pauses of the program's regular audio track.  However, this time limit doesn't always allow for enough information to be delivered.  However, if the author had the capability to pause the video, play an extended description and, when the description was finished, resume video playback, a lot more useful information could be delivered to the blind user.

Another point-- this stop-and-start process should occur automatically.  This almost sounds like what is being described in the very last bullet point in 3.1.3-- video plays; description 1 plays, which causes the video to pause; description 1 ends, which causes the video to resume playing; description 2 plays, thus pausing the video, etc.  However, I think this last bullet point relies on the user pressing an on-screen button to pause the video.  Ideally, the user could set a preference in the player that says if audio descriptions are available, they should simply be played.  This also means SMIL Boston would need an audio equivalent to system-captions=on, yes?

Geoff Freed
CPB/WGBH National Center for Accessible Media

Received on Thursday, 5 August 1999 09:34:15 UTC