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

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

Hi @flackr, thanks again to you and your colleagues for joining the breakout last Tuesday, we know there's a deadline of April 1st so we appreciate your patience. It was most helpful to have the development of the proposals explained, and helped us better understand the tradeoffs made.

As with APA, TAG is happy to see the continuation of the trend of moving common patterns away from JS, and into HTML and CSS, but are still concerned regarding CSS inert, and have some questions about what is exposed to assistive technologies around the action of scroll buttons.

# Accessible interaction and exposed info

We've noticed some AT users in the wild facing some [barriers whilst interacting with the carousel examples](https://dragonscave.space/@jscholes/114209673997034655) - specifically, these include, a lack of feedback from AT when the scroll buttons are used.

This gave rise to a couple of questions about the behavior of scroll buttons, and the composite carousel as a whole...

## Scroll buttons (inside carousels vs outside)

What is the expected behavior of carousel scrolling buttons from the perspective of AT users? In a carousel there are two common options:

1. Focus moving to the new slide (this can actually be quite jarring, but useful in some cases).

2. A live-region-based (or similar) announcement that the slide has changed. This fits many carousels, but not other use cases for scroll buttons.

**Is there a way for the author to request which happens?**

Outside of carousels, it seems like moving focus works as a default (or possibly exclusively) could work best. But inside a carousel, there might be reasons for either.

Another challenge here: if the UA is expected to do some of the work on providing feedback to AT (such as making announcements via live regions), then authors may be confused at the need to provide appropriate accessible names and roles (per next section).

## Exposed info about the carousel

One important goal of the carousels pattern is to make it easier to make accessible carousels. **Even with the features discussed so far, the user of assistive technologies will need the carousel, and slides, to have accessible names and appropriate roles** (as per this [APG example](https://www.w3.org/WAI/ARIA/apg/patterns/carousel/examples/carousel-1-prev-next/)).

This includes a name and role for the carousel as a whole (which allows the user to easily find the main content - especially useful if the buttons move the slides but not the focus).

It is also helpful for slides to have names such as "Slide X of Y" in some cases (more so if they are containers of other elements, but again this is an example of different variants of carousels for different purposes).

# `interactivity: inert`

As it's currently specified, it doesn't seem to be a good fit for CSS, nor does it fully address some of the concerns that have been raised by the accessibility (development and auditing) community. 

There are a couple of key areas causing us concern about the fit with both CSS and existing platform primitives.

1. The use of CSS for non-styling purposes, which couples other stuff with the rendering pipeline, which may lead to unexpected issues (for example: we need to recalculate style to check element editability and hence focusability, due to `-webkit-user-modify`).

2. The concerns around DX: accidental inerting, or un-inerting; confusion over behavioral differences between CSS and HTML inert. It seems there is a significant risk of these concerns causing long-term problems.

Several concerns have been linked before in this thread. Here are a couple more that bear considering:

* Detailed info and concerns, written since the CSS WG's decision, from @smhigley [about the sorts of DX issues that could occur in practice](https://github.com/whatwg/html/pull/10956#issuecomment-2734778015) - echoed by accessibility auditors.

* [Prior concerns from Maciej Stachowiak (WebKit) about the direction of travel in terms of affecting interactivity from within CSS](https://github.com/WICG/inert/issues/69#issuecomment-489915986).

**We feel it's important to pause on this part of the overall proposal, with the aim of making the design a good fit for CSS** (or finding an alternative approach), and for these and the other issues raised.

One architectural question came up in our discussion: **are the CSS features around interaction (`user-select`, `pointer-events`, `interactivity`) being specified because sometimes it would be really nice to apply an HTML attribute to all the elements that match a selector? If so, perhaps we could work on that cross-cutting requirement?**

Finally, it would also be really helpful if you could **add more detail to the explainer to cover `overflow-interactivity` and any other additional approaches considered**, as this would help everyone in future reference the use cases we've been discussing. There was a lot of support for `overflow-interactivity` to begin with on [CSSWG #10711](w3c/csswg-drafts#10711#issuecomment-2276867696) and, whilst we understand your desire to generalize the approach, in light of the concerns around `interactivity`, does it make sense to revisit this possible approach (and perhaps the one suggested above)?

# Next steps
- 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?
- 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.
- Add more detail to the explainer to cover `overflow-interactivity` and any additional approaches that have been considered.
- 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 this is ready to be shipped as is on the proposed date.

We can see a lot of work has gone into this proposal and as mentioned above, are happy to see more common patterns being moved into HTML and CSS. We're keen to keep working with you as things develop and happy to support where it’s useful. We look forward to continuing the conversation.

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

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