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