- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 15 Nov 2016 21:27:25 -0500
- To: www-style@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.
=========================================
Joint Meeting with A11y Working Group
=====================================
CSS A11y Task Force/CSS AAM
---------------------------
- A brief summary was given of the purpose of the task force and
what it hopes to achieve.
- The charter for the task force will be amended to state that
publications will be made jointly.
- Rossen had volunteered to help this effort and was looking for
more CSSWG members to join.
- Several members of both working groups volunteered to work
on editorship and a best practices document/questionnaire
- There were concerns about a separate task force ending up in a
silo; but it was clarified that everyone in CSS WG will need
to be aware of a11y tasks and the task force members are there
to coordinate and lead the effort.
- The task force will start out with technical discussions over
github and ~monthly telecons to sort out issues that can't be
resolved on github.
- There are two places where CSS affects accessibility; when it
effects structure like injecting generated content and when it
makes the visual order dramatically different than the DOM
order.
- The task force will look to document the best practices for
authoring and ensure that CSS specs are following those best
practices.
Media Queries for ARIA-details
------------------------------
- There was a request to have a media query to say that the page
should display additional descriptions. This will be worked
in with the rest of the user-preference MQ work in L5.
Navigation
----------
- Task force will need to deal with problems around navigation.
- The document from APA listing the problems is here:
https://www.w3.org/WAI/APA/wiki/Category:CSS_Navigation
- There was a desire to ensure that any changes to the a11y tree
that are also not reflected in the keyboard focus order.
Grid
----
- The APA doesn't anticipate objecting to the Grid transition
request.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda
Present:
Rossen Atanassov - Microsoft
Tab Atkins - Google
L. David Baron - Mozilla
Brian Birtles - Mozilla
Bert Bos - W3C
Rick Byers - Google
Tantek Çelik - Mozilla
Dave Cramer - Hachette
Emil A Eklund - Google
Behdad Esfahbod - Google
Elika J Etemad - Invited Expert
Daniel Glazman - Disruptive Innovations
Jihye Hong - LG Electronics
Dean Jackson - Apple
Ian Kilpatrick - Google
Pierre-Anthony Lemieux - supported by MovieLabs
Vladimir Levantovsky - Monotype Imaging Inc.
Chris Lilley - W3C
Myles C. Maxfield - Apple
Theresa O'Connor - Apple
Simon Pieters - Opera
Liam Quin - W3C
Matt Rakow - Microsoft
Manuel Rego - Igalia
François Remy - Microsoft
Florian Rivoal - Vivliostyle Inc.
Andrey Rybka - Bloomberg
Shintaro Sakahara - BPS
Hiroshi Sakakibara - BPS
Simon Sapin - Mozilla
Geoffrey Sneddon - Invited Expert
Alan Stearns - Adobe
Shane Stephens - Google
Surma - Google
Lea Verou - Invited Expert
Jet Villegas - Mozilla
Mark Watson - Netflix
Greg Whitworth - Microsoft
Steve Zilles - Adobe
Regrets:
Rachel Andrew - Invited Expert
Dael Jackson - Invited Expert
Scribe: fantasai
Joint Meeting with A11y Working Group
=====================================
<richardschwerdtfeger>
https://www.w3.org/WAI/APA/task-forces/css-a11y/work-statement#main
Janina: Idea was that we'd organize our work.
Janina: Started to see same issue with multiple specs.
Janina: Don't want to hold back CSS, but have some real issues wrt
accessibility
janina: Wanted to bring together APA and ARIA expertise.
janina: Don't want to go off on our own and misinterpret the spec.
janina: Together there are certain things we can do that would
help, and ultimately solve issues we've identified.
janina: For instance, had good success in ARIA WG with mappings.
janina: a11y API mapping specification.
janina: Worked through W3C process through REC, tested and
implemented and implementable.
janina: Test and validate your implementation of a11y.
janina: Many things can be handled by CSS-a11y mapping, that's why
ARIA is involved.
janina: Until a week ago, a11y mappings were owned by ARIA... HTML
mappings are their own story.
janina: Furthermore, some access among our various members to the
various platforms where we are mapping.
janina: So if we're missing support on the OS side, have
opportunity to do something there.
janina: Whether that covers everything, expectation is probably
not.
janina: May need a Best Practices as well.
janina: But after looking at various issues, group that goes to
work on this can decide what gets handled
janina: Another AAM, best practices, and maybe some tweaks to
specs.
janina: talk about that it coordinated and cohesive manner.
janina: Excited about this, overdue collaboration.
CSS AAM/CSS A11y Task Force
---------------------------
janina: Wrt draft of ?, Michael and I did some work on it
<MichaelC> -> https://github.com/w3c/aria/tree/master/css-aam CSS
AAM stub (will migrate to a new repo soon)
<MichaelC> -> https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features
CSS AAM Potential Features
janina: APA approved it, but it's a starting point.
janina: Will have a TF, chairs will appoint facilitators.
janina: Expecting group will meet on some regular schedule, a lot
of async communication, some telecons, etc. usual range of
tools for communication.
janina: That's organizational perspective we've put forward.
janina: Also had a document prepared for us, making argument for
why we though TF was really necessary.
janina: Prepared by one of our members who suddenly and
unexpectedly is no longer part of W3C.
janina: Didn't get that email til yesterday...
janina: Was hoping she'd give us a quick overview of the issues.
janina: Asked Rich to give an overview.
richardschwerdtfeger: OK, so, how this started is we had found
some issues where CSS was injecting content,
and we didn't have mappings across the
browsers for that.
richardschwerdtfeger: We'd also found issues with Flexbox, working
through that.
richardschwerdtfeger: Have been working with HTML and SVG, and all
those languages have mapping specs.
richardschwerdtfeger: Able to make issues, make sure what you put
in gets mapped.
richardschwerdtfeger: Talked with Rossen about how to go about
this.
richardschwerdtfeger: Wanted to make sure a11y issues are
addressed early on, because CSS critical to
web.
richardschwerdtfeger: So platform was created.
richardschwerdtfeger: Don't need mappings for everything, but
those things that are critical.
richardschwerdtfeger: TF is members of a11y and CSS, addressing
a11y issues.
richardschwerdtfeger: Make sure that content and presentation is
addressed by WG as a team.
richardschwerdtfeger: We haven't agreed on TF work state, next
step is how do we populate a group that will
work on these issues together.
richardschwerdtfeger: Was just told by joanie diggs (????) who
would like to be an editor, but need more
than that. Need members of CSSWG.
Rossen: I think that's a great summary.
Rossen: I've been communicating what we've talked about with the
CSSWG, we have few telecon time slots to talk about going
forward, how to proceed in terms of participating in TF
and what TF is actually going to do.
Rossen: Quick summary for benefit of everyone, of what mapping
spec is.
Rossen: They are fairly different from most specs we do in CSS.
richardschwerdtfeger: What people often don't think about when
creating Web content is that they're
contributing to a software application.
richardschwerdtfeger: Every OS has a11y services that communicate
necessary info to assistive technology, e.g.
text on screen, role is, how it relates to
other content, where the keyboard focus is,
etc.
<joanie> Example mapping spec:
https://rawgit.com/w3c/aria/master/core-aam/core-aam.html
richardschwerdtfeger: That info is mapped to platform API
richardschwerdtfeger: On every single OS
richardschwerdtfeger: So write once, accessible on all platforms
richardschwerdtfeger: as long as you write accessible code.
richardschwerdtfeger: In CSS, when you do things like inject
content, want to make sure it maps to those
services.
richardschwerdtfeger: For HTML ARIA try to make mappings for that
richardschwerdtfeger: We do ...????.
richardschwerdtfeger: Would do same thing here.
richardschwerdtfeger: You end up behaving just like accessible
software app on that platform.
Florian: Since CSS doesn't exist in a vacuum but exists on top of
HTML.
Florian: Mappings we define here, just need to have difference
from HTML mapping, right?
richardschwerdtfeger: Yeah for example with content injection in
CSS.
richardschwerdtfeger: Doesn't show up in DOM, there's an OM that
shows up.
astearns: Before going into details, ChrisL on the queue.
ChrisL: Gone through work statement, in general it's fine.
ChrisL: One thing that is different from our charter, our charter
says that documents will be co-published
ChrisL: Whereas work statement here is that one group will
publish. Sort of uncomfortable.
janina: Don't think we meant that, did we ?
ChrisL: Willing to change?
janina: Yes.
ACTION Janina fix charter to co-publish
Rossen: I'll try to give quick summary of work that was identified
for the TF.
Rossen: Problem statement here is that CSS affects the a11y layer
in 2 major ways.
Rossen: First one is when we end up affecting structure like
injecting generated content, or in case of table fixup,
more elements that are mapped.
Rossen: Second part that we've been having a11y related issues
have been when there's visual changes that are drastically
different from DOM order, such as flex-order property.
<Rossen> https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features
Rossen: So in order to get things going, Cynthia Shelly who was
Microsoft representative for APA and other a11y groups
created a quick outline of all of the modules that might
have a11y issues.
Rossen: As you can see, breakages the work that will be covered,
related to reading/navigation order.
Rossen: Flexbox, grid and positioning are called out explicitly.
Rossen: There is generated content and ...
Rossen: Documents of existing features that are implemented
Rossen: e.g. Generated content
Rossen: Which is supposed to be accessible, but isn't implemented
as such.
Rossen: Did some work in Edge recently to address some of these
issues. Can attest that this type of work is not all that
hard to do, and improves a11y layer a lot.
Rossen: Don't want to list all the specs out loud but this is set
of work that has been identified.
Rossen: Kickstart discussion
Rossen: I have volunteered myself
Rossen: to join the TF and help the work forward
Rossen: Would be very happy to have other CSS members.
astearns: Two questions. One is question of editorship -- who is
tasked with putting all the info into the document?
astearns: Then further question of just participating in the TF,
not necessarily writing specs.
astearns: Are you also volunteering yourself as an editor?
astearns: Anyone else from CSS interested in the TF for
participation?
astearns: I am definitely interested.
astearns: Francois & Greg from Microsoft.
dauwhe: I'm interested.
jcraig: Me too.
iank: Participation wrt Houdini.
astearns: Editing?
MichielBijl: I'm interested, from APA.
fantasai: I'm willing to help out.
fantasai: I think one thing that I should be working on is the
Best Practices document.
astearns: Was at chairs breakfast this morning, talking about wide
review especially by groups like APA.
astearns: One thing that helped me in my writing is not just
having a Best Practices document, with criteria.
astearns: But having a list of questions, like the security
questionnaire.
astearns: Short questionnaire so as people stat writing specs,
they have something to refer to.
astearns: Maybe some of the work in best practices can be done as
a short questionnaire on accessibility gotchas that
editors can refer to.
Rossen: I think fantasai was referring to ... we committed last
TPAC to write best practices for authors of CSS.
Rossen: This is something that will go a long way, I think there
will be value of having reference directly from CSSWG.
Rossen: Can hold this as formal recommended practices from our POV.
MattKing: I'm willing to collaborate on best practices, so that we
refer to each others' documents
MattKing: ARIA authoring practices guide
<MichielBijl> -> http://w3c.github.io/aria-practices/
<fantasai> http://fantasai.inkedblade.net/style/talks/best-practices/#title
MichaelC: We were focused on a11y mapping specification.
MichaelC: Not sure that best practices belong in ARIA best
practices.
Matt: Want to make sure documents are coordinated.
MichaelC: What I do with TFs is to set up an ? in formal W3C
infrastructure for participation.
MichaelC: Will have to talk about ML, anyone object?
ChrisL: Certainly not objecting. In this WG we're trying to move
away from MLs to GitHub.
ChrisL: Would encourage TF to work on that.
MichaelC: Put in link to ? would move it new github repo.
MichaelC: Do you want me not to set up an ML?
ChrisL: No, go ahead, useful for some stuff.
MichaelC: Didn't want to do without permission.
jcraig: Rossen mentioned pseudo-elements mapping to a11y layer.
jcraig: Generated content mapped in majority of browsers... Chrome
and Safari at least... Possibly Firefox. [Joanie responded
~"-ish"]
jcraig: The issue that Michael just brought up that's interesting
is, a separate github repo...
jcraig: I have reservations about accessibility TFs within WGs.
jcraig: It ends up getting groups of people siloed, so a11y people
on one side and CSS people not in the TF don't learn about
the a11y side.
jcraig: My general approach is that this type of work should
happen in the main group.
jcraig: I feel that works a little bit better.
<fantasai> +1
astearns: I share your concerns.
jcraig: Separate github repo ..
astearns: I think github repo for deliverables is ok.
astearns: My expectation for TF is that it's a coordination
function.
astearns: CSS folks in TF wouldn't be only ones doing work, would
be the ones outlining the work and drawing in each
editor as specs need mapping, adjustment, review, etc.
astearns: On CSS side, people not directly on TF, don't assume
that you have no a11y work that is going to be assigned
to you!
astearns: Just TF people will be ones coordinating.
MichaelC: Core stuff about how CSS maps into a11y
MichaelC: Often times a piece of that work will start in that
spec, and then needs to move xyz place.
MichaelC: I think coordination role of TF makes that easy to do.
MichaelC: TF can set up preferences for access to repo to everyone
or just editors or whatever.
MichaelC: Also want to know if people involved prefer or oppose
telecons.
Rossen: I'm in favor of starting with light telecon requirements.
fantasai: Maybe monthly?
Rossen: Yeah, something like that. Otherwise work on github issues
etc.
MichaelC: Also what level of checking goes through WG?
MichaelC: e.g. sometimes TF will go to parent WG for each thing.
fantasai: Probably we'll do both.
fantasai: If an issue is a bug fix, then it just gets written.
fantasai: If it's a design issue, it will go back to the WG for
feedback
fantasai: (to make sure people are paying attention)
fantasai: issue-by-issue basis.
janina: I imagine it's going to come up regularly to consult with
the APA.
<jcraig> +1 for most (all?) discussions happening on GitHub rather
than conf calls, as conf calls are imprecise, and
inaccessible in both senses of the word.
<tantek> also +1 technical discussions on GitHub rather than
mailing lists.
<MichielBijl> +1
janina: In APA we regularly go over a spec, assign someone to read
about a new spec and report to the csswg.
Rossen: What I was saying is, let's start with the TF as an
issue-generator
Rossen: We often have technical discussions, imagine those that
require design change and will have to do with larger
participation.
MichaelC: We'll need to pull in... make sure we have expertise
from both sides for the border.
astearns: At minimum I'd like to see notification, this is what's
been discussed, here's the minutes.
astearns: In most cases don't need extra step of "did we do OK?"
jcraig: Regarding what's discussed, minutes.
jcraig: I have a lot of trouble following minutes.
fantasai: Have you tried following CSSWG minutes?
jcraig: Those are different.
jcraig: But in general, easier to follow discussions on github.
jcraig: More accessible in all ways.
jcraig: Can have full, precise discussion at any time.
jcraig: So prefer to have discussion in text on the Web, most
accessible.
MichalC: That said, when disagreements, often easier to sort out
in telecons.
astearns: In CSSWG, as we discuss things on the phone or in F2F
meetings, as opinion coalesces, people update github
issues to say what we discussed, what we decided, where
are the minutes.
astearns: Think that's a good practice going forward.
jcraig: Important to summarize, not just link to minutes.
[discussion of what to discuss]
Media Queries for ARIA-details
------------------------------
janina: Trying to avoid using the word, cuz lots of controversy
over attribute, but trying to get beyond that because
requirements....
[jokes about longdesc]
janina: Trying to get beyond that, firstly because we don't like
doing things that are opposed by browser makers
janina: Secondly have more general requirements from dpub.
janina: Issue is, we want to make it possible for someone who
isn't using AT to be aware of e.g. simplified description
or braille alternative.
<jcraig> AT == "assistive technology"
janina: We have ways to do this for people who use assistive
technology.
janina: What we're looking for is for people who don't use AT to
get at that additional information, alternative
information.
janina: Want them to know that ARIA-details is available.
janina: Idea was to make extensions/plugins to experiment.
janina: The short-term ask is, can we have an MQ that all it does
it says that this element has an extended description.
janina: Also looking at extended MQs.
Elliott: what is the aria thing you're talking about?
Elliott: What computes an aria...
Elliott: You wanted an MQ on ARIA-details, what computes
ARIA-details?
dbaron: I'm also a little confused that you're asking for an MQ
that's asking about the state of an element.
dbaron: MQs are about the presentation context, not about
qualities of a particular element.
dbaron: Were you maybe wanting a selector?
<tantek> maybe even a pseudo-class?
jcraig: I think that what we were discussing is related to new
aria property that is a string of text that isn't
displayed anywhere.
jcraig: More or less the same as details and summary in HTML.
jcraig: I believe what janina is asking for is a media feature
that allows you to detect when the user wants to see
additional details.
jcraig: If that's the case, then the design, the CSS should be
able to display additional text.
janina: Close but not quite.
richardschwerdtfeger: What digipub wants to do is to show extended
descriptions for drawings on the page.
richardschwerdtfeger: This could be alternative formats, could be
a whole variety of things.
richardschwerdtfeger: Problem with digital publish is that by
default, publishers don't want this
information rendered on the screen.
richardschwerdtfeger: But need ability to know that it's there.
richardschwerdtfeger: They want to put the content in the pages,
and they want to be able for the user able
to activate a setting in the browser, that
would tell the book for example, to expose
this detailed information with drawings.
richardschwerdtfeger: What they're asking for is the ability write
a custom media query.
richardschwerdtfeger: Maybe through a plugin in the browser.
richardschwerdtfeger: So that they could turn on a feature that
activates CSS to expose that information on
the page.
richardschwerdtfeger: No opinion in interface.
richardschwerdtfeger: Details attribute in ARIA simply says that
that extended description is associated with
this other thing
richardschwerdtfeger: But publishers want to not impact the normal
visibility of the page, because they want to
preserve the intent of the publisher.
richardschwerdtfeger: But for people who need the extended info,
want to be able to turn that on.
richardschwerdtfeger: MQs are generally about OS/device
capabilities.
richardschwerdtfeger: But this is about preferences.
astearns: A user preference.
Florian: co-editor, Media Queries
Florian: dpub was still thinking about this idea yesterday.
Florian: If it's just about the details element, then seems too
specialized for MQ.
Florian: But if it's a general "if there's extended descriptions
in the page, user wants to see them"
Florian: This is going into new area of user preferences.
Florian: Related to preferences for inverted colors, high
contrast, etc.
Florian: We're exploring this category.
Florian: Seems to fall into this category, but for e.g. invert
colors, might be thing wishes to see OR might be thing
user wishes to see but might have been forced by browser.
Florian: Wrt details, browser can't do it for you, page has to do
it itself.
Florian: Need to explore more, but given what we've discussed
today.
Florian: Makes sense to me.
Florian: Another thing is custom media queries.
Florian: We've also discussed custom MQs, based on whatever JS
wants to compute.
Florian: I'm not sure how this would work out in this case
Florian: Because in the case of custom MQs, this is the JS in the
document talking to CSS in the document view MQ
Florian: But for this case, you want the plugin to talk to the
page via browser.
Florian: It doesn't seem to really be custom, seems to be standard.
rich: Also talked about "I would like to render different content
based on my preference"
rich: Management systems, working on today, have ability to store
personal info about the user.
rich: I would say that we quite know exactly what those are going
to look like.
rich: This is why extending MQ is a better solution, experiment
and figure out what we really need.
Florian: If it's about prototyping, then yes makes sense for
extending.
Florian: We had custom MQs in Level4, but are deferring to L5
because less stable than other stuff in L4 currently.
Florian: At the moment it's unclear whether will go into MQ or
Houdini spec in the future
Florian: But definitely on the radar.
Florian: Tab and I will be working on it, will either go into a
Houdini doc or MQ L5 which we will be starting soon
because we're wrapping up L4 nowish.
jcraig: ... Toggles value of a media feature, tells web page it's
ok to expose this info
jcraig: Mentioned working on custom MQs, similar to data-*
attributes in HTML. Allowed to do anything you want, no
consistency across websites.
jcraig: Is there an affordance here for a standard taxonomy?
jcraig: We'd be discussing something like
-epub-prefers-extended-descriptions.
jcraig: If there's a list of standard taxonomies, where would that
live.
Florian: From my understanding this would be about prototyping in
a limited context where people have agreed on common
semantics.
Florian: Once it's no longer experimental, no longer needs to be a
custom MQ, can be a standard MQ.
Florian: No need for prefixing.
Florian: ...
Florian: Room for experimentation if it's boolean, expresses ...
Florian: But once no longer prototyping, should be a standard MQ,
not a custom one.
Navigation
----------
astearns: Move on to navigation?
[discussion of whether to discuss navigation issue]
<MichaelC> -> https://www.w3.org/WAI/APA/wiki/Category:CSS_Navigation
Specs APA thinks are related to the CSS navigation
issue (there are more, still need to tag them)
rich: There are times in Flexbox where order is important to user
of AT
rich: What we had was, Flexbox was changing things visibly on the
screen but it wasn't reflected in how it maps to the a11y
services layer.
rich: You're looking at things in a sequence.
rich: That was first part of the problem.
rich: Second part was that the keyboard navigation didn't quite
follow the visual order on the screen
rich: So someone who is blind and is trying to navigate, didn't
make sense.
rich: There needs to be a discussion on how that can be corrected.
At the mapping layers, and also how keyboard navigation is
addressed.
rich: We had proposed a way to deal with keyboard navigation when
necessary, but much more work that needs to go on in the TF.
rich: When do we change the order? Should we change the keyboard
order when Flexbox vies display on the screen? Etc. That
needs to be discussed.
Grid
----
astearns: Last item.
astearns: Grid.
<MichaelC> -> https://www.w3.org/WAI/APA/wiki/CSS_Grid_Layout_Module_Level_1
APA notes on Grid
fantasai: We're planning to transition grid to CR.
fantasai: I emailed you at start of year. I think that's going to
happen this week.
fantasai: Wanted to check with you if there's any objections to
this transition.
rich: Wasn't involved in that discussion, and have sense where
grid is mapped correctly.
rich: Structural information in CSS, needs to be mapped into a11y
tree with rows/columns.
rich: More capability to do that in ARIA 1.1
rich: Haven't looked at Grid, things need to be looked at in terms
of accessibility tree.
Matt: Want to make a statement.
Matt: So, Rich just said that with grid, when affecting structure,
needs to be mapped to a11y services layer.
Matt: Want to make statement that we should not make any changes
to the a11y tree that are also not reflected in the keyboard
focus order.
Matt: That's very important, that order of a11y tree matches
keyboard order.
Matt: That's really important for combination of touch and
keyboard. Do not separate these two orders.
janina: I think maybe we need TF to makes this a priority.
janina: Since you're going to CR, not blocking, happy to be on a
path to a solution.
janina: More tools to offer, prioritizing is important.
astearns: Grid is important.
jcraig: Navigation index?
<tantek> jcraig: nav-index was dropped long ago
janina: Best summary is Cynthia's document.
Rossen: Back to grid question for minutes, what I heard from APA
there is no current objection to proceeding to CR, will
work through issues in TF.
Rossen: If any changes come up, we will take...
janina: This is a chair expressing her opinion.
MichaelC: Wanted to say that we have a wiki page for every spec
that we look at, and our notes on grid are that we did,
three months ago, plan to work on this in the TF. So
don't think we were expecting to object to a transition.
Florian: Don't know if you're aware of it, there is in CSS4 UI
nav-up/down/left/right properties for spatial navigation.
Florian: The ordered variant of the same, nav-next/nav-prev, are
not specced.
Florian: If you would like them to exist, let us know. If you
think they'd be terrible let us know as well.
Florian: There is something along these lines in CSS3 UI.
jcraig: Tantek just posted that they died a long time ago.
tantek: We took nav-index out completely years ago.
tantek: Based on feedback from a11y and other feedback.
jcraig: up/down is still there?
tantek: Yes, in multiple implementations, referenced from TV specs.
?: I like that for SVG a lot.
astearns: OK, out of time, thanks.
janina: thanks CSS
astearns: CSS will be on break for the next 20 minutes
<MichielBijl> Thanks all!
janina: APA in our room at 11!
<br>
Received on Wednesday, 16 November 2016 02:28:30 UTC