css-scrollbars-1 and people with learning and cognitive disability

[lseeman]

With regard
https://drafts.csswg.org/css-scrollbars-1/

I am glad to see the changes made with APA. However the risks are not clear with regard to people with learning and cognitive disability.
Is it possible for the notes to included warning for reduced accessibility and useability, especially for people
with low vision and or people with learning and cognitive disabilities for:

• making the scroll bar thin or none
• reducing the contrast of the scroll

Useability testing should included these user groups, when reducing the
size or contrast of scrolls bars.

Also we would like to mention that double or nested scroll bars is often
an accessibility issue and they should be avoided. If they are
necessary there should be very clearly grouped with the related content,
so that users can clearly tell what content will be affected by what scroll
bar.

for more information see https://www.w3.org/TR/coga-usable/ It is full of goodies about how presentation can help or hinder people with learning and cognitive disabilities.
The issues above with Scroll specificaly is mentioned a few time such as :
3.1.2 Clear Operation (User Story)
3.2.1 Findable (User Story)
4.3.1 , 4.3.4, 4.2.6 and more!

[LE0616]

Double nested scroll bars, as well as on hover only scroll bars, are definitely an issue for me as someone on the spectrum. Not only can they be confusing to use depending on their presentation, they are also a very high stim feature adding to neurological load in using the page or product in which they are present. High stim can use up my limited spoons and if stacked with other high stim features (ea. high contrast, moving and blinking content, high density content etc) can cause the page or product to become unusable completely to me and to others like me.

Thanks @lseeman for opening this issues for discussion.

[Malvoz]

Related (or potentially duplicate of): #6710.

[frivoal]

While I don't disagree that double nested scrollbars, or overlay scrollbars, can be problematic, this specification does not introduce or change the ability of such things to exist. Teaching authors how to design accessible websites, and convincing browser or OS vendors that the latest aesthetic trends have downsides is valuable, but is this specification really the best place to do it?

---

With regards to scrollbar contrast, and scrollbar width, I do agree that a statement is warranted, since the ability to customize those is introduced here, but I believe there are such statements inline in the relevant sections already, and and the Considerations for Accessibility Appendix elaborates further.

Could you propose some concrete wording of what you'd like to see added there?

[svgeesus]

@lseeman did you have any suggested additional text regarding scrollbar contrast and width?

[frivoal]

I believe the issue is properly addressed through various bits of the text throughout the spec, as well as through Considerations for Accessibility Appendix.

In the absence of additional information on what further statement would be warranted, I propose to close this.

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment with specific changes you believe should be made to css-scrollbars-1

Proposed Resolution: Close this issue for lack of specific change requests

[acli]

I just knew about this issue and just want to say this isn’t just to people with learning disability or low vision. This is a problem for people even with no disabilities if you have the “wrong input device” such as a Wacom pen or a keyboard with mouse emulation (e.g., a Ducky).

(I use a Wacom pen myself and I assume most people don’t even know a lot of accessibility issues can be detected if you just used a pen or rotating your monitor 90°, a lot of sites become very hard to use; some become virtually unusable.)

[acli]

PS: I just checked things out with xev. When you use mouse emulation on a Ducky, x and y “mouse” coordinates only change in quanta of 8 pixels (real pixels), so if any scroll bars are less than 8 pixels wide, a user will literally not be able to interact with these scroll bars. This is a serious problem that need to be explicitly mentioned.

I don’t know how other brands of keyboard work so I don’t know what is a safe minimum pixel width for scroll bars and other UI elements.

[acli]

PPS: I just did a screen dump and checked pixel widths again. YouTube uses a custom scroll bar of 8 (real) pixels and that scroll bar is virtually impossible to use with a Wacom pen. That means minimum usable pixel width must be wider than 8 pixels (real pixels, in case that’s different from CSS pixels); IMHO anything less than system default must be considered a potential accessibility problem.

[fantasai]

@acli The features in the scrollbars spec are trying to make sure that authors don't emulate scrollbars with JS, but use real scrollbars (by providing some key preferences that they tend to want to tweak so fewer authors roll their own). The more pages we can push to using UA-provided scrollbars, the more it's possible for the UA to ignore the author's preferred styling in favor accommodating the user when necessary. A user's scrollbar preferences need be set at the OS level for that to work, but users who have difficulty with standard scrollbars (or particular input combinations with scrollbars) should be adjusting settings at the OS level anyway.

[astearns]

RESOLVED: Close this issue for lack of specific change requests