Hi janina - just wanted to check in on the CSS feedback. I think we were going to have hives checking on the list, and then have you send it. I didn't notice any responses to my final feedback writeup. Do you think it's ready to send now?

The message should go to www-style@w3.org, with a copy to wai-liaison@w3.org. The subject should be something like "[css3-animations] PFWG feedback on CSS animations, transitions, and transforms modules (20 March 2009 version)".

Michael

-------- Original Message --------
Subject: Composite proposed feedback on CSS modules
Resent-Date: Tue, 14 Apr 2009 19:47:16 +0000
Resent-From: w3c-wai-pf@w3.org
Date: Tue, 14 Apr 2009 15:45:50 -0400
From: Michael Cooper <cooper@w3.org>
To: List WAI PF <w3c-wai-pf@w3.org>


Here is combined proposed feedback on the CSS transitions, animations, and transforms modules. If the WG approves it we can send it on to the CSS WG.


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.

Michael
--

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org
Information Page


--

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org
Information Page