Re: [w3ctag/design-reviews] CSS Overflow Navigation Controls (Carousels) (Issue #1037)

flackr left a comment (w3ctag/design-reviews#1037)

> Address ARIA questions around scrolling & focus behaviour for AT users, specifically: is there a way for the author to choose how focus is communicated to the AT?

Authors can continue to use live-regions which work in combination with interactivity to announce the new content. In the demo at https://flackr.github.io/web-demos/css-overflow/carousel/, the current page is announced as it becomes no longer inert. Focus is never forcibly moved. If the buttons or markers are used to move to the next page focus remains on the button or marker as it does in the APG examples or many javascript based existing components. Focus will be lost if an item on the previously active page was focused and the user scrolls / swipes it away.

> Address carousel name and role issue; carousels need accessible names and roles and we're not clear on how this is being done, if it is.

There are at least two major use cases for scroll markers:
1. A table of contents, e.g. navigation links to various points in the scrolling content,
2. Carousels / tabs.

Depending on which use case the developer is building, different roles are expected to be used. As such, we had left it for the developer to set the tabpanel role on the target if indeed that was the pattern they were building. For the generated pseudo-elements, the UA automatically sets the roles, currently to tablist / tab. However, considering all of the discussions we have had in this area we are considering an explicit api for declaring that the modality is tab-like which will influence a number of behaviors, see https://github.com/w3c/csswg-drafts/issues/12122.

> Add more detail to the explainer to cover overflow-interactivity and any additional approaches that have been considered.

I've updated the explainer to [include this in the alternatives considered](https://github.com/w3c/csswg-drafts/blob/main/css-overflow-5/carousel-explainer.md#overflow-interactivity-inert). The TLDR is that while overflow-interactivity could be used for simple use cases it had many issues as soon as authors try to create interesting effects such as card stacks or peeking into previous / next content. The current API aims to make what authors can do with the inert attribute usable in dynamic cases without requiring extensive scripting. There are still additional properties we are exploring, e.g. https://github.com/w3c/csswg-drafts/issues/11553.

> Spend more time on interactivity. The CSSWG may need to revisit the approach and/or find an alternative that better fits within CSS principles, as well as address the accessibility concerns. We don't think inert is ready to be shipped as is on the proposed date.

While we think that there are use cases for uninerting, out of caution for the risks raised we have removed the ability to uninert content making `interactivity: inert` equivalent to the inert HTML attribute. While `interactivity` (or the HTML inert property) is not the only feature needed in this space, we believe that like HTML inert, `interactivity` will help enable the creation of the carousel design pattern.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1037#issuecomment-2831227912
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1037/2831227912@github.com>