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

Dan: we had some feedback….

Lola: haven’t gone through it thoroughly yet… ultimate question is: what do we want to happen here? As far as I know… carousel is in chrome behind a feature flag…

we agree to re-visit it next week and that Matthew needs to look at this

Dan: we had some feedback….

Lola: haven’t gone through it thoroughly yet… ultimate question is: what do we want to happen here? As far as I know… carousel is in chrome behind a feature flag…

we agree to re-visit it next week and that Matthew needs to look at this

no update

Matthew: there were significant a11y concerns. You could un-innert something that was innert, and this seems to be a good thing. Next steps would be for the people participating to sync up, and if this is sufficient. We can't close this just yet - but they heard our feedback and made a good change. There's issues potentially related to aria "role" and this that I'll like to raise with the TAG.

Matthew: will bump this to next week.

Xioacheng: will you also raise this with the CSS working group?

Matthew: no, I need to raise them with the TAG first.

Matthew: The outcome of various people expressing concern having the interactivity ... addressed the concern. I guess we need ot make a judgement on whether that is sufficient ot close. I can follow-up. Jeffrey may be able to tell us whether to leave at that. Someone poeinting out if you're using AT, it'd be hard to find stuff - it used to be difficult - there is a lot of issues with carousels. We discussed in breakout B - checking how serious it might be.

Martin: Did you see Tab's CAS idea: https://gist.github.com/tabatkins/4074abaf486af5b3f7ac289737e216e4

Matthew: Looks cool, also discussed in braekout B. Discusses some of the gaps. Lola is involved in some discussions on that. It seems so much more better way to do it.

Martin: ... there is a standard list of ... Much easier to author than putting the attributes in.

Matthew: Right now, you can key your CSS styles of the semantic state of the element. If form is invalid, that encourages you to set that correctly before. The challenge of coming up with something better rather than coming up with ids. This could take care a lot of problems.

Martin: ... This is generally to say that the CSS works by default.

Matthew: Will catch up with L and X, and come back.

Matthew: Would be good to discuss with Lola, Jeffrey, Xiaocheng. Don't want accidental uninterting. They decided to mirror the HTML attribute. That seems like a good thing for accessibility. Not sure how we feel about the rest of it. But that's the biggest change. Immediate changes for us would be, is this enough? Sufficient to make TAG happy or satisfied with concerns? Next question would be, is this how it's going to stay? Maybe this is a pause rather than a change of direction. On that front, want to share a link, they're discussing in HTML and we just talked about it in APA call. Connect HTML spec up to new CSS interactivity property #10956 https://github.com/whatwg/html/pull/10956 does the harmonization between and HTML and CSS. What we want to figure out is, are they specifying this in terms of how HTML has always been in that you can't uninert stuff, or does this override the change we liked in the carousel space? Will this revert back to it being uninertable via CSS, or will it be the behavior we do want? Discussion is ongoing?

Lola: First question is, is this enough. I don't think so. In the final comment, @flackr says we are going to explore some things. They've updated explainer with alternatives considered. There are still additional properties they're exploring. Not sure if you've read https://www.sarasoueidan.com/blog/css-carousels-accessibility/#update%3A-may-29th%2C-2025. Sara is a11y expert. She has written this post breaking down all the issues with CSS Carousel in lots of detail.

Matthew: I've seen this, she's got the same concern where CSS is now in the business of adding roles to elements. They're already adding roles to pseudos, but adding roles to acutal elements is even worse.

Lola: Opens the door to mismatch of responsibilities. Things that HTML is responsible for, that CSS is responsible for, carousels wants to step into HTML's territories. So I'm opposed to this implementation of CSS carousel's as-is. Don't think the fixes to inert is enough based on this.

Matthew: I agree. Need to confirm about the roles stuff, but seems wholly inappropriate if they're doing that. Doing it with pseudos is already blurring the line. If they start doing it with elements... The other thing is, they're giving devs a choice between exposing as tags or links. Not good. CSS liason mentioned that Scott O'Hara mentioned, that the thing where they want to auto-inert slides that aren't in view, from some perspective that seems reasonable, it completely breaks virtual cursor. E.g. if you are iOS voiceover user, getting to next item , you can't do it because it's not in a11y tree anymore. Some users it would be better for, but for significant number it's worse.

Lola: Sounds to me like this tech is not ready. Not ready to be standardized at least.

Matthew: It worries me. I appreciate the progress with moving away from JS, like anchor pos is great, grid, but they've bitten off complicated widget pattern. I wanted to be supportive of it because devs want to do this and it gets done poorly, so if we can make it suck less and it can be more accessible that's good. But the more we go into it it seems less like that's happening. They've shipped so much, and in a generalized way, the parts don't add up.

