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

Hi,

Dean Jackson writes:
>
> 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.


Well, it's because good CSS is a strong support technology for a11y.
You're our allies in this.

Janina

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

-- 

Janina Sajka,	Phone:	+1.202.595.7777;
		sip:janina@CapitalAccessibility.Com
Partner, Capital Accessibility LLC	http://CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Received on Friday, 24 April 2009 20:43:35 UTC