Xiaocheng: they are asking us to review 4 different features... we should ask them to split into 4 different reviews. Also we should ask Matthew to take a look as there are A11Y considerations...

.. each feature targets a different part...

Hadley: you think we'll have conversations about each?

Xiaocheng: yes.

Hadley: them my vote would be...

Matthew: Several issues split out. Inert is the juciest from my perspective. APA had some questions about the scrolling stuff, some of which were answered by the fact that it fits into the overall proposal. Where else do you see this being used? It would be a good idea to start with an idea of what the current status is. Short term availability. And I have some other questions.

Robert: In Chrome 135, scroll markers, scroll buttons, columns, interactivity are available. Element-based scroll markers aren't.

Matthew: Inert will be an in-depth discussion. Some questions about scroll buttons.

Matthew: There's a lot of good stuff that's come out of this trend to avoid needing Javascript. Generally we're supportive, but we also have some concerns, particularly about inert. But also when you're doing a big thing, wouldn't create a single primitive just like ordering in support of masonry. Makes sense to look at what can be split out to solve other problems.

CSS Scroll Buttons - @xiaochengh

Matthew: TAG had an understanding that the scroll markers and buttons: is that intended to be used for something wider than carousels? Roadmap for where that's going to be used?

Robert: Intention for scroll markers is that they're very similar to a table of contents. Authors could use this for other use cases where a list of anchor points would be useful. For scroll buttons, they're equivalent to having a JS-based button to scroll an associated area. Many ARIA authoring guidelines suggest this for carousels. It sometimes shows up in other contexts, like with a 'view more' button to scroll the page down. Adds this automatically without needing script.

Matthew: Might it be used in a 'back to top' situation? Or 'back to top of section'?

Robert: Could. Scroll buttons don't provide that specific thing, but we could add it as a value. The intention is for that kind of thing for any scrollable region.

Matthew: APA got looped in on this through a CSSWG member labling the issue. It was a discussion of scroll buttons, and we couldn't find the overall explainer. Nobody's fault. We're looking at tweaking the process so the TAG sends us explainers. One issue we had, and it sounds like these are separate, but just to ask. You say "scrollable regions". In a Terms & Conditions, that's a scrollable area. Could they be applied in that case? Or just to scroll the viewport? Merge this with the browser's scrolling controls?

Robert: Can be associated with any scrollable region, so Ts&Cs woudl work. Haven't spec'ed how these would be attached for the root scroller, but they should work there too. This isn't the browser's affordance for scolling though; it's the developer's affordance. We wouldn't add scroll buttons by default.

Matthew: Would you end up with both?

Robert: This has nothing to do with the scroll bar.

Matthew: There was a lot of concern about focus order. We thought that if this were applied to scrolling in general, it might result in extremely different keyboard interaction. Now you press up or down, and there was a concern that this might need focus. But this is a button going to a particular place.

Robert: And adding the button doesn't prevent normal scrolling. It's the same as if the author wrote a <button>.

Matthew: Describing the problem is the most difficult part. ...

CSS inert - @xiaochengh

Matthew: APA left a comment on the TAG review. This is doing much more than CSS often does. How many of you have seen the APA-specific feedback? Robert replied. Going through APA's still-current comments.

Matthew: Why wasn't the original proposal sufficient? Overflow interactivity. It's not mentioned much in the explainer.

Robert: For the specific case of making a carousel, it's perfectly sufficient. When we discussed this in CSSWG, people were concerned that cases weren't handled by this. Scott raised concerns that while we're making it possible to automatically handle some use cases, we should handle some other ones. For carousels, it doesn't require the per-element interactivity thing, in most cases. There are experiences where authors will have animations as things scroll, so they're technically in the scroll port even though they're not visible yet. Maybe we could work around it.

Matthew: So, to make it more generally applicable. Some of Alice and Scott's cases, you couldn't do with that properrty, but don't know how effectively you can do them with inert. There are still some things you can't do. In the explainer, it cites the ARIA authoring practides, and I know Open-UI worked on a range of carousels, but for specifically accessible carousels, the APG one was the main cited one. There are different ways you can do it, and I've cited a few. Paul who's also in CSSWG. Some don't make the out-of-view content inert because it's part of a navigation. Some don't do it and still provide alternate means of navigation, and make inert a progressive enhancement using HTML with some JS. Some are like tab panels. When you were looking at this, did you look at other keyboard navigation patterns.

