We have a week before the Blink folks will approve this Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/TZLFLjzt4II/m/nzUrqB4CAwAJ

Hi @DavMila, thanks for your review request.

We appreciate this is an increasingly used pattern, and it's important to help authors to get it right. On those lines, we have several concerns:

• The robustness of this pattern on sites in general - e.g. when afforded by scripting - can be poor. For example: triggers firing the wrong number of times; things going wrong if the user scrolls back. Have you considered how these issues may be resolved through standardization?

• Historically, all page content was loaded in and was available to ATs - it might just be off screen, but could be explored. If content is loaded dynamically in response to scrolling, this could exclude some users. (It doesn't seem like that's inherent here, but it seems like a pattern that may more prominently emerge following this.)

• Scrolling and animation can cause huge cognitive issues (e.g. distracting, disorienting). We have prefers-reduced-motion but we're not sure how much consideration has been given to providing guidance for authors on how to ensure an equitable UX - especially in cases of complex animations revealing - or even themselves acting as - content.

• Does this interact with/affect the focus in any way?

There seems to be justification for an 'accessibility considerations' section, assuming ways to address these concerns are known, or could be found. APA WG would be happy to help by reviewing any content you might create for such a section.

We look forward to hearing your thoughts on the above.

Hi @DavMila, just wondering if you had any thoughts in response to our comment above?

Hi @DavMila, just wondering if you had any thoughts in response to our comment above?

Hi @matatk, we discussed this shortly after your comment but I apologize for taking so long in getting back to this.

• The robustness of this pattern on sites in general - e.g. when afforded by scripting - can be poor. For example: triggers firing the wrong number of times; things going wrong if the user scrolls back. Have you considered how these issues may be resolved through standardization?

One of the choices we made was to leverage scroll timelines which were introduced along with scroll-driven animations. Timelines, via the ranges API, offer developers a robust way of referring to portions of a scroll container. To use the “user scrolls back” case mentioned as an example, timeline triggers are designed to allow authors specify two ranges - this means that for a given side of the scroll port, authors can separate the boundary at which scrolling forward fires the animation from the boundary at which scrolling backwards does. One of the use cases we prioritized simplifying was being able to specify the ranges as contain / cover which provides a separation of the trigger points so that on one end of the scroll port triggering only happens when the element comes fully into view or goes fully out of view. We believe that this boundary separation, together with semantically connected “entry” and “exit” concepts (i.e. entry and exit must alternate) are likely to foster the development of UIs that are predictable and user-friendly.

• Historically, all page content was loaded in and was available to ATs - it might just be off screen, but could be explored. If content is loaded dynamically in response to scrolling, this could exclude some users. (It doesn't seem like that's inherent here, but it seems like a pattern that may more prominently emerge following this.)

I think our expectation is that use of this feature will apply to elements coming in and out of the viewport/scrollport, which are typically elements that are already loaded into the DOM.

• Scrolling and animation can cause huge cognitive issues (e.g. distracting, disorienting). We have prefers-reduced-motion but we're not sure how much consideration has been given to providing guidance for authors on how to ensure an equitable UX - especially in cases of complex animations revealing - or even themselves acting as - content.

We recognize that this is an important issue to consider and we think that this is something that developers should be considering in the context of animations in general. To this end, we noticed that the css-animation spec doesn’t have an accessibility section similar to the css-transitions spec. So, we are working on adding an accessibility section with a strong recommendation on prefers-reduced-motion. I think that one potential advantage of declarative scroll-triggered animations is the ability for the user agent to make modifications to the animations on a page according to the user’s needs. It might be more difficult for a user agent to do this with scripted scroll-triggered animations.

• Does this interact with/affect the focus in any way?

No, it doesn’t directly affect focus. In theory, it would be possible for an author to set up an animation that affects other CSS properties that, in turn, interact with focus , e.g. display. However, that’s true of animations today.