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

On 24/04/2009, at 7:09 AM, Janina Sajka wrote:

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

Thanks for the review. I'm impressed you completed a formal review  
after only the first public WD, but this will definitely help us get  
issues sorted out quickly.

>
> ------------------------------------------------------------------------
>
>    * 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.

Great. I'll add a warning and a link to WCAG.

It's probably obvious, but one advantage CSS Animations has over JS  
animations is that the user style sheet can do this:

* {
   css-animation-name: none !important;
}

This will disable all animations for all content.

Furthermore, in our WebKit implementation, we're planning on adding a  
preference to disable animations.

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

Good feedback. We were on the fence about removing the property,  
driven mostly by the "smaller specs are better" goal. The WebKit  
implementation has the property, and it works well and is easy to write.

Unless other people speak up with good arguments, we'll keep the  
property and remove the text marking it as under threat.

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

It is possible for an assistive tool to modify the animation durations  
for each animation fairly easily. We also have an event to notify when  
an animation has started, but by then it is too late to change the  
animation (other than to remove it and restart it with a modified  
duration, which might be good enough).

I'm tempted to think this is enough, but it would be good to get  
feedback.

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

The CSSOM is definitely normative and is required. For animations and  
transitions, you would not need any of the proposed DOM interfaces -  
the existing CSSOM is good enough. For example:

document.getElementById("some-element").style.transitionDuration =  
"10s";

That would set the inline style on the element, overriding the style  
sheet. Similarly, you could use the CSSOM to query the existing  
durations and slow them down by a factor of 5.

Our proposed DOM extensions are mostly for convenience when dealing  
with transforms.

>
> 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?

Not that I am aware of, and it depends on when it is changed: via a  
stylesheet loading, via JS, via a user event (eg. hover).

Or, to be more clear, the display will be updated, but exactly when  
that will happen is implementation specific at the moment.

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

I'm hesitant to add anything to these specifications on this matter.  
It seems like it is a general CSS issue.

For the transition/animation case, we deliberately do not specify how  
fast the animation should update. This is because it's basically  
impossible to guarantee, given that content could be anything and run  
on any device.

Dean

Received on Friday, 24 April 2009 01:04:45 UTC