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

    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)

• Making Content Usable for People with Cognitive and Learning Disabilities

• Giving users control over motion

I'll be be addressing / responding to comments above, progressively, and posting below as I get to each.

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.

Addressed via https://github.com/w3c/csswg-drafts/commit/d4fd9b01a87356432dcba44cf5bb9a7f0526960b

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?

That distinction is only used in hypothetical future extensions. It has been dropped from the spec, as it was causing more confusion than anything. See https://github.com/w3c/csswg-drafts/commit/0eb48905bfc4b60d60a825602530413966af1eb2 for the corresponding spec fix, and https://github.com/w3c/csswg-drafts/commit/10488e373bcd89d8b9c9bf794540b139f555b0d5 for the explainer

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?

This is indeed a tricky area. For now, the controls feature considered by explainer is not included in the spec, in large part due to these concerns about automagic focusability, and we went with the :animated-image pseudo class instead (at least for now).

Naturally, as authors build controls themselves for the animation, they need to design those correctly in terms of focusability (and every other aspect of making the page accessible). The downside being that it's on them, the upside being that they can do the right thing for the right situation.

The spec does include an explicit reminder to authors about this.

the table of contents links in the explainer don't go anywhere. was an issue with the build system. Has been fixed since.

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

Oops, this broke when the explainer was moved. Fixed. https://github.com/w3c/csswg-drafts/commit/4619b8cae8a91141379f3a4364d371ae80e4c5de

Thank you @frivoal for your helpful replies. It's good to see the work you highlight. We'll come back to you on the info you've added and points you've raised as soon as we can.

For now, I just wanted to also ensure we had a link from here to this related CSS issue: https://github.com/w3c/csswg-drafts/issues/13784 about conveying role and state info to AAPIs.