- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 25 Oct 2022 18:37:25 -0400
- 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:07 UTC