[css-overflow-5] Focus order of generated controls

[flackr]

Scroll markers #10720 and scroll buttons #10722 add focusable controls around the scrolling content. This issue is intended to cover the details of how they should be focused, which likely also implies what their relative tree order should be.

For the purposes of discussion let's consider a hypothetical DOM:

<input id=before-scroller>
<div class=scroller>
  <input id=item1>
  <input id=item2>
  ...
</div>
<input id=after-scroller>

Styled with scroll markers and/or scroll buttons, e.g.:

.scroller {
  scroll-marker-group: before | after;
}
.scroller::scroll-button(inline-start) {
  content: "<" / "Previous page";
}
.scroller::scroll-button(inline-end) {
  content: ">" / "Next page";
}

What should the tab order be, when you start on #before-scroller and tab forward? For the sake of making it easier to discuss, I think it might be helpful to define some terms:

• Buttons: All scroll-buttons, ordered by previous buttons, next buttons
• Previous buttons: All scroll-buttons navigating back, i.e. the block-start and inline-start directions in this order.
• Next buttons: All scroll-buttons navigating forward, i.e. the inline-end and block-end direction directions in this order.
• Markers: The scroll marker group, resulting in the active marker being focused.
• Before markers: The scroll-marker-group if it is scroll-marker-group: before.
• After markers: The scroll-marker-group if it is scroll-marker-group: after.
• Content: Focus goes through the content of the scroller, i.e. #item1, #item2

Options:

1. Buttons, Before Markers, Content, After Markers
2. Before Markers, Buttons, Content, After Markers
3. Before Markers, Previous buttons, Content, Next buttons, After Markers
4. Previous buttons, Before Markers, Content, After Markers, Next buttons

Some existing examples:

• The aria apg demo and @argyleink's carousel has the previous and next buttons next to each other in focus order despite the latter having them visually separated.

Note:

• Once you interact with a control, we can change the next tab stop to be the targeted content similar to how following an anchor link sets the sequential focus navigation starting point. This means that clicking on a marker or clicking on next page, and then tabbing could be defined to focus into the contents of the linked item / page regardless of the normal next item in tab order.

[flackr]

I propose we go with option 2: Before Markers, Buttons, Content, After Markers. The navigation buttons feel as if they should be directly adjacent to the content, and as suggested by aria discussions adjacent in focus order even if not visually adjacent.

One additional detail is if the scolling container itself is focusable where does it occur, my proposal would be that it is immediately before the content as this would more often result in a natural visual progression of focus indication (instead of having the container be first), i.e.
Before Markers, Buttons, Container, Content, After Markers.

[tabatkins]

I've gone ahead and reflected option 2 into the spec; we can change it if we decide differently.

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-5] Focus order of generated controls, and agreed to the following:

• RESOLVED: choose option 2 in the issue

The full IRC log of that discussion

<dbaron> flackr: we need a well defined focus order when you tab through these generated controls
<dbaron> flackr: aria has guidelines for rough expectation of focus in a carousel-like experience
<dbaron> flackr: this prpoosal aligns with that order
<dbaron> flackr: the buttons are together and occur before the contents of the scroller
<dbaron> flackr: the marker's position is before or after the scrolling contents depending on the scroll-marker-group property
<dbaron> flackr: my proposal is that the buttons... if the markers are before they come first, then the buttons, then the content, then the markers if they come after
<dbaron> flackr: see my last comment in the issue
<dbaron> flackr: one additional thing is question of when to focus the scroll container itself
<TabAtkins> +1 to the Option 2 in the issue
<dbaron> flackr: I think it still makes sense given the previous resolution for the container to come before the content.
<fantasai> Seems reasonable
<dbaron> flackr: so before markers, buttons, container, content, after markers
<vmpstr> q+
<dbaron> astearns: haven't thought about this deeply, but the container focus is not meant to contain the button or makrers?
<dbaron> flackr: right
<dbaron> flackr: focusing the container is typically done to scroll the container, so makes sense as a separate item between the controls
<astearns> ack vmpstr
<dbaron> vmpstr: when focusing the content that means tabbing through all the focus items within the carousel before extiing to the after markers
<ydaniv> +1
<dbaron> flackr: correct
<astearns> ack fantasai
<dbaron> fantasai: by before markers and after markers do you mean ::before and ::after pseudos?
<dbaron> flackr: referring to whether scroll-marker-group property says before or after
<dbaron> fantasai: I see
<dbaron> fantasai: how do we typically lay out the order of a scroll container and its scrollbars? Is that relevant here?
<TabAtkins> ::scroll-marker-group (before), ::scroll-button()s, scroller, scroller's contents, ::scroll-marker-group (after)
<dbaron> flackr: the scroll bars are not in the focus order
<dbaron> flackr: I think if they were ???... we're treating generaed controls as siblings of the scroller
<dbaron> fantasai: ... seems fine
<dbaron> flackr: I think with implementation and practice using it we'll see if it seems right, but this ist rying to follow best practices for these designs
<dbaron> astearns: what's the use of focusing markers?
<dbaron> flackr: User can tab to active marker, and use arrow keys to select which marker they want
<dbaron> TabAtkins: markers are links
<dbaron> astearns: I suppose AT could say "tab 2 of 4 is active"
<dbaron> flackr: exactly
<dbaron> astearns: sounds like we're converging on option 2, and we'll see how it goes
<dbaron> RESOLVED: choose option 2 in the issue