[RequestAnimationFrame] PFWG Review of Timing Control for Script Animations

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-2116
reflects 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.

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.html
may be useful here. Note that because this is a safety issue, not merely
a performance one, we consider this issue critical to address.

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-time
is 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.
 
-- 

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