- From: Belov, Charles <Charles.Belov@sfmta.com>
- Date: Thu, 17 Nov 2016 03:00:51 +0000
- To: "www-style@w3.org" <www-style@w3.org>
- CC: Dael Jackson <daelcss@gmail.com>
> -----Original Message-----
> From: Dael Jackson [mailto:daelcss@gmail.com]
> Sent: Tuesday, November 15, 2016 6:27 PM
> To: www-style@w3.org
> Subject: [CSSWG] Minutes Lisbon F2F 2016-09-20 Part I: Joint Meeting with
> A11y Working Group [mediaqueries] [css-grid]
>
> =========================================
> 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.
Would better read:
- There are two places where CSS affects the accessibility layer; when it
affects structure like injecting generated content and when it
makes the visual order dramatically different than the DOM order.
because "layer" is what is said below in the full minutes, and the "layer"-less summary gives a different impression. This is a significant difference because CSS also affects contrast, font size, and motion, all a11y issues, just not necessarily in the a11y layer.
> - 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>
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency
1 South Van Ness Avenue, 3rd Floor
San Francisco, CA 94103
Email: charles.belov@sfmta.com
Phone: 415.701.4388
www.sfmta.com
Find us on: Facebook Twitter YouTube
Received on Thursday, 17 November 2016 03:02:56 UTC