Minutes from joint meeting with CSS at TPAC

Text minutes from the joint meeting of APA and CSS during TPAC 2021 are
provided here.

Hypertext minutes are available at:

https://www.w3.org/2021/10/20-cssa11y-minutes.html


   W3C

                                                                                                            – DRAFT –
                                                                                                    CSS & APA Annual Checkin

20 Oct 2021

   IRC log.

Attendees

   Present
          Aimee_U, alisonmaher, amy_c, chris, dandclark, Francis_Storr, hdv, jamesn, janina, jasonjgw, Jennie, jfkthame, Joshue, kirkwood, LisaSeemanKest_, MasakazuKitahara, Matthew_Atkinson_, myles, Rossen_, smfr,
          vmpstr

   Regrets
          -

   Chair
          Janina, Rossen

   Scribe
          emeyer

Contents

    1. Highlights in Accessibility Tree
    2. Figure out how highlights are exposed to the accessibility tree
    3. Deep video-to-video transformations for accessibility with an application to photosensitivity
    4. [css-scrollbars] Add wide value to scrollbar-width
    5. https://github.com/w3c/csswg-drafts/issues/6351

Meeting minutes

   <Rossen_> Here's the agenda project https://github.com/w3c/csswg-drafts/issues/6351

   Rossen: many people on the call; not sure we have time for intros
   
 there are a few topics we captured in Github topic
   
 we have three topics tracked by CSS issues

   Rossen: let’s tackle the first issue on the agenda. Do we have the Github tracker here?

   dbaron: No.

   Rossen: okay. We’ll do our best to capture minutes and post them into discussions.

   <chris> https://github.com/w3c/csswg-drafts/issues/6498

   https://github.com/w3c/csswg-drafts/issues/6498

  Highlights in Accessibility Tree

   <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6498

  Figure out how highlights are exposed to the accessibility tree

   Rossen: Florian, you were the person who added this issue. Could you summarize?

   Florian: highlights are a things that exist in CSS already, you can select and style them. Example: spelling-error pseudo. We’re introducing an API that lets you create more. You can create a type of highlight and
   then style it via the API.
   
 question is, how will this be exposed to the accessibility tree?
   
 We have a definitive answer to this.

   Dandclark: What we propose is adding a type field to the highlight API so the author can say what they’re using it for.
   
 type field can be ‘spelling-error’, ‘grammar-error’. enum could be extended later to add more types.
   
 This would add these to the a11y tree in the same was existing pseudos are exposed to the tree.

   <Zakim> janina, you wanted to ask if can be used to hide?

   Janina: Could this also be used to hide an area of the screen?

   Florian: To the same extent any element can be hidden using CSS, yes. Such as white-on-white text.
   
 the current difference is element have to be bound to the tree. Selections don’t; they can cross element boundaries.

   <Zakim> jcraig, you wanted to ask Janina the context for her question about "hiding"

   <fantasai> Actually, much less than can be done with CSS in general. Highlight pseudo styling is extremely limited, and can't affect layout.

   jcraig: Can I have more clarrity on what’s meant by hiding?

   Janina: looked like another mechanism

   Lisa: Seems to me we should use the same model we use with ARIA because it works and it’s familiar to people.
   
 you can toggle the CSS against element state run by ARIA. Seems we could do something similar, we could have pink for grammar, green for extra-long words, red for spelling error. You could have reserved words and
   allow other words as well.
   
 This would allow the feature to extend. So you could have ‘aria-spelling’ or something like that. ‘off’ or ‘none’ could be reserved, indicating there’s no special highlighting.

   Rossen: I’d like to question some of the path forward to align with ARIA. One thing CSS highlight lets us do is cross element boundaries in a not-necessarily-normalized way, given how HTML works today.

   
