[css-scrollbars-1] accessibility review [css-a11y]

[patrickhlauke]

Reviewed on behalf of the CSS Accessibility Task Force:

At the end of https://www.w3.org/TR/2018/WD-css-scrollbars-1-20180925/#scrollbar-color we have

When using scrollbar-color property with specific color values, authors should ensure the specified colors have enough contrast between them. For keyword values, UAs should ensure the colors they use have enough contrast. See Techniques for WCAG 2.0: G183: Using a contrast ratio of 3:1 […] [WCAG20].

It may be worth generalising this to also mention that UAs should ensure that their automatically-chosen color values for scrollbar-color: light and scrollbar-color: dark should also pass sufficient contrast (i.e. that scrollbar-color: light on a light background / scrollbar-color: dark on a dark background should always have sufficient contrast (under the control of the UA)

WCAG 2.0 only provides guidance for text color contrast (so not directly applicable here). This should now reference WCAG 2.1 SC 1.4.11 Non-text Contrast https://www.w3.org/TR/WCAG21/#non-text-contrast which is directly related.

Additionally, it may be good to mention that UAs may ignore this directive altogether based on user preferences (for instance, providing users with a configuration option/setting that always ensures a particular scrollbar color / use of system default scrollbars)

As a side note, example 1 in this section has stray opening/closing single quotes.

https://www.w3.org/TR/2018/WD-css-scrollbars-1-20180925/#scrollbar-width allows authors to set the width of the scrollbar, including completely removing the visual display of the scrollbar with scrollbar-width: none. Too thin a width may make the scrollbar difficult/impossible for users to operate - particularly users with mobility impairments. A minimum size should be required/suggested/enforced by UAs - see WCAG 2.1 SC 2.5.5 Target Size https://www.w3.org/TR/WCAG21/#target-size
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. This should at least be strongly suggested/noted. For situations where an area is going to be scrolled by other means (e.g. programmatically), overflow: hidden is likely the more apt choice, rather than not using overflow but instead setting scrollbar-width: none

[jonjohnjohnson]

@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

[patrickhlauke]

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)

[jonjohnjohnson]

@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.

[tantek]

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/)

[fantasai]

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!

[patrickhlauke]

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.

[patrickhlauke]

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).

[frivoal]

@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?

[patrickhlauke]

@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

[frivoal]

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.