@patrickhlauke

Having the scrollbar completely suppressed may be confusing for all (sighted) users, unless an alternative/equivalent visual hint that scrolling is possible / that there is more content is provided.

Just wanted to say that with scroll-snap implementations landing, especially on mobile, I've been experimenting with making "paging" interactions, horizontal and vertical, cleaner by using very hacky hidden scrollbars. These UIs aren't exactly fit for scrollbars, even if they use the browsers native scrolling. Having scrollbar-width: none will be so much cleaner a solution. Check this demo on safari (especially iOS) http://output.jsbin.com/gedurer/11

i'm not disputing that it's useful, just - as noted - that authors should use it with caution as it can lead to potentially confusing experiences for users (for what it's worth, i had no idea what to do on your jsbin example, as a mouse user)

@patrickhlauke Rightfully that demo is confusing for mice, being a quite reduced test case made for touch screens (not a full featured site, with content, progressively enhanced for all environments). I do heed your words about using scrollbars in ways that contribute to clear interactions. This is exactly why sometimes scrollers, like in my example, should have no scrollbar. I do agree that a note about using scrollbar-width responsibly would be worthwhile.

Thanks @patrickhlauke for catching this, the suggestions, and especially the precise WCAG links, very much appreciated.

I’ve lightly edited the suggestions and incorporated them into a pull request:

#4694

Patrick, could you review that pull request?

Feel free to suggest additional edits if necessary.

I will wait for your positive review before merging. Thanks!

(Originally published at: https://tantek.com/2020/023/t5/)

I think the PR is clearly an improvement over the current text, so suggest we merge it in to improve the baseline text, and just leave the issue open to take Patrick's additional suggestions, if any, upon review!

my apologies, this slipped me by until now. i'll have a more thorough look tonight, but at first glance the PR is definitely an big improvement.

I proposed a tiny markup change here (hope I got the syntax right, not too hot with Bikeshed etc...was going by similar examples elsewhere in the doc) #4800

UAs should enforce a minimum actual size of scrollbar width per WCAG 2.1 SC 2.5.5 Target Size

Possibly worth noting though that even today, UAs don't generally have large-enough default scrollbars (based on the 44x44 CSS px minimum dimensions mentioned in that WCAG SC). Might be worth softening the statement a bit, maybe "UAs should enforce a minimum actual size of scrollbar width, to ensure that it remains usable/operable by users - ideally, following suggested minimum sizes per WCAG 2.1 SC 2.5.5 Target Size" or similar? Just worry that this part may be summarily ignored otherwise (particularly as it's a AAA requirement in WCAG anyway).

An additional point that I didn't mention originally, as it's not strictly WCAG related: it may be worth also adding a note that warns/reminds authors that if they do choose to go for scrollbar-width: none, they are essentially preventing mouse users from scrolling (unless those users have a scrollwheel, or the author provides an alternative programmatic scrolling mechanism).

@patrickhlauke Made some changes to address your comments in #3315 (comment), can you have a look and let us know if this is now satisfactory?

@frivoal lovely, those changes address the concerns.

looking ahead, may be worth keeping in mind that the upcoming WCAG 2.2 has pivoted slightly with regards to target size - 2.5.5 is now "Target Size (Enhanced)" (as it's stricter / more difficult to achieve with its exceedingly large target size requirements), and there's a proposed new 2.5.8 "Target Size (Minimum" (though that's still heavily in flux) https://www.w3.org/TR/WCAG22/#target-size-minimum which goes for 24x24 suggested minimum size, but also takes into account spacing/clearance around the target (so you can conceivably have a target that's actually smaller than 24x24 provided there's no immediately adjacent other target - the extreme case would be w3c/wcag#1848

lovely, those changes address the concerns.

Great. Closing then.

looking ahead…

We could expand the link to #target-size to be #target-size and #target-size-minimum, but if you say that's heavily in flux, I think it's probably better to leave as is for now. We can always open a new issue later one that's stable if it is still relevant, to add the link. Then again, if the details might still change, but we're sure that the less strict #target-size-minimum will exist no matter what, we can probably include the link already.