Robert: APG one doesn't even handle arrow keys. I looked at several. Cited APG as the authoritative one, but I thought abuot other experiences. That's why it's not just a default thing, but it depends on the experienc eyou're building. A list of contents probably makes sense to have the offscreen content in the tab order. When you have 100s of items, and many focusable things in each item, (e.g. the APG one with slides), it's a better epxerience for accessibility and keyboard navigation to have the separate controls, and make just the current pane interactive. Support both of those, with developer guidance.

Matthew: There are lots of types of carousels, including where cards have interactive and non-interactive content. What's insufficient about HTML's inert attribute?

Robert: You have to manage that in script, and tracking what's in view is non-trivial. One bit advantage over the APG example is that the carousels we're advocating are scolling containers. They advertise as having more content in the direction they pan. When you do that, it's complicated to get the events correct to update the inert attribute as you scroll.

Matthew: Looking at the discussion on this thread, your approach looked entirely reasonable. My worry, and APA's, were the implications of following this approach. We have a lot of experience of mistakes like this. People who accidentally use this even though they shouldn't. Accessibility consultants see so many instances of using ARIA when you shouldn't. This is something with no visual effects which could render a whole site useless to someone using AT. Can see it getting copy+pasted all over the place. Mitigations against things like that? Devtools could highlight inert parts of the page?

Robert: Unlike accessible-name, inert affects interactivity for all users, not just AT users.

Matthew: That helps.

Robert: Having some visual indication of this in devtools would be a good idea. I liked on the CSS discussion, Scott suggested something very similar, to have a visual treatment of those elements to make it obvious. Fits in devtools.

Matthew: Would have to be by-default until the user turns it off.

Matthew: Possibility of escaping the inertness, maybe unintentionally. Alice's comment about limiting it to the top layer. And if you have the ability to un-inert stuff, that's quite different from the HTML one, which is absolute. They're both called inert, which is confusing.

Robert: HTML attribute only has a value to make something inert. No opposite value. CSS has that, plus a new value that's not present in HTML. Not that confusing. HTML has a hidden attribute, while CSS has visibility: hidden|visible.

Matthew: The effect of this one is invisible. If you inert a subtree, you might test by clicking it, but if other things get un-inerted, you wouldn't know. Developer education. It's different because you can't see the effect. Asking you to limit the un-inerting to teh top layer might go against how CSS works. Limiting risk.

Robert: One thing we did, if you have content in the otp layer, you cant un-inert content outside it. That makes sure that if you have top-layer-modal UIs, you can't make deep content interactive. I understand the concerns: this doen't feel akin to other CSS properties. But today I added that a requirement to use the top layer eliminates some use cases like component modals. Must interact with part before you can use the rest of the component, but don't want that to prevent interaction with the rest of the page. Don't want it to pop above things outside the component. That's why it's generally useful to provide un-inerting. Good use cases where the top layer doesn't provide needed capabilities.

Matthew: Interesting. An ask on the comment thread was "couldn't we do a more thorough study of these mechanisms". You might say "we did that; here's a pointer". If we'd like to support some use cases, right now they're supported by frameworks and libraries. Might use the inert attribute or other mechanisms. How much JS code are we going to save by having this extra feature?

Robert: Doing this today, you have to change the structure of your DOM so the interactive content is outside the inert content. Or you can modify the tabindexes, but that's much worse for accessibility, because that content is still present. Either the libraries carefully ensure the interactive content is at the top of the DOM, which has structural and layout limitations. Or tricks with tabindex, which provides very different experiences between regular and AT users.

Matthew: Sounds like you're expecting that you can eliminate all the scripting. Is there anything left for JS to manage?

Robert: Goal is that you shouldn't need to use script, especially in support of users who disable script in their browser, it should be fully functional. There's probably always edge cases where it doesn't do exactly what you want, so you have to reach for script.

Matthew: For accessibility stuff, there's this view that to make it accessible it must not have JS. For a long time that was true. It's been such a long time since we gave up on the notion that there would be no-script browsers. Know why you want to move things out of the main thread. Anchor positioning is so good for accessibility. Carousels suck for accessiblity and usability: users often miss everything except the first slide. But designers want to use them, so you're making them better. If there was something devtools could do, fairly aggressively, that would be good. We have some things to think about, and maybe we can make suggestions.

---

Matthew: We didn't talk much about stylable columns because we didn't review it as extensively. Anything we should be aware of?

