Matthew and Serena: not yet

Jeffrey: this was approved by blinkdev to ship last week. There is still time for the working group to suggest changes, and then for the folks to make changes.

Lola: can we get to it soon, or should we reassign?

Matthew: I'll look at it tomorrow.

Serena: I'll have time this week.

Matthew to post the comment.

(Skipped.)

Matthew: It looks like we’re waiting for input from them. We’ve been talking in APA and the Cognitive Accessibility …, they have additional considerations. We could put them on this thread or in the repo. Can point them out once it’s fully reviewed.

Matthew: APA is working with cognitive accessibility tf, if anything comes up with cognitive accessibility we can bring it to this thread but for now we're waiting for external feedback from them.

Matthew: Same as last week: APA and my feedback will be coming soon.

Matthew: I think we posted on this yesterday. Think we’ll just say, I haven’t seen anything architectural, except for being very clear about the implications of using it. Makes it easier to build inaccessible, exclusive experiences. Takes things off the main thread, which we are usually happy about. I don’t think we need to add anything specific to the TAG response. Still working on the proposal with APA, but will send it separately, but that would go to the A11y section. Not to "stop it completely." Just waiting for an answer from them, and APA can file the issue separately.

Lola: Think I disagree with the "we shouldn’t say stop it," I think we should. But we can wait for them to come back before coming to a resolution.

Matthew: It’s labelled "pending external feedback." Shall I ping them?

Lola: You can do that.

Matthew: Looks positive b/c they work on an a11y section which we can have a look at APA. Was thinking about the robustness section, want to be the behavior more robust. Looks like they’ve considered that with scroll timelines, ranges API. Looks very promising, would respond with a positive comment.

[Coming back to this from earlier in the meeting]

Lola: Left a comment on this in the private brainstorming, as they responded. Addressed our concerns quite well. Two things, 1) specifying the ranges using contain/cover. This is already used in other places which have to do with images. Good to use existing syntax, but could this be confusing for developers? Or is context enough? Want Matthew and Xiaocheng's thoughts there. 2) Concern about dynamically loading elements into the DOM which could cause problems with accessibility. This is their actual expectation for the API. That indicates to me that there is a possibility that this feature might not apply to elements already in the DOM.

Hadley: Did we ask that question?

Lola: Plan to do this now. Wait for Matthew to check that. Will continue whenever folks are back.

Hadley: Any time pressures?

Lola: Past the deadline.

Hadley: Might be worth asking Jeffrey if this is too late.

Lola: They have been engaging with us actively, they wrote their comment two weeks ago.

Matthew: Proponents came back to our comment. Answered question about the DOM and they'll come back to it. Whether it effects focus: it doesn't. performance. The other is cognitive issues and animation could cause barriers, which APA and AG is looking at. The interesting thing is that they've identified there is no specific accessibility consideration for CSS animation, and so they're working on it. so there is a lot in common between two pieces of text which is a good sign. APA will work with them on that. When we / TAG comment, will point that out. Lola had a comment last week.

Lola: Had questions about, their response basically. They mentioned things that I wanted clarifying. They suggested using contain/cover, for separation between trigger points. Good to use established syntax, but contain/cover is used in a completely different context. This feels like going against work keywords already used. Similar issue with inert issue we had with CSS carousels. Maybe the context is different enough that it wouldn't be confusing, but I doubt it because it is still CSS.

The second is about wording. They say, whether elements are loaded dynamically or not. Elements coming in or out of the viewport, which are typically elements already loaded into hte DOM. I think our expectation is that we expect it to be done this but it might not be done this way. If the latter, it should be called or addressed.

Hadley: Did you ask these questions or we should?

Lola: I wanted to discuss in the group. Questions are in https://github.com/w3ctag/design-reviews-private-brainstorming/issues/223

Xiaocheng:

Matthew: If we can't readily find contain/cover use of those terms, we should ask them about that.

Lola:

Matthew: The question is worth ask explicitly about causing developer confusion.

Hadley: Reasonable to ask. It's the sort of thing we'd hope to see in an explainer.

