Minutes: SVG A11y TF meeting 8/9

Minutes from today's call are available here: https://www.w3.org/2016/08/09-svg-a11y-minutes.html

A plaint text version is available below:

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

              SVG Accessibility Task Force Teleconference
                              09 Aug 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/08/09-svg-a11y-irc

Attendees

   Present
          LJWatson, fesch, Brian, AmeliaBR, Rich_Schwerdtfeger

   Regrets
   Chair
          fesch

   Scribe
          Brian

Contents

     * [3]Topics
         1. [4]SVG-AAM
         2. [5]NEWS
         3. [6]Publication Status
         4. [7]Shadow Tree vs Shadow DOM Text
         5. [8]Testing of SVG A11y Spec
     * [9]Summary of Action Items
     * [10]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: Brian

   presnet+ Brian

   <fesch>
   [11]https://lists.w3.org/Archives/Public/public-svg-a11y/2016Au
   g/0007.html

     [11] https://lists.w3.org/Archives/Public/public-svg-a11y/2016Aug/0007.html

SVG-AAM

NEWS

   fesch: any news, or changes to the agenda?

   AmeliaBR: we now have cross-browser support for tabindex.
   ... as of last week update to edge we have support, as of
   Firefox nightly. There is a 6 week cycle for nightly ot stable
   ... Chrome and Webkit already have had tabindex support for a
   while

   fesch: any news from the SVG working group?

   AmeliaBR: We're working on getting SVG2 to candidate rec
   ... all normative changes are locked now.
   ... There is a couple required reviews. The
   internationalization team needs to review. There also needs to
   be an accessibility review.
   ... a request was sent out. Not quite sure the process there,
   but there will need to be a formal sign off that this doesn't
   do anything bad for accessibility. We may be the ones asked to
   confirm

   chaals-ordhord: Leonie will have a good idea of what happens
   next

   LJWatson: My guess is that it will show up on tomorrow's agenda
   (APA)

   shepazu: I think it's worth nothing, for whoever who's on that
   meeting, though we didn't seek explicit accessibiltiy review
   before, we have been working with accessibility people to
   address accessibility needs in advacne
   ... not only do we have tabindex

   LJWatson: Fred and I are usually on the APA call, we'll make
   sure this gets picked up then

   fesch: that'll jsut go through the normal channels. Rich,
   Leonie and I are all on APA. We don't anticipate any problems
   there

   shepazu: During that call, I'd appreciate, Rich as you point
   out, we waited to get the review. But, we didn't wait to get
   the review. We've been working with accessibility folks for
   several years now
   ... trying to resolve problems in advance. This isn't so much a
   review, but a sign off to get to CR
   ... the other one that got snet out, by the way. The
   internationalization, they said they didn't like seeing them
   put off so late, but we didn't change much, and most of the
   changes for language is with CSS

   fesch: what about lang and titles and description

   shepazu: I thouhgt we didn't do those changes

  AmeliaBR: those are still in. The two changes are
   multi-title/desc and switch langauge and allow reorder

   chaals-ordhord: is the multi-lingual title/desc real? Does it
   work anywhere?

   AmeliaBR: No, that's why it's marked at risk

   shepazu: I don't think it'll make it out of CR because we don't
   have implementations of it

   AmeliaBR: I think we need to present it as an accessiibility
   feature

   chaals-ordhord: I hate to say it, but I'd be pretty surprised
   if that worked

   AmeliaBR: there's more work people catching up on accessibility
   ... Microsoft fixed keyboard accessibility, and have been
   waiting for us to stabilize everything else

   fesch: anything else?

Publication Status

   these are good to go. They're in the queue, I think behind dpub

Shadow Tree vs Shadow DOM Text

   AmeliaBR: For SVG2 I added cross-links for the words for WhatWG
   spec for shadow dom
   ... the independent shadow dom spec has stalled, they're
   looking to integrate into the core DOM and not have two specs.
   The changes are in the WHATWG spec. This is a living standard
   ... If you're ok with using that as the definitive reference
   for terms, that seems to be the most up to date place
   ... I haven't pushed the clarifications to the AAM. I need to
   check with Michael if I can push changes, now that he's
   adjusted changes permissions to github
   ... It'll either be apull request from the repo, or a fork of
   the repo. I can let you know the changes I have marked as todo
   are to avoid the use of the term "shadow dom content", use more
   precise language
   ... There's another paragraph I need to clean up, Brad was
   saying it's a little confusing
   ... The main change is being precise in terminology

   fesch: Rich, did you have questions baout shadow dom shadowtree
   based on interactivity concerns

   Rich: I think in the last meeting that the events were the
   same, I don't think we need to differentiate

   AmeliaBR: dealing with IDrefs, due to the nature of the use
   element, and how users don't have control over the stuff inside
   it I don't see it to be an issue. It's more a problem using the
   shadowdom and custom widgets.

   Rich: When you have a click element inside a tree does it flow
   up to the parent element?

   AmeliaBR: It does. If you have a mousein mouseout type event
   where it's going in and out of two parts inside the shadow
   tree, and with the use element you'd be going in and out of the
   same element it stops bubbling.

   fesch: If you actually have a click inside a symbol referenced
   by a use, and you reference document, you're doing this
   programmatically, and your referencing document will it give
   you the parent document or the local document it'll refer you
   to

   AmeliaBR: the document is the sort of containing document. I'd
   need to grab the spec to get all the details. But, yeah,
   there's a whole set of new additions about what's contained to
   the local tree or what's related to the document.

   the shadow tree is related but not a separate document, like an
   iframe is a separate document

   fesch: can you programmatically find those?

   AmeliaBR: yes

   fesch: Would JQuery get confused? Can you find things with it
   inside those shadow trees?

   <AmeliaBR> [12]https://dom.spec.whatwg.org/

     [12] https://dom.spec.whatwg.org/

   AmeliaBR: Not by default, selectors only look inside one tree.
   ... This is not naything specific to SVG and use elements.
   They're part of the DOM standard, which browsers are making
   their implementations match
   ... We're trying to coordinate as much as possible. the
   distinction being use element shadow trees are read-only

   fesch: how would you show focus on them?

   AmeliaBR: styles are still independent. That's one important
   difference
   ... SVG using the shaodw tree model is different for SVG 1.1.
   Things are really messy in browsers in focus and hover styles
   ... The shadow tree model requires these are indepdent elements
   with indepdenent styles. They are mostly identical, but the
   interactive styles only apply to the element you're interacting
   with

   fesch: The gist of it is, there are still changes to be made in
   the SVG-aam spec. But the SVG spec is good?

   AmeliaBR: Yes, the SG2 spec should be good unless people find
   problems with it. SVG-AAM has changes.

   fesch: any other topics? We can talk about post-aria 1.1

   Rich: I can't think of that right now. There's a lot to do
   still