Robert: column-boxes that we lay things into. Styling is quite limited. Most properties don't apply; no full layout boxes. No font-size. Lets authors add things to physical locations of column boxes. It's the combination of features that make it really powerful. Scroll markers on columns makes an automatically-paginated carousel, but it uses existing primitives rather than inventing new things.

Matthew: Was there ever a stage where people researched whether there should be an element to handle this?

Robert: Yes. We started from elements, 5 years ago from an element perspective. Through the research of the ways developers want to create these experiences. It was going to be extremely difficult to pick a particular element behavior. Would be best to provide the features that authors could combine. It's possibel to revisit an element with the features in mind. Build an element from these features, which matches the <selectlist> approach.

Matthew: Yes, would be surprised if people could come to consensus on an element.

Matthew: Just before this call, there were some issues with customizable select. Didn't review the PR.

Robert: Saw it but haven't looked into it.

Tab: Same.

Matthew: Comments from Scott and Sarah Higgley. On carousels, everything makes sense, but I'm concerned about how people will use this in other places. Use cases that you've mentioned sound really good, and like a hassle to support now. There are tradeoffs in everything: if you have to structure your DOM in a certain way; people have tech debt which prevents them from making things accessible. Making people structure their DOM in a certain way might be far too restrictive. But with great power comes great responsibility. Undersatnd much more about motivations and tradeoffs. You're into the possibility of providing more help for developers. Wise for us to check out the latest comments on the actual PR. The worry about it having effects without being visible is my biggest concern.

Matthew: I still need to dig into the concern around un-inerting and live regions. Certain things we might be able to have added for developer education. Still some technical concerns that I'd like to ensure we understand. But that was very helpful. We'll see if we can offer anything constructive.

Matthew: What should we weight differently?

Robert: Inerting affects all users, not just AT users. Important to emphasize to authors that they've made authors inert, but it'll still affect regular users.

Matthew: can we talk about this?

we review draft text of a comment on 1037

Xiaocheng: right now are we expecting CSS pseudo elements to AT?

Lola: that's part of the issue... "you can only fill in the accessibile name via CSS content" ... so just the left and right scolls are [being exposed to AT]... The dots at the bottom of the carousel are not being exposed to AT.

Xiaocheng: regarding scroll buttons... is our position "this will be good if they can be properly exposed to AT with the corrct names and roles"?

Lola: yes - and I think we need to get more information... Prompting for more questioning. Yes if we can expose that then that's what we want.

Matthew: keyboard wise they are in the focus order... The a11y tree in [chrome] canary - they don't names or roles... The way that scroll buttons are described... I don't see a problem, assuming they are implementing correctly... the general mechanisms seems fine. But there is a type of carousel where the scroll buttons move the focus and do the scrolling. But you've also got carousels where the scroll button just moves the slide and not the focus... In this particular case, the feedback that Lola highlighted, the focus didn't move and person using the screen reader didn't get any feedback. Then I realized the examples don't expose the expected information. So you end up in a situation where some of the info you have to provide in the normal way... ARIA... but if you want the scroll buttons to make an announcement then you would need a liveregion which means you'd need javascript and the whole point of this is to not need javascript...

Also: Lola has seen more examples...

Xiaocheng: that's very reasonable.

Hadley: my thoughts are editorial ... I think we should bring out specific actions with formatting... Make clear what we're asking of them.

Matthew: small bit of context ... Jeffrey was suggesting focus on what we agree on... We subsequently found more example... The first part is more questions... The second part is much more "please don't ship this but we want to work with you..."

Hadley: suggests formatting changes

Dan: let's change the formatting and ship it.

Lola: I thought it might be a good idea for someone from TAG to be in the CSS wg meetings [when this is discussed] ... so when this comes back to TAG there is more context. Gives us a bit of inside knowledge... I spoke to someone in the CSS ... the meeting times are doable... Possible Peter could act as a go-between...

Hadley: if anyone has a plan in mind (to attend) then by all means execute but otherwise let's rephrase the comment ... there are a lot of things that need our time.

Lola: I can do the formatting.

Hadley: the goal should be - is it immediately clear what the TAG wants them to do.

Action: Lola to do the formatting and post it.

Xiaocheng: what about CSS inert?

Lola: our recommendation is that they are fine to do everything except inert...

Hadley: 'we are comfortable with everything except inert' would be good wording.

Xiaocheng: OK.

Matthew: leave open with pending external feedback.

Hadley: ok we may want to put in the comment "we know you have a deadline."