Matthew: The question about stuff in the DOM / if rendered, there is something else about this question, which is, ties into other barriers as well. If animation is critical to the content on the page, then it is not necessary in the DOM. You have to explore them. The animation is when it wants to happen, not when you want to. It might be too fast for some people with accessibility or cognitive disabilities, or distracted. One of the things the APA is drafting is, the animations are not used for absolutely critical and/or the user agent gives the user some agency on the speed that these things that happen. This was also mentioned in the CSS group / that pleased me because they're thinking that. I don't know if the UAs enable that. In general we don't want to use this type of animation unless it is absolutely critical. There are videos where you can provide an alternative, in which case the animation is decorative, in the body or something like that. It is important and there is a more fundamental thing. Good to expose but if the user doesnt have a chance to grasp it before it goes away, there is not much point.

Hadley: Re speed of animation, as a user, would I know enough from the site to adapt it? I'm guessing it is a decision the site developers made beforehand, the speed of animation. Or maybe I could adapt it after I found the site frustrating?

Matthew: Thinking that this should be something the UA should have an idea about on behalf of the user. UAs could do this and they're not writing...

Lola: On the speed of animation thing, what do current animation folks do now. This wouldn't be the first time that issue would've been raised. With other animations or in general, how do they handle that issue.

Matthew: For housekeeping: the consideration section would cover all of it. There is a number of different ways this could be handled to include in our response. Web Platform issue: https://github.com/w3ctag/gaps/issues/15 . It does mention some very high level user requirements. Plenty more we could add, but they wanted to just publish it. This might be a good place to discuss for more cross-platform stuff.

Xiaocheng: Re animation speed, if we're talking about conventional animations, the animation speed is always set by developer, the scroll linked animation is only mechanism where user can decide the animation speed. Re whether in the DOM or not, I'm not sure about any mechanism about animating anything not in the DOM. if the page wants to load. domething dynamically, it has to be done by other means, and then after it's loaded, we add animations to it. Re discoverability of these elements, there is a very similar thing added to the spec, discrete transitions, if we display the type from none to block, with traditional transitions we can't add animations but with discrete transition we can have fading animation. And starting state of transition is display none, and I'm not sure if AT is undiscoverable.

Matthew: display none removes things from the Accessibiltiy Tree.

Xiaocheng: have we reviewed this before?

Hadley: let's check our github issues.

Xiaocheng: Previous design reviews for discrete transitions: https://github.com/w3ctag/design-reviews/issues/829 https://github.com/w3ctag/design-reviews/issues/825

Sarven: This is a good topic. it for input the user agent's doucment about...the UA has a good shot, a good sense of hte user's capabilities and needs. So in the UA doucment has an understanding that there are duteis o the UA to fulfill, to protect the user and so on. I can have a look at the doument and see how we can caputre this point about ensruing the user's needs or capabilities are factored in to its decision-making. The UA should provide the controls to control that

Hadley: I think it's great to put this into the UA document.

Matthew: Sarven just made me say this, 100% million agree. Priority of constituencies! The author's viewpoint has been more important than the user and that's where the problems have come from. Priority of constituencies is super important. This is how I imagine it to work. I have turned up text size in the OS, and the browser doesn't see it but does reflect it. It could be done transparently to the author.

Hadley: why do that in the OS instead of the browser?

Matthew: I need it for other apps too

Sarven: another example is dark mode or light mode, which is in the OS and inherited in the browser. I prefer to have that, I trust my OS most, and I want to dictate how the rest of my interaction happens on my computer and browsers want context. so if I set it to dark mode at night, I like my UA to adhere to that. Similar ideas to the controls that are there in the OS for the user's vision... I don't know what controls are there but the UA should acknolwedge that. Without leaking info to the website.

Hadley: Sounds like we have TAG opinions on this. Happy to support APA on this. Should we put a comment to reflect our opinions on this?

Matthew: We just had a chat that seem to be on the same page. The direction we'd like to see. They already say the UA suggestion, so maybe we take that from them because they wrote it down already. Discretely, 1-2 questions Lola raised, most impotrantly the dev confusion. And UA feature. I'd like to say something about motion gap.

Matthew: We (APA) looked at it, had most of the suggestions in the a11y considerations section that we would have raised. Leaves developer ergonomics. Need to draft a comment.

Matthew to write comment