Lola: My position is, regarless of what they've done and plan to do, this is TAG's position. Doesn't mean we have to back it. My position is it's not ready. A concern I have as well is that there don't seem to be many a11y pros in the CSSWG. It's one of the bigger and more active WGs in the W3C. We don't want to take on too much work and have expectation that TAG will come into your WG and personally direct things, but there needs to be a requirement now that CSSWG needs people to participate to give a11y guidance.

Matthew: I have action points for what you suggested. I will check up on the business of giving roles to elements from CSS. While drafting the comment we can also show it to Alice. On subject of getting more a11y representation in CSSWG, yes. Paul Grenier is participating and flagging stuff to APA. We need to find a way to support CSS and get that feedback ASAP. They're attracting people who know stuff -- Scott, Sara, Paul...maybe they're attracting them too late. APA is also struggling with this. Only finding out about it after it's shipped, only hear about it because of Paul. But too late. So part of the answer is to encourage people to go through a11y review sooner, through TAG or APA.

Lola: Makes sense to me. Who are the CSSWG chairs, can we reach out to them? Alan Stearns, Rossen Atanassov. Immediate next steps: let's figure out the comment we want to leave on this. Should discuss with more of the group. Let's put it in next plenary.

Matthew: Are we saying, by next plenary, we have draft comment on this?

Lola: Yes if it's not too much. Else we should have a position at least. I will add to agenda for next plenary.

Lola: Concern of possible antagonism between CSSWG and APA. Worried about the feedback we’re seeing from a11y pros.

Matthew: The outcome of getting more a11y review is great. But issue seems to be mainly with features that come to the CSSWG already largely complete. The issue is not with the CSSWG itself, who has members that care deeply about a11y. Talking with the chairs could help alleviate this. Process improvements about CG's is good, about stuff getting more scrutiny as it gains "traction", and defining what "traction" means.

Lola: CSSWG gets stuff as first point of access, right?

Matthew: Right, so those process changes wouldn't help here. But would they if there was a CSS CG?

Lola: Privacy CG does this well. Other people are thinking about this -- maybe we can discuss at TPAC.

Matthew: Still working on proposed comment - I have an outline in the private thread - could you check anything is missing?

Lola: Many documented UX issues. Trying to make the pattern native to the web, without addressing the known issues, isn't a good idea.

Jeffrey: This is a reasonable thing for us to say. We could recommend reconsidering based on this. I think they'll say people want to do this kind of UI so we are making it work better.

Lola: Sara's 'blog post was illuminating.

Matthew: I'll include that and think about how to more strognly word the caution, in light of what we've found doing the review.

Matthew: Found out a couple of things. There is a few things that we were discussing that I related to this one.

… Recap: We were pleased that the implementor's reflected the HTML inertion behavior

… but we still have several concerns, these include issues around whether the CSS is going to apply semantics on the page

… concerns me that it applies semantics to pseudo elements

… there's a change in HTML to harmonize HTML and CSS, and they've agreed on that you can't uninert

… we've talked about Cascading Attribute Sheets as an alternative solution

… for the other one, I don't see a solution. If you do inerts (i.e., hide from a11y tree), there is no way to explore them using the virtual cursor, which is a very important navigation mechanism, which is especially useful on mobile (rotor in VoiceOver), which allows you to skip between segments like headlines, landmarks etc.

… One potential way around that would be that the user agent would be aware of this, but this would take a lot of effort

… Lot of related things are going on at the same time, think we should have a comment that combines all these

… I think we are concerned about this more than we were before. I'm happy to draft the comment, so we have it available next week.

Lola: Totally fine. Jeffrey also mentioned that we can link to Scott O'Hara's blogpost. If there are things in the blogpost, you can refer to them. Let's talk about this next week.

Matthew: Xiaocheng, you are also on this issue. Thoughts?

Xiaocheng: Don't have anything to add. Waiting for you to finish the comment.

Lola: Matt, you mentioned you'd have carousels comment ready?

Matthew: I can paste what I've got. Want to add citation. Might need a little bit of work. Covers the big areas we talked about, need to add link for virtual cursor. It's here: https://github.com/w3ctag/design-reviews-private-brainstorming/issues/97#issuecomment-3140075595 Not completely done but almost all there. Each day I make half of the remaining progress :)

Jeffrey: Cascading attributes issue linked from gap issue. Is that related to carousel?

Matthew: Might be useful for carousel. Not just the idref thing, also the imparting roles thing.

Jeffrey: So not quite ready to approve, but people can pay attention.

Matthew: I'll ping in Slack when done.

Matthew: It's taken me longer to get to this than I'd hoped, but I need to cite sources properly. What we discussed last week was broadly OK with the rough outline of the proposal. Will post that before plenary. Computer replacement took some time.