Minutes, 12 November 2015 SVG WG telcon

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Minutes, 12 November 2015 SVG WG telcon

Nikos Andronikos
The minutes from today’s telcon are at:

http://www.w3.org/2015/11/12-svg-minutes.html

and as text below.


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

SVG Working Group Teleconference
12 Nov 2015

   [2]Agenda

      [2] https://lists.w3.org/Archives/Public/www-svg/2015Nov/0023.html

   See also: [3]IRC log

      [3] http://www.w3.org/2015/11/12-svg-irc

Attendees

   Present
          nikos, ed, heycam, AmeliaBR, fesch, BogdanBrinza, Tav

   Regrets
   Chair
          Cameron

   Scribe
          Nikos

Contents

     * [4]Topics
         1. [5]Accessibility Task Force documents
         2. [6]ARIA Graphics module
         3. [7]new TR stylesheets
     * [8]Summary of Action Items
     __________________________________________________________


Accessibility Task Force documents

   <AmeliaBR>
   [10]https://lists.w3.org/Archives/Public/www-svg/2015Nov/0022.h
   tml

     [10] https://lists.w3.org/Archives/Public/www-svg/2015Nov/0022.html

   AmeliaBR: There's two docs. One is an updated draft, the ARIA
   team is hoping to publish that next week
   ... other is first pass wd - won't be published for a few weeks
   but if we can sign off on it that would be good

   <AmeliaBR>
   [11]https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

     [11] https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

   AmeliaBR: This is the SVG accessibility api mapping spec
   ... Purpose is to define how browsers should map svg specific
   features to the OS accessibility api
   ... that are then used by screen readers, special input
   devices, etc
   ... OS accessibility APIs have a standard way of describing
   everything and they have to work with the content of the web
   site as well
   ... there's a core accessibility API mapping guide that defines
   how the basic ARIA roles should map
   ... but that doesn't cover the unique features of a given
   langauge
   ... so there'll be a HTML mapping guide, covering form elements
   and other interactive elements
   ... then there's this guide which talks about SVG features
   ... Starts with introduction
   ... talks about how dom tree maps to simplified accessibility
   tree that the assisted technologies need to work with
   ... Important terms has a long list of terms that are common to
   all ARIA specs
   ... Then there's a section on keyboard navigation that
   references the new tabindex requirement from SVG 2
   ... shouldn't be too controversial - just basic tab index
   navigation
   ... Then we get into the specifics. I should mention the entire
   TOC of this document mirrors the TOC of the core mapping doc
   ... Many of the sections are very short and say follow core
   spec
   ... Where we need SVG specific roles they're described
   ... core spec has rules for how elements in general are exposed
   in this accessibility API
   ... and which elements are exposed
   ... general approach is to keep it as simple as possible
   ... not give unimportant info to assistive tools
   ... e.g. hidden content and things that don't have layout
   information
   ... that's where things get trick y with svg because we have a
   lot of content that isn't rendered directly on screen -
   filters, gradients, etc
   ... there's also much more complex rules for pointer events
   ... something can have pointer events even if invisible
   ... there's about 6 or 8 options for pointer events
   ... so we need some svg specific rules that say even if this
   element does not cause any pixels to change, if it reacts to
   pointer events then it is still perceivable to a user of a
   mouse who can see the end result of clicking, therefore it
   should be accessible to users of assisted tech
   ... there's a note explaining that, we need to do some work
   with the core group on making sure the defs in the core are
   general enough to account for these svg specifics
   ... other editors note is about how we handle desc element
   ... svg 1 spec talks about using css to make an alternate
   presentation of desc
   ... so you can display html instead of graphcs - but that
   doesn't work on any ua
   ... so we allow any html in desc but it's not going to display
   anywhere
   ... this is tricky because if something isn't drawn on the
   screen there's no way for someone to browse to it and read it
   in a structured way
   ... we still use the description, but treat it as plain text
   ... similar to an alt

   heycam: is there a reason that can't work?

   AmeliaBR: there are practical reasons in that it doesn't work
   now, there's also the more intentional reason that we don't
   want to encourage a screen reader experience that is
   disconnected from the visual experience
   ... having complex content that doesn't show up on the screen
   can be problematic and confusing
   ... could happen in future, we've talked about it in the TF -
   that's why we have a note
   ... was suggested that we could have html structured tooltips
   instead of plain text
   ... but the tech isn't there yet, and there isn't a framework
   for creating it

   heycam: if the TF has specific suggestions on what should
   change in SVG 2, then it would be good to hear them

   AmeliaBR: right now we want to make sure the text in the SVG 2
   spec doesn't imply to authors that they can do things that
   won't have any effect
   ... so might want to add a note to the desc element
   ... so although it's allowed, it's not exposed currently to
   assistive tech
   ... I've had complaints from authors about why it doesn't work
   ... There are some issues on aria roles
   ... part of the second doc is trying to fix this
   ... First question is what to do with the use element
   ... right now we're mapping it as an image
   ... you can't access the internal content
   ... the only way we use the source graphic is as a name and
   description
   ... so we tell browsers to look at the source graphic and see
   if it has a title instead
   ... problem with that is if we end up in SVG 2 moving to a
   shadow dom based thing, where the contents of teh use element
   are a complete dom tree that scripts can interact with, then
   that needs to be reflected in the accessibility tree
   ... so depends where the svg 2 spec goes with use
   ... svg 1.1 had the element instance tree that could have
   conceivably be used, but wasn't implemented
   ... so there's a note, and we're trying to get feedback from
   users
   ... but we need a decision from SVG WG about how use elements
   are handled wrt shadow dom specs
   ... is there a desire to keep use elements simple and use
   custom elements for other things?

   shepazu: Just want to say that we're requesting approval for
   updated publication of the AAM spec and publication of the
   other spec
   ... so we have two svg accessibility specs and they're joint
   deliverables wit the SVG and APA WG
   ... we need approval from both WGs to move them forward
   ... It's good that Amelia is giving you details on the spec,
   but we should also open the floor to questions

   AmeliaBR: To be clear, these issues, we're planning to publish
   with them as notes in the document

   heycam: that's fine, from what I can see there's not that many
   issues

   shepazu: There is obviously a need for ongoing co-ordination
   between SVG and accessibility TF about the issues
   ... but I don't think these are show stoppers, think we could
   sort them out in the course of the next publication
   ... but it is something the svg wg will ultimately have to be
   responsible for and accept

   heycam: So does anyone have any questions about publication of
   this first document?
   ... And is everyone in favour of publishing?

   nikos: yes

   shepazu: +1

   <ed> +1

   <AmeliaBR> RESOLUTION: SVG WG endorses publication of a new
   working draft of the SVG Accessibility API Mappings
   specification.

   AmeliaBR: We'll try to publish that next week - so be quick if
   you have questions or concerns
   ... but it is just an updated WD which we'll continue working
   on over the next few months

