[csswg-drafts] [css-overflow-5]: calling focus on the carousel / scroll container (#12240)

smhigley has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-overflow-5]: calling focus on the carousel / scroll container ==
## Current behavior

Adding `::scroll-marker-group` and scroll markers to an element appears to make it focusable but not in the tab order, similar to adding `tabindex="-1"` to the element.

Saving a reference to the scroll container and calling `element.focus()` moves focus to the scroll container itself, not to either the inner scroll buttons or scroll marker group. This can be verified either by running a screen reader or inspecting the related FocusEvent's `event.target` (which currently points to pseudo-elements when you tab to them, but points to the scroll container if you programmatically call focus).

## Problem

There are two related issues around handling `.focus()` calls, one with the current behavior, and the other with the API in general.

### 1. Current behavior

It seems pretty clear to me that making an element into a scroll container does not imply an authorial intent for that element to itself be interactive or exposed to assistive tech users. Instead, the scroll buttons, markers, and scrolling content are the semantically relevant controls. In this basic case, I don't think the scroll container element should become focusable just because of `::scroll-marker-group` -- it likely does not have (and often _should_ not have) an interactive role and accessible name that would support it being focusable and accessible.

By default, it seems like the best course of action would be to either set focus to the first internal focusable element (which is currently a scroll button if it exists, and the scroll markers if it doesn't), or always set it to the scroll markers. I'm curious on other folks' thoughts on which it should be, since generally I would lean towards moving focus to the scroll markers, but having the scroll buttons before them in the tab order complicates that.

I personally think authors need the ability to call focus on the prev/next scroll buttons and scroll marker group separately, so perhaps figuring out how to expose that would solve this question (and the next) as well.

### 2. Resolving `.focus()` on focusable scroll containers

This problem extends beyond resolving the current issue with focusing what are otherwise unfocusable scroll containers. If an author has intentionally created a focusable scroll container, then calling `scrollContainerElement.focus()` would need to send focus directly to the element. Authors would still need a way to send focus to the scroll marker/button controls though, separately from the container element.

Since pseudo-elements are not currently accessible in JS, and also are type Element and do not support the `.focus()` method, it probably needs someone more creative than I am right now to figure out how this would be solved 😅

(As a brief top-of-mind example on why this would be necessary -- consider an overflow container with `tabindex="-1"` to handle fallback focus if all content is deleted and there is no longer overflow. However, when sending focus to the region while it is interactive, the author would want to move focus directly to the scroll buttons/markers. Or a scenario where the author has made custom keyboard commands to jump to a specific slide, and needs to manage focus when doing so.)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12240 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 28 May 2025 01:35:25 UTC