Testing of SVG A11y Spec

   AmeliaBR: you've held up on updating the test suites because of
   the graphics roles. Do we now have mappings for the main APIs?

   Rich: We definitely have those for Mac. We need to review the
   other platforms.
   ... we'll get there. Mac is there.

   <AmeliaBR>
   [13]https://rawgit.com/w3c/aria/master/graphics-aam/graphics-aa
   m.html#mapping_role_table

     [13] https://rawgit.com/w3c/aria/master/graphics-aam/graphics-aam.html#mapping_role_table

   Rich: if you expand all and look at mac. We don't get to call
   it a graphics-document it's just a document. All the
   differentiation we'd asked for is basically gone

   fesch: One question, we have MSAA on the table, should we drop
   this?

   Rich: no, why would be do that?
   ... Iaccessble2 is an extension of MSAA, object attributes are
   IA2. Oh, there's a typo there

   AmeliaBR: as far as the tests, Fred, are your scripts able to
   easily update the testing outcomes based on these mappings?
   ... if these mappings change in the future, update accordingly

   fesch: I need to put these into the wiki. Once they're in the
   wiki, they can convert them into the form
   ... What form that is, is an ongoing issue in the ARIA testing
   subgroup

   <fesch> ack

   fesch: I've tweaked the perl script one time. The other thing
   that's kind of interesting, becasue it's what I heard, we were
   going to try to have automated tests similar to what Joni did
   with the webkit layout tests, so they just sort of run when
   people build.
   ... I'm not seeing this happening, or what the general test
   harness will look like either. Once we know the form, it won't
   be hard to get the tests from the wiki to the proper form
   ... the people that are building the testable statements for
   ARIA 1.1 agreed they'll be using a wiki to test their
   statements as well. It's easier than manually creating JSON.
   The form is unknown, but the testable statements will be
   created in wikis

   <fesch> ack

   AmeliaBR: that covers a lot. Once I finalize the use elements,
   there will need to be updates to the testable statements
   accordingly. Probably some new tests to look at contents inside
   a use element that needs to be exposed

   fesch: I'd suggest everyone look at the wiki. I don't think the
   wiki is specific to a document. If people think we should break
   out stuff that should only apply to the graphics document.
   However we want to handle them that's ok

   <AmeliaBR> Root page for testing wiki:
   [14]https://www.w3.org/wiki/SVG_Accessibility/Testing

     [14] https://www.w3.org/wiki/SVG_Accessibility/Testing

   fesch: the testable statements are broken out to two pages. One
   is title/desc with multilingual support. Every other testable
   statements are on the other one

   <fesch>
   [15]https://www.w3.org/wiki/SVG_Accessibility/Testing/Test_Asse
   rtions_with_Tables

     [15] https://www.w3.org/wiki/SVG_Accessibility/Testing/Test_Assertions_with_Tables

   fesch: We've sort of had an informal review as we've went
   along. Joanie did some review. If you want to look really
   quick, the last row is NOTE. That's Joanie's notes to herself
   about what test she's doing. If you're editing, just don't
   change Joanie's note.

   AmeliaBR: it'll only change with respect to use elements

   fesch: anyone want to go through them and check that they're up
   to date? They're broken into little groups. Testable
   statements, separate ones for role none and presentation

   AmeliaBR: I will try to go through them. My first priority is
   getting these edits done. I will hopefully have more time to
   work on the a11y side now that I'm done with the main SVG spec

   fesch: any changes we can take to the ARIA testing group

   trackbot, make minutes public

   <trackbot> Sorry, Brian, I don't understand 'trackbot, make
   minutes public'. Please refer to
   <[16]http://www.w3.org/2005/06/tracker/irc> for help.

     [16] http://www.w3.org/2005/06/tracker/irc

   RRSAgent: make minutes

Summary of Action Items

Summary of Resolutions

   [End of minutes]

Brian McNeilly
Accessibility Consultant
SSB BART Group
brian.mcneilly@ssbbartgroup.com<mailto:brian.mcneilly@ssbbartgroup.com>
(415) 814-0522 (o)
Visit us online: Website<http://www.ssbbartgroup.com> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>