Proposal for further refinement of audio, video, animation requirements

Hello,

Per my action item from the 31 August teleconference [1], please
consider the following proposal to address issues raised about control
requirements for audio, video, and animation. This proposal attempts
to address issue 297 [2] (control of content that is intended for
style), comments from Al Gilman and Eric Hansen about control
requirements
for short audio and video, and also Gregory Rosmaita's request that
he be able to suppress automatic rendering of audio on load.

Note: For this discussion I focus on audio, but the same discussion
applies to video and animations. The checkpoints of the 18 August
draft [3] affected by this proposal are: 3.2, 3.3, 3.5, 4.5, and 4.6.

<OLD (From 18 August draft [3])>
3.2 Allow the user to configure the user agent not to render
audio. [Priority 1] 

4.6 Allow the user to start, stop, pause, resume, advance, and 
rewind to the beginning audio, video, and animations. [Priority 1] 
</OLD>

<NEW>
Priority 1 requirements:

1) Keep current checkpoints 3.2, 3.3, 3.5.

2) For rendered audio that lasts three or more seconds at its 
   default playback rate and that is not marked up by the author 
   as style, allow the user to stop, pause, resume, fast advance, and
   fast reverse the audio. The user must be able to control
   each such audio source recognized as distinct independently of 
   others. 
     Note: This checkpoint applies to content that is rendered
     automatically or on request from the user. Respect 
     synchronization cues per checkpoint 2.4.

3) For rendered audio, video, and animations that last 
   three or more seconds at the default playback rate 
   and that are not marked up by the author as style,
   allow the user to slow the presentation rate. [Rest of checkpoint.]
    
Priority 2 requirements:

4) For rendered audio, video, and animations 
   not covered by checkpoint 2, allow the user to pause, 
   resume, fast advance, and fast reverse the content.

5) For rendered audio, video, and animations 
   not covered by checkpoint 3, allow the user to slow
   the presentation rate.

6) Allow the user to configure the user agent not to 
   render any audio that the author has specified to be
   rendered without explicit user request.
     Note: The user should be able to play this audio
     by changing the configuration and reloading the 
     content.
</NEW>

Notes:

a) There is no explicit requirement that a user agent allow the
   user to play audio. If a user agent supports audio, it will
   allow the user to play it, whether automatically or on explicit
   request from the user. Specifications will indicate whether
   content is meant to be played on user request or automatically.
   Saying "play audio" is like saying "process html". What is
   important to us is the ability to stop audio that may be 
   a barrier to accessibility, or control it for access to the 
   information it contains. It is for these functionalities that
   we must have minimal requirements. Same applies to video, animations.

b) I chose the "three-second" limit arbitrarily (obviously).
   Does this make sense to developers (can a UA tell how long
   an audio clip will play at its default rate)? 
   Does it cover sufficiently user needs, or do we need
   more semantics here?

c) The sixth checkpoint is intentionally
   expressed in terms of the author's intent rather 
   than the user's choice of which audio the user 
   wants to play expressly.

d) Checkpoint 4.17 (control of opening viewports) might cover 
   what is required by checkpoint 6 above. If the user
   has configured the user agent to not open viewports except
   on user request, then any viewport rendering audio could
   be suppressed unless requested from the user (which is what
   Gregory wants). Refer to proposal (as yet unadopted) to
   fix checkpoint 4.17 [4]. For similar reasons, checkpoint 6
   is proposed as a P2 checkpoint: don't require the user to stop
   several sources of audio manually when the user agent can do so
   automatically.

e) If the Working Group decides to merge checkpoints 2 and 4 and
   to merge 3 and 5, (thus requiring the user agent to compensate for
   bad authoring practices) then the document should indicate that 
   this level of control is being required as a repair functionality.

 - Ian


P.S. For the record, here are the axes on which this proposal is
based:

a) Global v. Element-level control. 
b) Start and stop
c) Pause, resume, fast forward, fast reverse
d) Content intended as style v. more important content.
e) Short v. Long clips
f) Explicit request to render v. automatic rendering.

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0341.html
[2] http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#297
[3] http://www.w3.org/WAI/UA/WD-UAAG10-20000818/
[4] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0246.html
-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Thursday, 31 August 2000 20:25:48 UTC