Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[carousel] How to make scroll-markers / navigation buttons? #1031

Open
flackr opened this issue Apr 5, 2024 · 5 comments
Open

[carousel] How to make scroll-markers / navigation buttons? #1031

flackr opened this issue Apr 5, 2024 · 5 comments

Comments

@flackr
Copy link

flackr commented Apr 5, 2024

I've been working on a set of features which would allow developers to construct carousel experiences by styling regular DOM components. There is an explainer, prototype, and demos at https://github.com/flackr/carousel/ which I'd be happy to talk through. Two features in particular feel like they have a fair bit of overlap with the invokers and focusgroup proposals:

  1. Scroll buttons sound like they could be explained and authored with a few new invoker actions for scrolling containers (e.g. scrollBlockForward).
  2. Scroll markers are a combination of actions (scroll a target into view), roving tab-index to tab focus only the currently active marker, and scroll triggered state.

I was hoping that some discussion might help inform the design of the scroll-marker api when trying to create proper elements which have scroll marker behavior - see flackr/carousel#6 for some prior discussion on this. #1030 is related but only solves one part of the desired behavior.

In particular:

One thing that might help is thinking about how configurable the way you interact with these should be. E.g. should the focusgroup behavior be optional? WAI suggests it can be tabs with focus-group / radio-button roving tab-index style navigation or buttons where each is a tab stop.

@scottaohara
Copy link
Collaborator

scottaohara commented Apr 11, 2024

is it possible to make the items that are not presently in view inert? otherwise i think there are some conflicts with what this is trying to do (using scroll markers to manipulate the overflow content of the carousel) vs what would make for good UX for keyboard/AT users (the content that is not presently in view should not be focusable/accessible until the user explicitly requests that content be visible/accessible)

note: i see that you're aware of the inert problem

@flackr
Copy link
Author

flackr commented Apr 11, 2024

is it possible to make the items that are not presently in view inert?

This is called out as a separate primitive to figure out as part of the overall offering, https://github.com/flackr/carousel/tree/main/inert. Right now, you can only change inertness via an attribute, so you'd have to do it in script at the point where a different item was brought into view, but if we have a css property to control inertness then this could be part of the standard markup, which I have an example for at https://github.com/flackr/carousel/tree/main/inert#carousel

I do think there are use cases for scroll markers in non-carousel designs (e.g. effectively working like anchor links, but also having some highlight effect while you're in that section). You can see an example of something like this at https://flackr.github.io/carousel/examples/scroll-marker/

@scottaohara
Copy link
Collaborator

prior thumbs up to the first part of your response (re: inert)

i'm not sure i understand the use case for the second, since it only visually scrolls the pane. but say i were to add a focusable element to each section of that content. Then as a keyboard user, the controls to scroll the content are effectively useless to me. E.g., I want to navigate to section 3 - i activate that but the content only scrolls and because these aren't hyperlinks, i remain on the current control. If i then hit tab (or in this case shift tab since the visual order is opposite the DOM order), I don't navigate to section 3 - rather i navigate to the focusable element i placed in section one, and now i have to navigate through any other focusable elements that might exist in this content, before i can get to section 3.

maybe that is something that could also be resolved per further exploration in the css inert you mentioned? A way to temporarily make such focusable elements/content skippable until focus has moved to an item in the 'active' section? And then, remove the interness from those elements so that people could then navigate backwards (tab or via reading keys w/a screen reader) to access the content they initially wanted to skip over, but now might want to review?

@flackr
Copy link
Author

flackr commented Apr 11, 2024

prior thumbs up to the first part of your response (re: inert)

Apologies for the unexpected edit, I should have kept it a separate comment :-)

since it only visually scrolls the pane. but say i were to add a focusable element to each section of that content. Then as a keyboard user, the controls to scroll the content are effectively useless to me.

This is really interesting point. I completely agree that the naive keyboard focus behavior would be really unexpected / hostile in this case.

One of the options I considered for the generated pseudo-elment focus order flackr/carousel#21 was to keep the scroll markers in their relative DOM positions. This might actually address your concern because then after selecting / focusing section 3, the next item in the tab order would be the first focusable item in section 3. That said, it might also be weird if while tabbing through the document you tab to the scroll marker before tabbing to the focusable content in the next section.

Maybe there's other ways we could make this interaction work properly, e.g. since it scrolls on focus, invoking could move focus to the target.

@flackr
Copy link
Author

flackr commented Apr 15, 2024

The more I think about this the more moving focus to the scroll target on invoke makes sense. It aligns the behavior with that of an anchor link or as @argyleink explained to me, skip links, and it will mostly just do what you would expect when you click on it. I'll try prototyping this out and see how it feels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants