Skip to content

[css-overflow-5] Discrete versus navigation scroll marker mode #12122

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

Open
flackr opened this issue Apr 25, 2025 · 0 comments
Open

[css-overflow-5] Discrete versus navigation scroll marker mode #12122

flackr opened this issue Apr 25, 2025 · 0 comments

Comments

@flackr
Copy link
Contributor

flackr commented Apr 25, 2025

Overview

When using scroll markers, there are two known main use cases:

  1. A table of contents or set of quick navigation points.
  2. A set of independently exclusively accessible content (e.g. a carousel, tabs).
  3. If there are other use cases, please comment on this issue so we can consider whether they fit into these two modes or not.

Currently, the focus management and behavior of scroll markers is largely designed around the first use case, and requires the developer to use interactivity to inert the non-current content should they need the second use case.

However, it would be nice if the developer could opt into this behavior and the browser could use this opt-in to automatically apply appropriate inferred roles to the content.

Proposal

Authors creating carousels or tab designs would apply scroll-marker-type: discrete, making the scroll marker pseudo-elements a sequential focus navigation scope owner for their originating elements. This means that the originating element (and its descendents) follow the scroll marker in focus order. Since only the :target-current scroll marker is focusable the originating element and its contents are only part of the tab focus order when that scroll marker is current.

When this type is applied, the originating element will be given the "tabpanel" role, and the ::scroll-marker-group and ::scroll-marker pseudo-elements will be given the tablist and tab role respectively.

Otherwise, (e.g. for table of contents use cases) the ::scroll-marker-group and ::scroll-marker pseudo-elements will be given the listbox and option respectively.

Open questions

  • Should this be part of the scroll-marker-group property? E.g. scroll-marker-group: before discrete;? It probably doesn't make sense (and we couldn't implicitly apply the tablist role) if this was per scroll marker - so it needs to be associated with the common container of the scroll markers and this mean that we don't have this extra property for all elements just in case they have a scroll marker group.
  • Does this have an effect on element scroll markers? Presumably applied to the same element that has scroll-marker-group: contain per [css-overflow-5] Creating scroll-marker groups within which to select an active marker #10916.
  • Should this change focus behavior? E.g. without specifying this property we would have a list-of-links style focus where every scroll marker is in tab order. This would be a breaking change but the impact is likely minimal for now.
  • How would this work when scroll markers are established on ::column pseudos? Or would we skip the sequential focus navigation scope order?
    • In particular, some elements will span across multiple ::column pseudo-elements. Could we make the marker a sequential focus navigation scope order only for the fully contained elements or only elements whose first fragment is in that particular ::column?
  • How does this affect the accessibility tree? The expectation of the tabs design pattern is that users are not confronted with content from the inactive tabs. Does this automatically hide the inactive tabs from the AT?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant