IRC log of svg on 2015-11-12

Timestamps are in UTC.

20:27:59 [RRSAgent]
RRSAgent has joined #svg
20:27:59 [RRSAgent]
logging to
20:28:01 [trackbot]
RRSAgent, make logs public
20:28:01 [Zakim]
Zakim has joined #svg
20:28:03 [trackbot]
Zakim, this will be GA_SVGWG
20:28:03 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
20:28:04 [trackbot]
Meeting: SVG Working Group Teleconference
20:28:04 [trackbot]
Date: 12 November 2015
20:28:05 [heycam]
Chair: Cameron
20:28:23 [heycam]
20:29:57 [nikos]
present+ nikos
20:30:06 [ed]
present+ ed
20:30:37 [heycam]
present+ heycam
20:31:17 [AmeliaBR]
present+ AmeliaBR
20:31:41 [BogdanBrinza]
BogdanBrinza has joined #svg
20:31:47 [fesch]
20:31:54 [AmeliaBR]
WebEx quick-join URL:
20:34:52 [BogdanBrinza]
20:35:07 [nikos]
scribenick: Nikos
20:35:13 [nikos]
scribe: Nikos
20:35:16 [nikos]
scribenick: nikos
20:35:24 [Tav]
present+ Tav
20:36:06 [nikos]
Topic: Accessibility Task Force documents
20:36:08 [AmeliaBR]
20:36:32 [nikos]
AmeliaBR: There's two docs. One is an updated draft, the ARIA team is hoping to publish that next week
20:36:47 [nikos]
... 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
20:36:58 [AmeliaBR]
20:37:10 [nikos]
... This is the SVG accessibility api mapping spec
20:37:27 [nikos]
... Purpose is to define how browsers should map svg specific features to the OS accessibility api
20:37:36 [nikos]
... that are then used by screen readers, special input devices, etc
20:37:57 [nikos]
... OS accessibility APIs have a standard way of describing everything and they have to work with the content of the web site as well
20:38:09 [nikos]
... there's a core accessibility API mapping guide that defines how the basic ARIA roles should map
20:38:16 [nikos]
... but that doesn't cover the unique features of a given langauge
20:38:33 [nikos]
... so there'll be a HTML mapping guide, covering form elements and other interactive elements
20:38:39 [nikos]
... then there's this guide which talks about SVG features
20:38:54 [nikos]
... Starts with introduction
20:39:22 [nikos]
... talks about how dom tree maps to simplified accessibility tree that the assisted technologies need to work with
20:39:46 [nikos]
... Important terms has a long list of terms that are common to all ARIA specs
20:40:01 [nikos]
... Then there's a section on keyboard navigation that references the new tabindex requirement from SVG 2
20:40:12 [nikos]
... shouldn't be too controversial - just basic tab index navigation
20:40:27 [nikos]
...Then we get into the specifics. I should mention the entire TOC of this document mirrors the TOC of the core mapping doc
20:40:37 [nikos]
... Many of the sections are very short and say follow core spec
20:40:47 [nikos]
... Where we need SVG specific roles they're described
20:40:57 [nikos]
... core spec has rules for how elements in general are exposed in this accessibility API
20:41:01 [nikos]
... and which elements are exposed
20:41:11 [nikos]
... general approach is to keep it as simple as possible
20:41:21 [nikos]
... not give unimportant info to assistive tools
20:41:36 [nikos]
... e.g. hidden content and things that don't have layout information
20:41:56 [nikos]
... 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
20:42:03 [nikos]
... there's also much more complex rules for pointer events
20:42:20 [nikos]
... something can have pointer events even if invisible
20:42:33 [nikos]
... there's about 6 or 8 options for pointer events
20:42:48 [shepazu]
agenda+ new TR stylesheets
20:43:17 [nikos]
... 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
20:43:41 [nikos]
... 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
20:43:51 [nikos]
... other editors note is about how we handle desc element
20:44:06 [nikos]
... svg 1 spec talks about using css to make an alternate presentation of desc
20:44:16 [nikos]
... so you can display html instead of graphcs - but that doesn't work on any ua
20:44:35 [nikos]
... so we allow any html in desc but it's not going to display anywhere
20:44:52 [nikos]
... 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
20:45:02 [nikos]
... we still use the description, but treat it as plain text
20:45:07 [nikos]
... similar to an alt
20:45:19 [nikos]
heycam: is there a reason that can't work?
20:45:54 [nikos]
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
20:46:19 [nikos]
... having complex content that doesn't show up on the screen can be problematic and confusing
20:46:32 [nikos]
... could happen in future, we've talked about it in the TF - that's why we have a note
20:46:47 [nikos]
... was suggested that we could have html structured tooltips instead of plain text
20:46:58 [nikos]
... but the tech isn't there yet, and there isn't a framework for creating it
20:47:26 [nikos]
heycam: if the TF has specific suggestions on what should change in SVG 2, then it would be good to hear them
20:47:50 [nikos]
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
20:47:58 [nikos]
... so might want to add a note to the desc element
20:48:14 [nikos]
... so although it's allowed, it's not exposed currently to assistive tech
20:48:32 [nikos]
... I've had complaints from authors about why it doesn't work
20:49:39 [nikos]
AmeliaBR: There are some issues on aria roles
20:49:46 [nikos]
... part of the second doc is trying to fix this
20:49:54 [nikos]
... First question is what to do with the use element
20:50:00 [nikos]
... right now we're mapping it as an image
20:50:05 [nikos]
... you can't access the internal content
20:50:12 [shepazu]
20:50:16 [nikos]
... the only way we use the source graphic is as a name and description
20:50:30 [nikos]
... so we tell browsers to look at the source graphic and see if it has a title instead
20:50:56 [nikos]
... 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
20:51:05 [nikos]
... so depends where the svg 2 spec goes with use
20:51:40 [nikos]
... svg 1.1 had the element instance tree that could have conceivably be used, but wasn't implemented
20:51:54 [nikos]
... so there's a note, and we're trying to get feedback from users
20:52:05 [nikos]
... but we need a decision from SVG WG about how use elements are handled wrt shadow dom specs
20:52:28 [nikos]
... is there a desire to keep use elements simple and use custom elements for other things?
20:53:19 [nikos]
shepazu: Just want to say that we're requesting approval for updated publication of the AAM spec and publication of the other spec
20:53:34 [nikos]
... so we have two svg accessibility specs and they're joint deliverables wit the SVG and APA WG
20:53:40 [nikos]
... we need approval from both WGs to move them forward
20:54:16 [nikos]
... It's good that Amelia is giving you details on the spec, but we should also open the floor to questions
20:54:39 [nikos]
AmeliaBR: To be clear, these issues, we're planning to publish with them as notes in the document
20:54:56 [nikos]
heycam: that's fine, from what I can see there's not that many issues
20:55:26 [nikos]
shepazu: There is obviously a need for ongoing co-ordination between SVG and accessibility TF about the issues
20:55:39 [nikos]
... but I don't think these are show stoppers, think we could sort them out in the course of the next publication
20:55:53 [nikos]
... but it is something the svg wg will ultimately have to be responsible for and accept
20:56:08 [nikos]
heycam: So does anyone have any questions about publication of this first document?
20:56:38 [nikos]
... And is everyone in favour of publishing?
20:56:51 [nikos]
nikos: yes
20:56:53 [nikos]
shepazu: +1
20:57:04 [ed]
20:57:36 [AmeliaBR]
RESOLUTION: SVG WG endorses publication of a new working draft of the SVG Accessibility API Mappings specification.
20:57:59 [nikos]
AmeliaBR: We'll try to publish that next week - so be quick if you have questions or concerns
20:58:12 [nikos]
... but it is just an updated WD which we'll continue working on over the next few months
20:58:18 [nikos]
Topic: ARIA Graphics module
20:58:22 [AmeliaBR]
20:58:39 [nikos]
AmeliaBR: one of the issues we came up with in the mapping guide is there's very few roles for graphics
20:58:44 [stakagi]
stakagi has joined #svg
20:58:55 [nikos]
... image was defined so that all child dom nodes would be ignored
20:59:18 [nikos]
... 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
20:59:25 [nikos]
... so we need a more nuanced approach to graphics
20:59:38 [nikos]
... Long term goal is to create an ARIA model for describing charts and graphs
20:59:49 [nikos]
... where assistive tech can add extra understanding
20:59:53 [nikos]
... we're not there yet
21:00:05 [nikos]
... this is a basic set of roles for describing structured graphics
21:00:15 [nikos]
... where components have titles and description
21:00:25 [AmeliaBR]
21:00:35 [nikos]
... That section defines the new roles
21:00:48 [nikos]
... Graphics document is the default role for the svg element
21:01:24 [nikos]
... Difference from exiting image is that graphics-doc has meaningful child content
21:01:25 [shepazu]
21:01:52 [nikos]
heycam: What would be the difference between the experience if you have inline SVG that does have graphics-doc and one that doesn't?
21:02:27 [nikos]
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
21:02:46 [nikos]
... they wouldn't see a lot - in future, new tools might allow arrow key navigation instead of dom order navigation
21:02:59 [nikos]
... or other things, if you have a braille doc it could be aware you're dealing with graphics content
21:03:15 [nikos]
heycam: so it's an indication that there's 2d presented information that isn't some hierarchically ordered document?
21:03:31 [nikos]
AmeliaBR: the assumption is with a plain text doc that there's a single reading order
21:03:35 [nikos]
... with graphics that doesn't always work
21:03:49 [nikos]
... so the new role is a signal to tech that they can apply different heuristics
21:03:55 [nikos]
... based on 2d layout
21:04:04 [nikos]
... we're not defining what they would be yet, just enabling that
21:04:58 [nikos]
shepazu: So what we're defining is a framework for future work
21:05:29 [nikos]
... want to allow accessible visualisations and allow screen readers to explore them in novel ways
21:05:42 [nikos]
AmeliaBR: there'll either be separate domain specific specs or a level 2 of this document
21:05:54 [nikos]
heycam: so we have the graphics-doc role that says the whole document is an explorable graphic
21:06:17 [nikos]
AmeliaBR: graphics-doc is an alternative to group
21:07:07 [nikos]
s/graphics-doc is an alternative/graphics-object is an alternative
21:07:24 [nikos]
... it's adding semantics so distinctions between groups in a document can be described
21:07:30 [nikos]
... final role is graphics-symbol
21:08:02 [nikos]
... for things that are conceptually a categorical item - e.g. data points on scatter plot or astrological male and female symbols
21:08:11 [nikos]
... you don't want to delve inside these objects
21:08:21 [nikos]
... this is the role we will propose as the default role for basic shapes in SVG
21:09:43 [nikos]
... 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.
21:11:36 [nikos]
ed: anyone opposed to publishing this document?
21:11:45 [nikos]
BogdanBrinza: no
21:12:08 [nikos]
RESOLUTION: SVG WG approves publication of WAI-ARIA Graphics Module draft
21:12:35 [nikos]
AmeliaBR: if any of you have time to have a look at these specs, and especially the editor's note
21:12:44 [nikos]
... we are looking for examples of use
21:13:41 [nikos]
Topic: new TR stylesheets
21:13:42 [nikos]
21:13:56 [nikos]
shepazu: You can see an example
21:14:25 [nikos]
... in 2016, all published specs will need to use these style sheets
21:14:34 [nikos]
... so we need to make sure our specs will work with this style
21:14:43 [shepazu]
21:15:16 [nikos]
... 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
21:15:39 [nikos]
But starting in Jan we'll be publishing with these styles, so we might need to do some changes to the spec generation scripts
21:16:41 [nikos]
... This is almost all CSS - there's very little change to the markup
21:17:02 [nikos]
... we haven't updated our style for 15 years. Future revisions may include script libraries and other things to improve it
21:17:16 [nikos]
... but for the moment, it's almost all just style sheet changes
21:17:35 [nikos]
AmeliaBR: Have you tried to put the style sheet on our current specs?
21:17:43 [nikos]
shepazu: not yet, but we should
21:17:47 [nikos]
AmeliaBR: maybe a branch on github
21:17:57 [nikos]
Tav: annotations aren't included in this
21:18:08 [nikos]
shepazu: Still working on that
21:18:55 [nikos]
shepazu: One of the points of this is that we want to start encouraging a common style for all W3C specs
21:19:24 [nikos]
... We'll try to find the best practices and apply them to all specs
21:19:30 [nikos]
... each group may still need variations of course
21:23:51 [nikos]
RRSAgent, make minutes
21:23:51 [RRSAgent]
I have made the request to generate nikos
21:24:21 [ed]
we'll have a spec editing session next week, and due to thanksgiving the telcon after that will be cancelled
23:24:16 [jdaggett]
jdaggett has joined #svg