ARIA Graphics module

   <AmeliaBR>
   [12]http://rawgit.com/w3c/aria/master/aria/graphics.html

     [12] http://rawgit.com/w3c/aria/master/aria/graphics.html

   AmeliaBR: one of the issues we came up with in the mapping
   guide is there's very few roles for graphics
   ... image was defined so that all child dom nodes would be
   ignored
   ... that's not useful for SVG where you want people to explore
   the sub components that might have their own titles and
   descriptions and event handlers
   ... so we need a more nuanced approach to graphics
   ... Long term goal is to create an ARIA model for describing
   charts and graphs
   ... where assistive tech can add extra understanding
   ... we're not there yet
   ... this is a basic set of roles for describing structured
   graphics
   ... where components have titles and description

   <AmeliaBR>
   [13]http://rawgit.com/w3c/aria/master/aria/graphics.html#roles

     [13] http://rawgit.com/w3c/aria/master/aria/graphics.html#roles

   AmeliaBR: That section defines the new roles
   ... Graphics document is the default role for the svg element
   ... Difference from exiting image is that graphics-doc has
   meaningful child content

   heycam: What would be the difference between the experience if
   you have inline SVG that does have graphics-doc and one that
   doesn't?

   AmeliaBR: Assuming the alternative is what browsers currently
   do - they map to a grouping role or an existing graphics role
   that doesn't have an ARIA equivalent
   ... they wouldn't see a lot - in future, new tools might allow
   arrow key navigation instead of dom order navigation
   ... or other things, if you have a braille doc it could be
   aware you're dealing with graphics content

   heycam: so it's an indication that there's 2d presented
   information that isn't some hierarchically ordered document?

   AmeliaBR: the assumption is with a plain text doc that there's
   a single reading order
   ... with graphics that doesn't always work
   ... so the new role is a signal to tech that they can apply
   different heuristics
   ... based on 2d layout
   ... we're not defining what they would be yet, just enabling
   that

   shepazu: So what we're defining is a framework for future work
   ... want to allow accessible visualisations and allow screen
   readers to explore them in novel ways

   AmeliaBR: there'll either be separate domain specific specs or
   a level 2 of this document

   heycam: so we have the graphics-doc role that says the whole
   document is an explorable graphic

   AmeliaBR: graphics-object is an alternative to group
   ... it's adding semantics so distinctions between groups in a
   document can be described
   ... final role is graphics-symbol
   ... for things that are conceptually a categorical item - e.g.
   data points on scatter plot or astrological male and female
   symbols
   ... you don't want to delve inside these objects
   ... this is the role we will propose as the default role for
   basic shapes in SVG
   ... The idea is that these roles will become default roles for
   SVG. We haven't updated to the other spec to refer to this one
   yet as we won't be publishing this one until December. But
   there's notes currently.

   ed: anyone opposed to publishing this document?

   BogdanBrinza: no

   RESOLUTION: SVG WG approves publication of WAI-ARIA Graphics
   Module draft

   AmeliaBR: if any of you have time to have a look at these
   specs, and especially the editor's note
   ... we are looking for examples of use

new TR stylesheets

   [14]https://lists.w3.org/Archives/Public/spec-prod/2015OctDec/0
   009.html

     [14] https://lists.w3.org/Archives/Public/spec-prod/2015OctDec/0009.html

   shepazu: You can see an example
   ... in 2016, all published specs will need to use these style
   sheets
   ... so we need to make sure our specs will work with this style

   <shepazu>
   [15]http://fantasai.inkedblade.net/style/design/w3c-restyle/201
   6/sample

     [15] http://fantasai.inkedblade.net/style/design/w3c-restyle/2016/sample

   shepazu: Have seen some problems when there's a large table or
   if there's a large image. Because the spec space is now
   narrower, that can be a problem

   But starting in Jan we'll be publishing with these styles, so
   we might need to do some changes to the spec generation scripts

   scribe: This is almost all CSS - there's very little change to
   the markup
   ... we haven't updated our style for 15 years. Future revisions
   may include script libraries and other things to improve it
   ... but for the moment, it's almost all just style sheet
   changes

   AmeliaBR: Have you tried to put the style sheet on our current
   specs?

   shepazu: not yet, but we should

   AmeliaBR: maybe a branch on github

   Tav: annotations aren't included in this

   shepazu: Still working on that
   ... One of the points of this is that we want to start
   encouraging a common style for all W3C specs
   ... We'll try to find the best practices and apply them to all
   specs
   ... each group may still need variations of course

Summary of Action Items

   [End of minutes]

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.