RE: Questions regarding animation requirements in UAAG 1.0

Ian:
I've been pretty busy getting ready for the face2face, so please excuse the
long delay in responding and the brief replies in-line.
-Aaron

> -----Original Message-----
> From: Ian Jacobs [mailto:ij@w3.org]
> Sent: Wednesday, February 21, 2001 8:40 PM
> To: pschmitz@microsoft.com; aaron.m.cohen@intel.com; clilley@w3.org
> Cc: w3c-wai-ua@w3.org; dd@w3.org; asgilman@iamdigex.net
> Subject: Questions regarding animation requirements in UAAG 1.0
> 
> 
> Patrick, Aaron, Chris,
> 
> I would greatly appreciate your comments on the questions below, to
> help the User Agent Guidelines Working Group resolve some outstanding
> last call issues. The questions are about user agent control of
> animations. 
> 
> (I am cc'ing Al Gilman and Daniel Dardailler on this email so that
>  WAI PF can track this discussion if necessary.)
> 
> In the 26 Jan 2001 draft of the User Agent Accessibility Guidelines
> 1.0 [1], there are two checkpoints that involve control of animations:
> 
>  --------
> 
>   4.4 Allow the user to slow the presentation rate of audio, video and
>   animations. For a visual track, provide at least one setting between
>   40% and 60% of the original speed. For a prerecorded audio track
>   including audio-only presentations, provide at least one setting
>   between 75% and 80% of the original speed. When the user agent
>   allows the user to slow the visual track of a synchronized
>   multimedia presentation to between 100% and 80% of its original
>   speed, synchronize the visual and audio tracks. Below 80%, the user
>   agent is not required to render the audio track. The user agent is
>   not required to satisfy this checkpoint for audio, video and
>   animations whose recognized role is to create a purely stylistic
>   effect.  [Priority 1]
> 
>   4.5 Allow the user to stop, pause, resume, fast advance, and fast
>   reverse audio, video, and animations that last three or more seconds
>   at their default playback rate. The user agent is not required to
>   satisfy this checkpoint for audio, video and animations whose
>   recognized role is to create a purely stylistic effect. [Priority 1]
> 
>  --------
> 
> The UA Working Group has questions about whether a user agent can
> satisfy these requirements for all classes of animation and animation
> format.
This is a very complex question and in many practical cases deals with the
realities of media system architecture more than absolute possibility.

For sure, there are many situations where playing backwards is not
practical. For examples, streaming video would require infinite storage. But
pausing, resuming, and rewinding are fine and implicit "desired" controls of
the presentation timeline for the user agent.

> 1) It would seem that for animations that are composed of "frames"
>    (e.g., animated GIFs, Flash animations), that this type of
>    control: slow, reverse, advance, etc. is feasible.
Yes, if the API from "time manager" to "renderer" supports it. The fact is
that many architectures which allow plug in players currently do not.

> 2) It would seem that for some other classes of animations
>    (e.g., animations that may be created with SMIL Animation [2]),
>    it may not be feasible to satisfy our slow, advance, and
>    reverse requirements.
Actually, the requirement is easiest to satisfy with purely algorithmic
animations such as is usually done with SMIL Animtion. It depends upon what
properties of the target are being animated. In the usual cases, such as
position or color, it is relatively easy to play these at different rates.

Even in this case though, you have to realize that other parts of the
presentation may be locked to the timing of the animation, and so playing
the animation at a different rate would require parts of the presentation to
play at that new rate and so you are back to the original difficulty with
media types and plug in interfaces.
 
> Questions:
> 
>  * Would you agree with these two assertions? 
See above.
 
>  * Can you help us understand (and qualify) why SMIL Animation
>    animations do not lend themselves to being slowed, reversed, or
>    fast advanced (and how we might explain that in our requirements,
>    if necessary)? Chris indicated that SMIL 2.0 animations [3] were 
>    different than SMIL Animation and could be controlled in the
>    indicated manner. Why is that the case?
The SMIL 2.0 namespace (currently, not the language) has extensions that
support declarative modification of the rate of passage of time with
accelerate, decelerate, and speed. Maybe that is what he is talking about.
That in SMIL 2.0 we have declarative means of doing this.

But these things control whole time scopes, not just the animations. And the
rules propagate if DOM calls or other means are used to change the rates.
Things that are locked together, say in a par, are supposed to remain locked
together. So animations coordinated with things like video could be very
difficult to play backwards. As I note about, to ensure a consistent
presentation, modifying the rates of an animation in a presentation would
have to obey the rules of consistent time within a container. Of course
documents can be authored to allow slippage of the animations against time
siblings, but the opposite may be possible as well.

Note that if the user agent has an option to "disable" animations, then the
animation elements themselves would still have to run, in order to preserve
timing relationships. The user agent could, however, disable the "effect" of
the animation. So that it ran, but the values were not actually animated in
the presentation.

This all or nothing approach is probably not optimal, but it does give the
user a way of separating the timing dependencies from the affect on what the
user sees.

 >  * What other classes of animations should we be considering and
>    have forgotten about? 
I'm sure that there are more I have not though of.
 
> Notes:
> 
>  a) We explicitly do not require user agents to provide the indicated
>     control for animation effects created through scripts. Our
>     checkpoints 4.4 and 4.5 only address those animation effects 
>     that the user agent can "recognize" through the format.
Okay, but the issues above are basically the same in either case. 

>  b) We are not concerned here with control limitations due to
>     streaming (i.e., you can't fast advance through streamed content).
Okay good.
  
>  c) We are not concerned here with alternative content workarounds
>     from the author.
I figured that, but realize that the author may be expressing a critical
part of the content by the synchronization between and animation and other
media. You can't just slow the animation, you have to slow the other media
that it is synced with.

> Thank you for any direction you can provide,
> 
>  - Ian
> 
> [1] http://www.w3.org/WAI/UA/WD-UAAG10-20010126/
> [2] http://www.w3.org/TR/2000/WD-smil-animation-20000731
> [3] http://www.w3.org/TR/smil20/
> 
> -- 
> Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
> Tel:                         +1 831 457-2842
> Cell:                        +1 917 450-8783
>

Received on Friday, 23 February 2001 19:26:32 UTC