Re: [w3ctag/design-reviews] Other Spec Review: CSS Image Animation (Issue #1237)

matatk left a comment (w3ctag/design-reviews#1237)

Hi @DevSDK, and thank you for your review request. We have some feedback and questions.

**Overall:** Clearly there are good use cases to be solved here, and there is developer demand. The approach looks reasonable (though we have a few questions, below).

**General thought/proposal:**

There's a lot of inconsistency across the platform on motion and animation. It'd be great if we could work towards a solution to the [wider user needs](https://github.com/w3ctag/gaps/issues/15) and hopefully not precluding that with any of the work proposed here (input on there would be welcome!)

For example, the 'user research' section highlights WCAG needs, and gives some good requirements. This doesn't capture _all_ the key requirements, such as varying the pace of animation (but as long as this approach doesn't preclude them from being met, we could build on it).

**Questions/concerns:**

* The explainer states:

  > Currently, screen readers typically do not chose to announce animated images differently from non-animated images, though they could if they wanted to.

  Is it the case that screen readers can know if images are animated or not? If it's not the case, then it would need to be addressed in order for AT to be able to help the user understand and control the state of the image.

* We have unanswered concerns about doing things like changing focusability via CSS; it is likely to be a potential footgun. Specifically in this case, we (and the explainer) would benefit from answers to some immediate practical concerns like: how will the animated image be named? Where will it get its accessible name from?

**Missing 'contemporary solutions' and 'rejected alternatives' section info:**

* The 'Contemporary Solutions' section needs to be fully populated so we can effectively evaluate the proposal - there's some tantalising stuff in there about why they think this is better than something like `<img controls>` but it's not explained.

* Regarding the rejected alternative of 'Provide this as a UA setting'...

  - The explainer states that this approach was rejected because the browser can't determine what is a content and what is a decorative image. However, the [explainer also has a definition for the difference between content and decorative images](https://drafts.csswg.org/css-image-animation-1/explainer#rejected-alternatives:~:text=content%20images%2C%20which,to%20external%20images.).

    That difference can be detected by the UA, but we expect that in the wild, content authors will use both _technical_ types of image for both (semantically) content and decorative images. This means we agree with the reason given for rejection of this approach.

    However, the explainer also specifies different UA behaviour based on whether an image is a content, or a decorative, image - so is there a contradiction there that needs to be resolved? 

  - The explainer does explain how UAs could continue to provide this setting (which seems like a good idea for users, even if it has to be blunt).

**Minor stuff:**

* Under 'Non-goals' there's a link 'could be pursued separately' that is broken.

* The table of contents links in the explainer don't go anywhere.

**Background links:**

* [WCAG SC 2.3.3
Animation from Interactions (Level AAA)](https://www.w3.org/WAI/WCAG21/Understanding/animation-from-interactions.html)

* [Making Content Usable for People with Cognitive and Learning Disabilities](https://www.w3.org/TR/coga-usable/)

* [Giving users control over motion](https://github.com/w3ctag/gaps/issues/15)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1237#issuecomment-5346128630
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1237/5346128630@github.com>