Re: [RequestAnimationFrame] PFWG Review of Timing Control for Script Animations

On Wed, Mar 14, 2012 at 1:14 PM, Michael Cooper <cooper@w3.org> wrote:

> **
> Below are three comments, vetted by the Protocols and Formats Working
> Group, on Timing control for script-based animations<http://www.w3.org/TR/2012/WD-animation-timing-20120221/>
> .
>
> 1) An important accessibility requirement is that users be able to pause
> or stop moving content that may be distracting. This is expressed in Web
> Content Accessibility Guidelines 2.0 Success Criterion 2.2.2
> http://www.w3.org/TR/WCAG20/#time-limits-pause. For script-based moving
> content, this currently requires authors to provide this feature within
> their script, something that many do not do. User Agent Accessibility
> Guidelines Success Criterion 2.11.6 http://www.w3.org/TR/UAAG20/#sc-2116reflects this requirement and requires user agents to provide such a
> feature directly. It seems Timing control for script-based animations would
> provide the ability to exert control over animations that use this
> technology, even when authors do not build this feature, via the user
> agent. However, it is not clear how external scripts can interact with the
> request animation frame callback list in order to stop animation. While
> perhaps simply clearing the list would serve to stop animation (if some
> other process does not restart it), that would not meet the use case to
> pause the animation with the ability to restart as far as we can tell. We
> request clarification in the specification of how this use case would be
> met, noting that it may (or may not) require additional methods.
>

The user agent can limit the animation rate to whatever is acceptable for
the user.  External scripts cannot.

>
> 2) We are concerned about potential problems arising from animation rates
> that are not pre-determined. While this has always been a problem with
> script-based animation due to environmental differences, this specification
> introduces further variability into animation rates. The accessibility risk
> that arises is triggering photosensitive epileptics seizures due to certain
> types of animation with certain frame rates, described in Web Content
> Accessibility Guidelines Success Criterion 2.3.1
> http://www.w3.org/TR/WCAG20/#seizure-does-not-violate. While Timing
> control for script-based animations serves to slow down animations and thus
> is more likely to slow animations out of the seizure-trigger threshold
> rather than accelerate them into that threshold, it is possible for it to
> set animations into a seizure-inducing frame rate. For instance, an
> author-defined animation with a frame rate that exceeds the
> human-perceivable limit could be slowed down into the human-perceivable
> range and then become a seizure-inducing trigger. There may be additional
> conditions that could result in this that our limited understanding of the
> processing model does not allow us to predict. It is unfortunately probably
> not feasible, due to the wide variety of factors involved and potential
> impact on non-problematic animations, to introduce limitations into the
> technology to eliminate the risk of creating seizure-inducing animations.
> But we do request that a warning to authors about the issue be provided in
> the specification, including details about the types of animations that
> could become seizure-inducing when their frame rates are modified by this
> technology. The WCAG 2.0 definition of general flash and red flash
> thresholds http://www.w3.org/TR/WCAG20/#general-thresholddef and the
> support material for WCAG 2.0 Success Criterion 2.3.1
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/seizure-does-not-violate.htmlmay be useful here. Note that because this is a safety issue, not merely a
> performance one, we consider this issue critical to address.
>

The author can pick whatever framerate they desire (by observing the time
between calls and postponing if necessary).  Similarly, the user agent can
limit the animation rate to whatever the user wants.


> 3) The note that "getting the next sample time" is undefined
> http://www.w3.org/TR/2012/WD-animation-timing-20120221/#dfn-get-next-sample-timeis problematic. With this value undefined, there is more potential
> variability in practice with the impact of this technology on animations,
> resulting in more uncertainty in which animations could potentially become
> seizure-inducing as per the previous comment. We request that this feature
> be normatively defined in the specification.
>

It will be.

- James


>
> --
>
> Michael Cooper
> Web Accessibility Specialist
> World Wide Web Consortium, Web Accessibility Initiative
> E-mail cooper@w3.org <cooper@w3.org>
> Information Page <http://www.w3.org/People/cooper/>
>
> --
>
> Michael Cooper
> Web Accessibility Specialist
> World Wide Web Consortium, Web Accessibility Initiative
> E-mail cooper@w3.org <cooper@w3.org>
> Information Page <http://www.w3.org/People/cooper/>
>