Meeting minutes
Agenda Review & Announcements
<janina> https://
<becky> janina: follow up on CSS tpac conversation and standard agenda
<becky> janina: APA is cosponsoring the above referenced symposium next week
<becky> Janina: Symposium: Shape the Future: Research and Development Questions in Digital Accessibility
<becky> Online Research Symposium, 10 November 2021
CSS Scroll Bars -- Does 'auto' always overide?
<becky> Janina: hoping the phrasing of this agendum helps resolve; APA concern is that we need to support wide scroll bars
<becky> Janina: for users; my understanding is that if user has specified wide scroll bars in the OS or browser settings, author specified thin value will be overridden by that user preference
<becky> JF: concern is that where does auto come from if author has specified thin within the page
<becky> Florian: yes, Janina is correct. There are a variety of ways for the user to override: user CSS can include auto !Important and it will override CSS value
<becky> Florian: CSS doesn't specify the browser UI but through a user setting in OS or browser, the user setting will be honored
<florian> https://
<becky> Florian: I have made a pull request to clarify this in the spec. Waiting for other CSS members to comment (few have)
<becky> Florian: see link about
<Zakim> JF, you wanted to ask about what "auto" actually equals
<becky> JF: I understand using auto !important in a user style sheet. This will override the author thin with the default; how do I make it wider
<becky> Florian: CSS scroll bar width property doesn't allow setting the width via pixel values; but auto override will use the OS or browser setting for the width
<becky> JF: CSS has provided an author way to make the scrollbar thinner but not wider
<becky> Florian: CSS believes that user should be able to override settings set by CSS; We do not believe that CSS is the right way for users to customize
<becky> Florian: author is the author of the web site being visited; They may need to put something in a cramped space and offer thinner scroll bars
<becky> matthew: I agree with CSS view that wide is not needed because user setting will override, so don't think we need wide. I don't understand why we need thin but it is already in the spec
<becky> matthew: user can override in two ways: user css or by setting OS or browser setting
<becky> Matthew: and how is thin specified
<becky> Florian: User agent decides what "thin" means. is if thinner than the user's default setting or some other variant
<becky> paulg: ack that user control of CSS and of the OS is common, but we can't always make that assumption - for example kiosks, which often have a smaller screen. Thus believe wider scroll bars should be available . And WCAG AAA does discuss making pages for specific options. Believe should add wider or deprecate thin
<becky> Florian: agree kiosks are an issue; but believe we need to still include thin so they don't create thin scroll bars via JS which can't be overridden by the user settings
<Zakim> florian, you wanted to respond to paul
<becky> Florian: pull request does explain the thin should only be used for specific purposes
<Zakim> JF, you wanted to comment on Should/shouldn't
<becky> JF: agree we can say what authors should and shouldn't do and people don't always follow: gives example of doc that says not to user placeholder and people still do. Believe if can change an attribute in one direction it should be changeable in the other direction
<becky> matthew: I believe we are talking about this issue: https://
<florian> yes we are
<JF> +1
<becky> Janina: yes that is the issue; Would encourage CSS to rethink the kiosk use case; Agree with JF philisophical approach but that understand argument that this is for specific UI within a page
<kirkwood> can’t grab a scroll bar in a kiosk. just finger scroll whole area. Does that affect things?
<becky> Florian: if the kiosk operator could use auto !important in style sheet for kiosk. We can't force that but that is the same with any user agent - they won't always offer all features. The tools are available to support the user we can't force implementors to use them
<becky> kirkwood: generally whole area scrolls with touch - it is not just the scroll bar that is the target area. Scroll bar gives indication of where you are but is not used for operation
<becky> kirkwood: most kiosks are touch
<becky> paulg: but scroll bar is a visual affordance that some people need
<becky> Neil: I am baffled that kiosk is considered an important use case? There is still nothing to force the author to use wide and no guarantee that they will
<JF> If the proposal is for "Default" and Default-", why can't we have "Default+"... I just don't understand the opposition
<becky> Florian: the argument is the other way around, author's might use thin and that could make the situation worse
<becky> Neil: it is up to the kiosk implementor to add the override
<becky> paulg: was just using kiosk as a general example or alternative User interface
<kirkwood> FYI We have over 1000 public kiosks (former phone booths) here in the City NYC
<becky> paulg: believe there are situations wrt AAA conformance for specific audiences where wide would be used
<becky> Fazio: library systems generally use keyboards or projected keyboards - we should be forward thinking.
<becky> Florian: responding to offering a switch one way we should offer switch the other way. We are really just providing a toggle between thin and default - two things that people are already using
<becky> JF: I respect that perspective but believe we are providing use cases of where we should offer both options
<becky> Florian: we have addressed the use cases - the user is in control
<becky> Janina: I'm not sure we have provided use cases for why authors would want or use wide (other than specifically for a11y); we do have a path for users to override on their own systems
<becky> Janina: if there are use cases for authors to need wide (vs. user) we need to provide those
<becky> matthew: all of us want to give users control of their environment; but understand that user does already have control via OS and browser settings; Adding wide won't give users more control
<becky> matthew: I think the group is concerned with the ability of authors to use thin but understand the argument that they are being used and if thin is not available authors will implement via JS. The JS implementation is not overridable by the user but the thin option is
<florian> +1 to Matthew's points
<becky> matthew: agree that adding wide is not a solution; don't see a CSS solution for kiosk example; I see an analogy with author supplied customization like font size but we really want user to have more generic control
<kirkwood> +1 to Mathews points
<becky> janina: are we comfortable solving by drafting accessibility considerations for this issue to be included into the spec
<becky> Florian: I have included a warning in the pull request I proposed: https://
<becky> Janina: might be good to also add a separate section for accessibility considerations
<becky> Florian: I can do that
<becky> Janina: is there anyone who can't live with the resolution that wide is not needed
<becky> JF: I still have concerns but I won't formally object
<becky> janina: we never got to the use case of the author wanting wide; the thin case has been presented; I gain comfort that the user can override and it does meet the need
<JF> +1 to missed opportunity
<becky> paulg: my first project was a website for a drug for parkinsons, if I had the option for a wide scroll bar I would have argued for using it. I feel not having a wide misses the use case. So still believe it is an issue and I have made that case and don't see use of presenting again,