PF-Wg feedback on CSS animations, transitions, and transforms modules (20 March 2009 version)

The following is formal PF Wg response to the modules referenced below.
We apologize that we're forwarding them a bit late. The PF Wg thanks
Michael Cooper for leading its review of these modules and for preparing
our feedback.

------------------------------------------------------------------------

    * CSS Transitions:
      http://www.w3.org/TR/2009/WD-css3-transitions-20090320/
    * CSS Animations: http://www.w3.org/TR/2009/WD-css3-animations-20090320/
    * CSS 2D Transforms:
      http://www.w3.org/TR/2009/WD-css3-2d-transforms-20090320/
    * CSS 3D Transforms:
      http://www.w3.org/TR/2009/WD-css3-3d-transforms-20090320/

These comments apply primarily to the CSS animations module but are
applicable to animated transitions and transforms as well.

1) Accessibility Issues

Potential accessibility issues created by the features of these modules
include:

   1. If the animation or transform conveys meaning, the meaning also
      needs to be communicated another way. This is of course true for
      any other use of CSS.
   2. Defining the ability to have content moving over time means
      there's the possibility of distraction or difficulty interacting
      with it. This activates the requirements of WCAG 2.0 Success
      Criterion 2.2.2 (http://www.w3.org/TR/WCAG20/#time-limits-pause).
   3. It is also possible to create seizure-provoking flashing content
      with these technologies. This relates to WCAG 2.0 Success
      Criterion 2.3.1
      (http://www.w3.org/TR/WCAG20/#seizure-does-not-violate) and, at a
      higher conformance level, 2.3.2
      (http://www.w3.org/TR/WCAG20/#seizure-three-times).

We recommend that these modules include informative notes in appropriate
places reminding authors to be responsible in how they design their
animations, in order not to create the above problems. We also intend to
work with the WCAG Working Group to provide techniques for these CSS
features related to these issues.

2) Declarative control of animation state

There is also a note that you are considering removing the
animation-play-state property
(http://www.w3.org/TR/2009/WD-css3-animations-20090320/#the-animation-play-state-property-).
We strongly recommend that you not remove this property. The rationale
in the note for removing it is that pausing animations can be
accomplished by other means. However, there wouldn't be a standardized
means, and authors might be less likely to provide a mechanism to pause
content. The ability to pause long or repeating animations is vital for
content to conform to WCAG 2.0 SC 2.2.2, and we should make it as easy
as possible for them to do so. Also, although it would be possible to
use a script to pause and restart an animation, it would be difficult
for a tool to inspect the current state of the properties and determine
that there is a paused animation in progress as opposed to just a set of
properties. This makes it more difficult for quality assurance of
conformance to WCAG 2.0. There may be other accessibility use cases for
wanting to be able to inspect this property. Therefore, it is highly
desirable to retain this property, to specify that simply changing the
state of the property automatically pauses or unpauses the animation,
and that the current state of the animation can be determined by
inspection of this property.

3) Declarative control of animation speed

Some users need to be able to speed up or slow down animations. While
this may not be crucial for basic transitions associated with, for
example, mouse hover over a link, longer animations would need this
feature. In reviewing the set of properties that control animations, it
was not clear if a third party tool (e.g., assistive technology, browser
extension, etc.) could reliably adjust a given property to achieve an
intended animation speed effect. We request either that the necessary
properties be added, or that information about how third party tools can
speed up and slow down animations be provided.

4) Access to CSS DOM

Since third party tools interact with and potentially modify CSS via the
DOM, it is important that the support for programmatic modification of
CSS exist. The PFWG was not clear if the sections on DOM interfaces are
normative and expected to be supported by browsers, or if they are
informative. A standardized means of programmatically altering the
defined CSS properties is important to achieve the use cases described
in the previous comments. We request that the normative mechanism for
doing so be clearly indicated.

5) Update of display on property change

It was not clear if the CSS specifications require that display be
updated when CSS properties are changed. This comment may not be
directly applicable to the specifications under review and referenced
above, but is relevant to the situations on which we comment. Is there a
statement somewhere that CSS display MUST be updated when a property is
changed? If the display of CSS is not guaranteed to be updated, then the
features requested in the above comments won't provide the intended
accessibility benefit anyway. We request a clarification on this issue,
or a normative statement in these documents if need to ensure the
ability to update animations.


Janina Sajka, WAI-PF Chair