You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using scroll markers, there are two known main use cases:
A table of contents or set of quick navigation points.
A set of independently exclusively accessible content (e.g. a carousel, tabs).
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.
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?
The text was updated successfully, but these errors were encountered:
Overview
When using scroll markers, there are two known main use cases:
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
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.scroll-marker-group: contain
per [css-overflow-5] Creating scroll-marker groups within which to select an active marker #10916.The text was updated successfully, but these errors were encountered: