W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes TPAC/Vancouver 2022-09-15 Part II: CSS-APA Joint Meeting [css-color] [mediaqueries] [css-selectors]]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 25 Oct 2022 18:37:25 -0400
Message-ID: <CADhPm3sfSPbhatVSs_cW5LsY3oKEMjhu7AOb8Sxh4ZxbnFzaJQ@mail.gmail.com>
To: www-style@w3.org
Cc: public-css-a11y@w3.org, public-apa@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


CSS-APA Joint Meeting
=====================

CSSWG Accessibility Liaison
---------------------------

  - Janina encouraged the CSSWG members to look in their orgs for a
      possible CSSWG-A11y liaison; APA would be glad to train them up
      if they have interest in the topic.

contrast-ratio()
----------------

  - Chris Lilley gave an introduction to the intended use case which is
      also described in issue #7730 (contrast-ratio()).
  - The APA team expressed interest in helping in the effort to specify
      contrast-ratio() with a better contrast algorithm than used in
      WCAG2.

Media Queries in relation to Adapt
----------------------------------

  - matatk introduced the work the Adapt Task Force has been doing to
      allow pages to change based on user need for simplification.
      There is a demo available here:
        http://matatk.agrip.org.uk/personalization-semantics-explorations/distracting-sign-up-form.html
      The ask of the CSSWG is for media queries to support this work.
  - Next step would be to open specific issues for proposed media
      queries for CSSWG to consider.

Work on Navigation
------------------

  - The group discussed the navigation mentioned in the CSS charter.
      Spacial Navigation isn't moving forward much due to a lack of
      interest.
  - There is a suggestion from RachelAndrew to allow authors to opt
      into the display order which had a fair amount of interest and
      could assist with the accessibility limitations of navigation
      experienced today.

