#1054: CSS Scroll Buttons

Visit on Github.

Opened Feb 20, 2025

こんにちは TAG-さん!

(Split from #1037. Original requester @flackr)

I'm requesting a TAG review of CSS Scroll Buttons.

Carousels are an often used design pattern on the web. They are used in a variety of contexts, from product listing pages to slideshow like content. OpenUI has explored a range of carousel designs, showing that the specific layout and appearance can vary dramatically. They are also provided by many frameworks as components, however implementing a carousel correctly is complicated and often results in inconsistent and sometimes inaccessible implementations.

There are a variety of problems being solved by carousels, which we believe could be provided by a set of CSS features. Developers could then combine these CSS features to create the various designs. CSS-only component libraries could be built to further simplify this process.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines:
  • The group where the work on this specification is currently being done: CSSWG
  • The group where standardization of this work is intended to be done (if different from the current group):
  • Major unresolved issues with or opposition to this specification:
  • This work is being funded by:

Discussions

Log in to see TAG-private discussions.

Discussed Feb 1, 2025 (See Github)

Xiaocheng: this is one of the carousel issues... Approach is like identifying the common design pattern... Really complicated to design as a whole.. so the approach is to identify common parts of the carousel pattern...

[Lola: we agreed in breakout A to talk about this in a session.]

Matthew: There is a discussion in CSS that APA has been tracking... related to this. A bit unclear as the intent of the CSS wg here... Element would need to be focused.. which is different to how focus works now... different from a keyboard interaction perspective.

Martin: ... pseudo-elements are focusable - doesn't imply they have to be focussed ... ... would be good ... not clear from the explainer... "can be focused" -

Xiaocheng: they are treating scrollers as special case of carousel... Regarding other issues: for this they are defining a pseudo-element for interaction purposes... Can be focused ... Is that a good approach from an a11y perspective?

Martin: don't we already use pseudo elements for various forms? e.g. inoput type=file?

Xiaocheng: with event listeners?

Martin: I think so.

Matthew to draft a comment requesting further info... we can agree to leave it async or agree it at the plenary

Comment by @matatk Feb 27, 2025 (See Github)

Hi @flackr, thanks for your review request (this is split off from your original thread), and for your replies on #1055.

Thank you for writing an Explainer for your proposal. However, we're unclear on a couple of things:

  1. Is it intended that the scroll buttons must be focused in order to scroll the carousel via the keyboard?

  2. Is it intended that scroll buttons will be provided as a way to style the scrolling mechanism for any scrollable region on the page (and/or the viewport itself) in future?

We are concerned that if the answer to both questions is 'yes' then scrolling would work very differently from a keyboard interaction point of view to how it does currently.

Comment by @flackr Mar 18, 2025 (See Github)
  1. Is it intended that the scroll buttons must be focused in order to scroll the carousel via the keyboard?

No, keyboard scrolling still works as it normally does. These are also in the focus order.

  1. Is it intended that scroll buttons will be provided as a way to style the scrolling mechanism for any scrollable region on the page (and/or the viewport itself) in future?

No, the intention is that these re not provided by default but that authors could add these to facilitate scrolling of any scrollable region. They are the equivalent of an author adding a <button> that programmatically scrolls the area.

Comment by @xiaochengh Apr 15, 2025 (See Github)

Closing this sub-issue. Please refer to the response in the parent issue: https://github.com/w3ctag/design-reviews/issues/1037#issuecomment-2754205037