Example: Handling a selection that starts right before a button and ends in the middle of the button. Describing this with ARIA is difficult.
   
 In terms of the direction where this is going, I’m not sure it aligns well with ARIA.

   Lisa: That makes perfect sense.

   Rossen: You could also have multiple overlapping higlights.

   <Zakim> jcraig, you wanted to express preliminary support for Dan Clark's proposal, and mention the WebKit implementation with Apple platform accessibility APIs and attributed strings

   jcraig: I’m new to this issue, but the Apple API uses attributed strings. WebKit already does the same for selection ranges like the native Find in Page feature.
   
 I don’t have any particular concerns about the proposal. I agree that Dan's API would be better to than to use something like ARIA here.. That would entail a complicated dance of adding new DOM elements.

   <Jemma> +1 to jamesc

   Aaronlev: I appreciate the simplicity of the current proposal. It’s very useful to be able to overlap area. Could potentially add problems we’ve had in ARIA annotations.

   <Travis> aria-details="place to highlight?"

   Aaronlev: imagine a document with multiple commented regions, where the regions overlap. You can imagaine this would solve those problems.

   Dandclark: Building on what James said, we’d been prototyping this in Chrome. There are annotation types that can mark errors.
   
 I don’t know if that’s something that would go into ARIA mappings, but it does seem to fit into assistive tech platforms pretty well.
   
 In the meeting we had, from reviewing notes, the advnatage of having a set of supported types is that it allows things in the ATA platform to be represented in a first-class way.

   <LisaSeemanKest_> agree

   Dandclark: If assistive tech becomes more powerful, if arbitrary strings are used, it limits the ability to make them first-class.

   <jcraig> +1 to dandclark's comment about the benefits of keeping this as close as possible to the platform features

   Rossen: Want to address where this work can and should be specified, where I mean the actual AT specification and any platform mapping that need to take place.
   
 Good candidate for CSSAAM. What you’re proposing sound like a great first candidate.

   <LisaSeemanKest_> Im sorry I need to leave early. feel free to be in touch

   Rossen: It also sounds like most feedback is positive from tech point of view, in terms of user enablement. Since we have great experts here, what do you all think? Is this good or great? Are we missing something?

   <aaronlev> +1 for CSS-AAM. There are other uses for CSS-AAM IMO

   Janina: I’m not an expert on implementation and AAMs, but not having anyone in queue seems to say this is reasonable.

   <Travis> +1 for CSS-AAM

   Janina: If this is a reason to get a CSS-AAM started, great.

   jcraig: An AAM may not be necessary. This doesn’t seem like a terribly complicated API. ARIA with AAM has a lot of cross-reference to other things on the web.

   <Zakim> jcraig, you wanted to talk about whether CSS AAN is necessary for this

   jcraig: In that regard, I don’t see quite as much value in spinning up a document to reference just this one API when implementators probably don't need one. This strikes me as an implementation detail.

   <aaronlev> I recently filed an issue to develop rules to expose CSS cursor info to platforms that want it to allow ATs to use the info for heuristics

   jcraig: If you do spin up, please make it a living document. We’ve found AAM docs get out of date very quickly.

   Rossen: Point well taken.
   
 I challenge that this is an implementation detail in terms of how ranges and range types are supposed to be mapped.
   
 We want some level of consistency across various ATs. Totally with you on this being a living document.

   <Zakim> jamesn, you wanted to say we are moving all the ARIA AAMs to living standards with the new charter

   Rossen: I’m hearing support from both sides, and am hearing support here. In terms of CSS AAM, I propose we not spend time here and now. We can take it to email. once we have a resolution, we can resume the CSS AAM.

   Janina: Sounds reasonable.

   Rossen: Excellent. The next two issues: one is Ruby, one is scrollbars.
   
 One more was raised by Amy. This is about MIT’s demonstration on video streams and analysis of Flash animation.

  Deep video-to-video transformations for accessibility with an application to photosensitivity

   Janina: that’s mainly a heads-up where we can provide a tech solution to what’s long been a WCAG authoring guidelines.
   
 MIT has shown double-digit millisecond delay can allow the machine to block flashing and avoid killing people. Should we trigger that via CSS or HTML? Still being discussed.

   <Rossen_> Document in reference: https://groups.csail.mit.edu/infolab/publications/Barbu-Deep-video-to-video-transformations.pdf

   Rossen: I don’t have a firm opinion on how this might be exposed or implemented. Anyone have a firm opinion?

   Florian: Speaking of different issues, I’d like to not discuss the Ruby issue. I don’t think it’s ben sufficiently discussed in the WG.
   
 The scrollbar issue is the last one before next stage, so I’d like to discuss that.

   Rossen: I’d like to go back to the previous issue and alalow people to express opinions.
   
 I’ll take the silence as no opinions.
   
 Let’s go ahead to the scrollbar issue.

  [css-scrollbars] Add wide value to scrollbar-width

   <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/6351

  https://github.com/w3c/csswg-drafts/issues/6351

   Florian: Two varying degrees based on the platform and browser. You may have the ability to change the scrollbar. This is not about that.
   
 Besides user preferences, we see many web sites that want to change scrollbars in certain contecxts, like narrow scrollbars in a dropdown menu.
   
 CSS WG wanted to introduce a property with values ‘auto’ and ‘thin’.

   <emilio> there's a third value (though not relevant to this conversation), which is 'none'

   Florian: Because CSS also has user overrides in form of user.css etc., if the user doesn’t want this, they can override.
   
 We considered whether sites should be able to make scrollbars wider, but the WG concluded that users should be able to make scrollbars bigger, but that’s a UI setting. There’s no need for authors to be able to make
   scrollbars wider.
   
 We resolved that ‘auto’ and ‘thin’ was all we needed, but not everyone is convinced.
   
 It’s not clear to me whether the ‘wide’ value should make a ‘thin’ scrollbar normal width, or if it would make a wider-than-usual scrollbar.
   
 WG still thinks this isn’t needed, because we believe that need is addressed differently.
   
 We believe we’ve made a compelling case, but we want to discuss.

   Janina: Maybe a specific feature in a page needs a wider scrollbar. That may change our view. Anyone from APA want to talk to this?

   JF: “Author proposes, user disposes”. A ‘thin’ value is making a decision for the user. The user may not agree or be able to use that.
   
 Why wouldn’t a low-vision user be able to say “I want ALL scrollbars to be thick”?
   
 It seems to me the obvious choice to have the opposite of ‘thin’ and ‘thick’.

   Rossen: This is a very pointed, quick question: what is it you want from this discussion?

   Florian: I’m looking for a reason to close or continue.
   
 Response to JF: should user be able to make scrollbars thin? They can already do that. They can block authors from making any scrollbar thin. In addition, should the user be allowed to make wider scrollbar? Yes,
   but not through CSS. it should be done through customization elsewhere.
   
 ’auto’ will make scrollbars as the system is configured: thinner, wider, normal, whatever.

   JF: You keep talking about the author.

   Florian: I’m talking about the user. They can override all author scrollbars, and use their system to widen all scrollbars.
   
 From a user point of view, we’ve served the need for users to be able to override authors. Why do users need to use CSS to make things wider?

   <astearns> put another way, 'auto' lets the user set all scrollbars to their preferred system setting

   JF: Again, I don’t understand the hesitancy to add another value.

   <tantek> hesitancy is because there is no documented *developer* use-case need for "wide", so there is no desire to take-up that cost (of specification, implementation, testing, compat, etc.)

   JF: Are you saying we’re going to have browser settings for scrollbars?

   tantek: First, I 100% agree with user use cases that JF and Janina have described. The current solution seems to address them. It may be confusingly named.
   
 If you’d asked us that 10-15 years ago, the WG would have agreed. But one thing we’ve learned to do is not add anything that doesn’t have a demonstrated developer use case.
   
 As long as we’re preserving user intent, that’s sufficient. All user preferences can be contained within the ‘auto’ value. With ‘wide’ developers could mess with user preference.

   emilio: Concrete example: there are Windows settings that let you set scrollbar width. You can set them there. ‘auto’ would then yield wide screenbars.
   
 Adding this ‘wide’ value to CSS doesn’t make sense because authors don’t have a user case for it. Users do.

   JF: Couple of things. 1, we may not be able to come up with author use case, but users have a use case. The fact that I can fix this in OS settings, okay, but at some point we want to make this easy for the user as
   well. I can see users wanting to use a ‘wide’ value. To withhold this because the OS can address this strikes me as weak. This feels like separaating the needs form the solutions.

   Emilio: You can definitely configure the browser to ignore the OS settings. In Firefox you can already do that with advanced settings.

   <tantek> No disagreement on the user use case JF.

   fantasai: I want to re-emphasize the point that the property is a way for authors to say what they want in a scrollbar. It’s not a way for users to do that. A CSS property isn’t necessary for this for users because
   users in general aren’t writing CSS.

   <Rossen_> aack florian

   Florian: I feel like we’re not quite hearing each other. I hear some saying it’s important to let users set scrollbars wide. They already can, as ‘auto’ will allow users to override authors with whatever their system
   is set to provide.
   
 It’s desirable that an easy UI lets users configure this, but that’s outside the scope of CSS. For users, we’re covered. We need something for authors to give hints.

   <emilio> To be extra concrete, on Firefox: `about:config` -> `widget.non-native-theme.win.scrollbar.use-system-size=false` -> `widget.non-native-theme.scrollbar.size=<whatever>`

   Janina: Renaming may be a good path forward.

   Rossen: The CSS WG is trying to move forward and publish this. It’s work that enables a lot of functionality.

   <tantek> Perhaps it would be good to add some advisory text to the spec for users who want wider or default scrollbars to use 'scrollbar-width:auto'

   Janina: I don’t think we can resolve here, but we can discuss whether we want to keep debating or resolve.

   <florian> +1 to tantek

   <tantek> If it's causing this much confusion among experts here, it's worth clarifying in the spec

   Rossen: We went in circles a few times here. Can we make this more actionable? Perhapas some of the CSS WG could cross over to the APA WG call?

   Amy: Thank you for everyone explaining, it really helped understand where the WG is coming from and what’s meant.

   <Matthew_Atkinson_> +1 to Amy; this was really helpful, thanks.

   Janina: Want to thank Amy_c for all her help with APA, sad we can’t pay enough to keep you. And we’re looking for a new liason.

   Amy: APA is really good to work with.

   <JF> +1 to Tantek re: more clarification

   <tantek> ^ it looks like we're close to a resolution

   Rossen: Couldn’t agree more. Want to express appreciation for everyone hanging with us and working through these things.

   <tantek> PROPOSED: Add advisory spec text to 'scrollbar-width' noting that for users who want wider or default scrollbars to use 'scrollbar-width:auto' in their user style sheet

   Janina: thanks to everyone from APA, CSS, and other groups for being here. Looking forward to moving this forward in the future, will make the scrollbar our top issue when we return to work in November.

   <Travis> +1 thanks emeyer


    Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).

Diagnostics

   Succeeded: s/topoics/topics/

   Succeeded: s/used/uses/

   Succeeded: s/ I agree it would be better to put something in ARIA/ I agree that Dan's API would be better to than to use something like ARIA here./

   Succeeded: s/We could do the same for selection ranges, I think./We already do the same for selection ranges like the native Find in Page feature./

   Succeeded: s/We already do the same for selection ranges /WebKit already does the same for selection ranges /

   Succeeded: s/API when authors can probably deal without one./API when implementators probably don't need one. This strikes me as an implementation detail./

   No scribenick or scribe found. Guessed: emeyer

   Maybe present: Aaronlev, Amy, dbaron, emilio, fantasai, Florian, jcraig, JF, Lisa, Rossen, tantek, 
Example

-- 

Janina Sajka
https://linkedin.com/in/jsajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Co-Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

Received on Wednesday, 20 October 2021 17:09:35 UTC