:role() pseudo-class
--------------------

  - There was high interest in having the :role() pseudo-class (Issue
      #3596). It is currently waiting on someone to have the time to
      write it up; there have also been some concerns about
      implementation difficulty.

====== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/csswg-drafts/projects/31
APA's Agenda: https://www.w3.org/WAI/APA/wiki/Meetings/TPAC_2022#CSS_.26_APA_Joint_Meeting

Scribe: fantasai
Scribe's Scribe: heycam & emilio

CSS-APA Joint Meeting
=====================

  [Rossen reviews the agenda]
  Rossen: Anything else to add?

CSS APA Liaison
---------------
  Janina: Pleading with this group to help us out
  Janina: Years ago were doing great with Amy
  Janina: Tried on our end to find a new liaison
  Janina: Many of you are from relatively large corporations, probably
          have some junior staff you want to develop into more effective
          participants
  Janina: if you think they have interest in accessibility, we'll train
          them up for you
  Janina: but we are desperate, having a formal liaison really makes
          this relationship effective
  [discussion of possible liaisons]

contrast-ratio()
----------------
  github: https://github.com/w3c/csswg-drafts/issues/7730

  matatk: Not proposing to resolve all issues right now
  matatk: wanted to use our F2F time to get background
  matatk: What's the use case for this function?

  chris: Dropped link to the issue
  chris: where I gave an introduction to what we want to do here
  chris: If you just have a single stylesheet, no variables, just light
         mode, don't need anything special
  chris: everything is constant
  chris: but if you have theming and customization, and stylesheets
         merged from multiple teams
  chris: it will work out for you
  <argyle> also, user's bring preferences to the page: prefers-contrast
           (less, more, etc)

  chris: Previously, this was all done by eye
  chris: They chose contrast by eye, threw through a checker to be sure
  chris: Here, not necessarily have human intervention
  chris: but need to know that it will check out

  matatk: I thought you as the author still have to give colors to
          choose from and isn't that deterministic
  matatk: but you said it would be from variables
  matatk: wouldn't you still have to know which custom properties would
          be applicable?
  chris: Yes, and the list that you give is in priority order
  chris: Also one of the open issues is allowing that list to be empty
  chris: and if empty, it gives you a color: either white or black,
         whichever more contrasty
  chris: but if you want to pick a target contrast, then will look for
         that
  <iank> note - sometimes these lists colors are generated from a user
         provided image for example.

  chris: Other big issue open atm is WCAG2 has a contrast algorithm
         which gives a lot of false positives and false negatives
  chris: and we want to do better
  chris: I've implemented a bunch of contrast algos in JS so people can
         play with it
  <chris> https://colorjs.io/docs/contrast.html
  matatk: As side project, I had to write a function that gives white
          or black from bgcolor
  matatk: so that's very helpful
  matatk: we'll follow the discussions and offer what advice we can
  janina: WCAG's color contrast rule is problematic in many ways
  janina: including that some people don't do well with very high
          contrast, as you noted
  chris: It used to point to obsolete draft of sRGB, now it's updated
  janina: Plan to be smarter in 3, but quite a ways out, so time to get
          it smarter
  janina: would be willing cooperators in that

Media queries in relation to Adapt
----------------------------------

  matatk: Adapt TF is working on, for decades, been through coda and
          aria and now become its own TF
  matatk: What we're trying to do is to facilitate adaptations being
          made for pages to help people with cognitive and learning
          disabilities
  matatk: as well as people who are busy, or have a migraine, or other
          temporary barrier
  matatk: split and focus on different things, but some overlap with
          CSS to talk about

  matatk: Adapt as a whole, got some transformative tech in there
  matatk: but query we have specifically for you relates to potential
          overlap with what some of Adapt is doing and some things you
          can do with Media Queries
  matatk: Most important thing to say about Adapt is, it solves many
          problems, but all very similar
  matatk: it attaches machine-readable metadata at the element level
  matatk: to adapt
  matatk: by adding a little bit of metadata, we can allow the machine
          to make a lot of enabling adaptations on the part of the user
  matatk: I have a demo here, that we can use to discuss

  [shares screen:
http://matatk.agrip.org.uk/personalization-semantics-explorations/distracting-sign-up-form.html
]
  matatk: This is a page that is a distracting sign-up form
  matatk: One thing Adapt spec does is to simplify things for people
          easily distracting
  matatk: for some people can be annoyance, for others can completely
          derail people
  matatk: Really critical, e.g. someone with dementia, someone with a
          severe migraine
  matatk: might need to pare this page down to be absolute core of
          what's required to sign up for this service

  matatk: I've made this page as a demo
  matatk: got things like an animated logo, countdown timer
  matatk: several form fields to fill out, reset and submit
  matatk: a marquee at the bottom

  matatk: Of course if you want to adapt this nowadays can use things
          like prefers-reduced-motion
  matatk: here the image and marquee stop moving
  matatk: but maybe we want to go further than this
  matatk: so attributes in the page allow filtering
  matatk: One is to remove sensory distractions
  matatk: and it's taken away the logo and the marquee
  matatk: I can also say I only want things of medium or critical
          importance
  matatk: and this case we lose some of the form fields
  matatk: that weren't as important
  matatk: If I say only critical things, now also lost the reset
          button, all I have is the heading the clock and two form
          fields and a submit form

  matatk: Example of what can be done with adapt
  matatk: Question is should we be doing more of this with Media
          Queries?
  matatk: My feeling is that MQ are great for providing alternative
          content, but Adapt is also removing content that is
          distracting

  florian: I think this is an interesting and related problem
  florian: encourage you to think about whether author should provide
           all the alternatives
  florian: and let the UA make choices depending on context
  florian: or if you want the UA to tell the author what mode you're
           in, and make adaptations
  florian: Let me give an example outside this field. Discussing
           whether to have MQ for network bandwidth
  florian: if it's too low, maybe want to swap in lower-resolution
           images
  florian: but suppose you enter a tunnel you end up switching to
           loading the lower-res images even though the high-res images
           were already loaded, then reload higher-res images when you
           exit the tunnel
  florian: For such cases, better to let UA make smart decisions than
           expose a mode change to the author
  florian: For this case, if you want UA to make smart dynamic choices,
           provide alternatives and let UA choose
  florian: if best for author to decide, then MQ is more appropriate

  hober: My comment is similar vein, I was immediately reminded that
         many browsers have a feature called "reader mode" or something
         like that
  hober: where the user can make all the "junk" go away and read the
         content of the page
  hober: One of the reasons this works as a browser feature is that
         it's somewhat adversarial
  hober: not a feature that the website author is cooperating with
  hober: if you have some content that is ad-supported, ads on the
         Internet can be very distracting
  hober: images, sounds, etc.
  hober: but the page is not going to tell the browser that this is a
         distraction. They want to get paid
  hober: Florian noted on an important thing, on some level you're
         going to have to think of "remove the distractions" feature as
         something we do to the page, not something that the page wants
         you to do
  hober: Could be that there's both, maybe some amount of author opt-in
         to some of this
  hober: but what you're going to want is AT or something to impose
         this state on the page
  hober: without its cooperation

  PaulG: 2 comments, first having the author provide hints for media
         queries can work in a lot of contexts, especially where context
         is required
  PaulG: e.g. in investment banking, UA shouldn't be guessing what to
         show
  PaulG: Ad situation, have the agency to tip for service or to donate
         to links of our choice, if a site chose to mark their ads as
         optional and I chose to opt in, I'm helping to get paid
  PaulG: but prefers-less-capitalism MQ
  PaulG: With MQ, fact that they apply to page and not individual
         components, I'm worried about that
  <chris> +1 to prefers-less-capitalism
  PaulG: Worried about extensibility in the future when society
         chances, user needs change, how long does it take to get MQ
         added to UAs
  PaulG: how long does it take to permeate to author use
  PaulG: is there another mechanism we should be looking at

  fantasai: If this is a sort of markup, where the UA chooses from
            alternatives, and show/hide content depending
  fantasai: having standardized markup is fine, but I think that makes
            sense to hook it up to a MQ
  fantasai: UA styles could hook that up
  fantasai: if you're choosing between alternatives based on user's
            preference, then as a MQ it makes most sense
  fantasai: can be queried in JS
  fantasai: any kind of adaptation can be made based on that

  fantasai: The example of image loading Florian gave doesn't really
            apply here
  fantasai: it's about time lag in that case
  fantasai: not a factor here
  fantasai: here, if you're switching modes you're want to switch modes

  fantasai: I agree with Tess some amount of stuff will need to be
            handled by the UA itself
  fantasai: as far as how long it takes to add a MQ, if the user is
            somehow expressing a preference, and we need to expose it
            to the page, whether automatically based on metadata in the
            page, or having a MQ, the browser has to do something to
            make that happen
  fantasai: so once we have a framework for a MQ, adding values to it
            won't take long

  fantasai: Lastly, you are adding more information about the user,
            exposed to the page, no matter how you do this
  fantasai: if you add/remove content, the page can know about it
  fantasai: if you have MQ, it can also see that
  fantasai: There's privacy implications to exposing this, but the page
            will know regardless of which technique we use
  fantasai: there's more fingerprinting surface

  fantasai: more complexity for the author. If it's too complex for
            the author they won't use it

  Rossen: Most of the things I wanted to mention already captured
  Rossen: Demo page is great, thanks
  Rossen: I was hoping we can see an issue opened with CSSWG that we
          can consider at least simplification for MQ
  Rossen: can see something like prefers-simplification
  Rossen: and have authoring that helps identify what's critical medium
          and low
  Rossen: This is a great example where the ?? of the MQ can help
  Rossen: distraction is something we have discussed in the past
  Rossen: more to discuss in the TAG
  Rossen: It's the most contentions, I don't know if possible to
          satisfy with MQ
  Rossen: but maybe open some issues

  matatk: Can I show a 2-minute demo?

  florian: I agree with fantasai the example I gave doesn't apply here,
           but you gave us a small sample of bigger project
  florian: is this a MQ, the weird scenario doesn't apply here, but
           that's a criteria I would use to think about it
  florian: but so far that wouldn't apply and media query seems
           appropriate

  Rossen: We have at this point crossed the halfway mark in our time
  <Lionel_Wolberger> The simplification link,

https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html

  matatk: Problems that we're trying to solve are for many users
          helpful, and for some users absolutely critical
  matatk: they aren't necessarily the issues that may be of highest
          priority if you look at content usability guidelines
  matatk: because some of them are very bespoke to content involved
  matatk: but issues we're trying to solve are the ones that are
          solveable by the machine
  matatk: with just a little bit of metadata at the element level
  matatk: so collection of problems that we're solving, and that's the
          technique we're using to solve them

  Rossen: When you say solved by the machine, can you define that for
          us?
  matatk: We expect this would be a UA adaptation to the content
  matatk: and by UA what we mean for the foreseeable future, a browser
          extension
  matatk: Might be many browser extensions for different groups of users
  matatk: because it varies a lot
  <PaulG> user agent or assistive technology (AT)?
  matatk: so really encourage anyone to make an extension to cover any
          bit of the spec, using any technique appropriate for their
          user
  matatk: UA would be modifying the DOM on behalf of the user
  matatk: because it's coded for a particular group
  matatk: going off of markup that the author provides
  matatk: to provide hints
  matatk: Let me show this demo
  PaulG: Clarify that matatk was saying UA, would be assistive
         technology. Doesn't need to be in the AX tree
  PaulG: examples of plugins and extensions
  PaulG: this can be prototypes with markup, and help make a media query

  matatk: Here's an example, created by Lisa Sieman
  matatk: it does have a button in the page, although if this was an
          extension, it would be in the browser UI
  matatk: This is a clothes retailer with a contact form, many fields
  matatk: navigation across top of page, lots of categories
  matatk: when I press personalize page, get some visual preferences
          applied
  matatk: slightly fewer categories
  matatk: one fewer form field in the form
  matatk: and then step down to even fewer
  matatk: One of the things in our discussions is, some people say "I
          might not want this simplification, might want a different
          simplification"
  matatk: e.g. Sports/Leisure rather than Men/Women
  matatk: MVP doesn't handle this, might have less control over how
          filtered but just does get filtered
  matatk: want to make sure that filtering uses interest in the future
  matatk: some sites have done demographic data, can alter markup based
          on info they know about the user
  matatk: can do even with this markup

  Rossen: Next steps, so we have closure on this issue
  Rossen: I encourage you to open issues and propose specific
          candidates for media queries
  Rossen: and then you have people here would would help you reason
          about how that can progress through CSS

Work on Navigation
------------------

  matatk: Context, I have a link to minutes from Sapporo 2015 TPAC
  <matatk> https://www.w3.org/2015/10/30-apa-minutes.html
  matatk: We saw mention of this in your new charter, work on
          navigation, wondering if it's a continuation of that
          conversation or something totally different?
  matatk: It seemed to be discussing issues around DOM order vs visual
          order
  matatk: controlling that through CSS
  matatk: or is it about some new research on spatial navigation
  <chris> proposed new charter
https://w3c.github.io/charter-drafts/2022/css-2022.html
  astearns: I think charter might be referencing the spatial navigation
            draft
  <astearns> https://drafts.csswg.org/css-nav-1/
  <heycam> there is also this paragraph:
  <heycam> In addition to the above catch-all reference to horizontal
           review which includes accessibility review, this Working
           Group will work with the Accessible Platform Architectures
           Working Group to work on accessible navigation which needs
           to be addressed coherently across multiple modules, address
           accessibility issues related to the features of individual
           modules, and develop new CSS modules to address
           accessibility use cases where appropriate.

  Rossen: Here's my 30-second review of 2015 minutes interpretation
  Rossen: my recollection was that we had an extensive conversation
          which took place right before we introduced a lot of the
          order properties for Flexbox and Grid
  fantasai: Must have been after, Flexbox was published as CR in 2012
  Rossen: Perhaps motivated by that
  Rossen: We have DOM that has an order, applying styles that change
          the order
  Rossen: whether tabbing or using AT to move spatially in the page,
          order is usually that of the DOM, and visual doesn't match
          the content
  Rossen: that was the basis of that conversation
  Rossen: At the time our position was that CSS has a strong
          recommendation for creating accessible content based on DOM
          and follows DOM order
  Rossen: fantasai has some good posts about this
  Rossen: and that was then
  Rossen: Since then we've done some work on spatial navigation, which
          was motivated by other media such as screen navigation on TV
  Rossen: where you have a directional pad for input
  Rossen: and some effort to make that work in general, regardless of
          the page layout
  Rossen: These were the two efforts, and I think they're slightly
          separate
  Rossen: in terms of efforts we were chasing
  Rossen: but I wouldn't say they're mutually exclusive

  matatk: Things you've been working on, this ED is dated 17th of May
          last year, is it still active work?
  florian: I'm editor of that document
  florian: It got to a reasonable degree of completeness, but it has
           since stalled
  florian: there hasn't been significant effort for quite some time
  florian: I still think it would be a good idea
  florian: but given insufficient amount of attention, can't say it's
           an ongoing path forward atm
  florian: for now it is stalled
  <PaulG> "stalled" that's a shame. It seems like a great mechanism for
          authors to accommodate input development and a welcomed
          replacement for roving tab index keyboard handling JS.

  rachelandrew: Separately to that issue, there was a proposal that I
                raised
  rachelandrew: which was to create a way for authors to opt into the
                display order
  rachelandrew: a lot of interest from devs to do that
  rachelandrew: because although I think document order is generally
                what should be using
  rachelandrew: there are cases where, e.g. when content is rearranged
                by MQ
  rachelandrew: also have some layout methods that jumble the order
  rachelandrew: such as masonry
  rachelandrew: so a lot of discussion in that issue
  rachelandrew: This is definitely something that needs to be solved
  rachelandrew: authors want to do the right thing
  <heycam> https://github.com/w3c/csswg-drafts/issues/7387
  rachelandrew: We've given them this ability, and saying don't use it,
                is not great
  rachelandrew: would really like to see this solved in a good way

  matatk: Thanks for that, Rachel
  matatk: My question is, the work on spatial navigation was motivated
          by things like smart screens, webTV, etc
  matatk: and as Rachel said, with new layouts
  matatk: I'm wondering, given that the spatial navigation spec isn't a
          REC yet
  matatk: what do you see devs doing in the wild to try to provide
          this, or not provided?
  rachelandrew: I think that we're seeing people either not doing
                things that they would like to do for lots of users
                because of a11y issues
  rachelandrew: and others who are not caring and do terrible things
  rachelandrew: as you see more visual tools that allow drag-and-drop
                layouts, easy to do now with grid
  rachelandrew: those completely disconnect the author from the
                document, and will create situations like this
  rachelandrew: I just feel like this is an issue that we have to solve
  rachelandrew: not say "they should follow document order", I don't
                think that's realistic
  rachelandrew: At the moment people who want to do the right thing do
                not have good options
  rachelandrew: what's a good user experience?
  rachelandrew: creates problems for navigation
  rachelandrew: so I want to give people a good way to do this

  fantasai: I think we need to pursue both of these things
  fantasai: they're not exclusive and both are needed
  fantasai: going through a linear order is a bit different
  fantasai: spatial nav has different requirements from doc order
  fantasai: we should accommodate both
  fantasai: sometimes I want to navigate physically down, and sometimes
            I want to go to the next thing
  Janina: Thanks for suggesting both are important, I agree

  Janina: previous and next as we have them in HTML, can be inadequate,
          and publishing as long has a more elaborate hierarchical model
  Janina: easiest to illustrate if you consider a play
  Janina: multiple acts, and in each act there are scenes
  Janina: You may have to take a lot of steps to get in linear order
  Janina: but if you can adjust your granularity, going to scene 3 in
          act 4
  Janina: then you get there far more quickly
  Janina: They've had that in publishing forever, came out of talking
          books
  Janina: been effective in most cases, works very well
  Janina: Would be clever if we could have cookbooks that automatically
          read just such as what's top level, what's next level, etc.
  Janina: based on types of cuisine or whatever
  fantasai: I agree having a hierarchy would make that easier to manage
  Rossen: This is handled by many ATs, can move by e.g. headings etc.
          But only works so long as document has good structure

  matatk: If you're not using AT, in the traditional sense, and just a
          keyboard-only user
  matatk: and there are many such users
  matatk: then they do have a lot of work
  matatk: keyboard-only users only have tab and scrolling and that's it
  matatk: what Janina said about granularity of linear navigation
  matatk: Remember an app where the developer had made hierarchical,
          tree-based order
  matatk: initial navigation was across tab panels, and then can enter
          into each panel and navigate through there
  matatk: They had to take it out because it was unfamiliar and not
          documented well
  matatk: it would be great to have a standard conventional mechanism
          for it

  PaulG: Especially in light of what we were talking about before, of
         ripping out content based on user's request for less of it
  PaulG: this presents a difficult challenge for devs to get keyboard
         navigation correct
  PaulG: when predicted display is more complex, effect of both
         author's content and users preference
  PaulG: maybe dangling keyboard handlers with no next, or traps that
         appear out of nowhere
  PaulG: need to consider chances of authors really messing this up
  PaulG: so I think this spec is on its way and would like to get
         involved to make sure we have those mechanisms for the future
  PaulG: and love to replace every instance of tabindex I have

:role() pseudo-class
--------------------
  github: https://github.com/w3c/csswg-drafts/issues/3596

  Rossen: Can someone summarize this issue?
  matatk: Is this a shortcut for the attribute selector? Seems to be
          syntactic sugar
  fremy: There are some differences, handles roles that are implied as
         well
  <TabAtkins> Yeah, handling implicit roles is the big point
  PaulG: Map to computed role from Chrome's implementation
  fremy: Could do it yourself with correct attribute, but simplified way
  heycam: Is computed role only a function of role and tag name, or
          more things?
  matatk: Landmarks, I maintain an extension to navigate, and where
          they are in the document determines what they are
  matatk: e.g. if header/footer are scoped to page you have page header/
          footer
  matatk: but inside an article, not the same landmarks
  matatk: not that simple, so I can understand why if browser does the
          matching it would be useful
  PaulG: What's the status of it?
  Rossen: There's a group discussing this with ARIA
  TabAtkins: Several years back we resolved to add this, to expose
             computed roles to selectors
  TabAtkins: several years after that, I raised this issue saying that
             I was supposed to draft it
  TabAtkins: still haven't written it
  TabAtkins: if any concerns about it, please file issues/comments
  TabAtkins: Otherwise this is just something that needs to be written
             by me at some point, because I signed up for it

  Rossen: With this, we are out of time
  Rossen: thanks APA for joining us
  <matatk> thanks everyone for warm welcome, great discussion and to
           fantasai for the excellent scribing!
  Janina: Thanks for your hospitality
  Rossen: Please do engage on the issues
  Rossen: we love to work with you
  Rossen: if you find a liaison, would love to work with them
  matatk: File issues is the theme for this week!

  <jcraig> re: :role() selector... I may have proposed it early on but
           we abandoned the idea when implementation discoveries made
           it apparent it would be way more effort that the benefit
           justified
  <jcraig> My comment here:
https://github.com/w3c/csswg-drafts/issues/3596#issuecomment-460135566
  <jcraig> gist: It’s not impossible, but it’s quite a bit more than
           anyone was willing to commit to.

<br duration=10m>
Received on Tuesday, 25 October 2022 22:38:08 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC