20:30:11 <RRSAgent> RRSAgent has joined #svg
20:30:11 <RRSAgent> logging to http://www.w3.org/2015/05/21-svg-irc
20:30:13 <trackbot> RRSAgent, make logs public
20:30:13 <Zakim> Zakim has joined #svg
20:30:15 <trackbot> Zakim, this will be GA_SVGWG
20:30:15 <Zakim> ok, trackbot; I see GA_SVGWG()4:30PM scheduled to start now
20:30:16 <trackbot> Meeting: SVG Working Group Teleconference
20:30:16 <trackbot> Date: 21 May 2015
20:30:37 <Zakim> GA_SVGWG()4:30PM has now started
20:30:44 <Zakim> +Thomas_Smailus
20:32:29 <Zakim> +[IPcaller]
20:32:31 <heycam> Zakim, [ is me
20:32:31 <Zakim> +heycam; got it
20:32:46 <heycam> Chair: Cameron
20:32:52 <heycam> Agenda: https://lists.w3.org/Archives/Public/www-svg/2015May/0025.html
20:33:00 <heycam> Regrets: Erik
20:33:05 <heycam> Zakim, who is on the call?
20:33:05 <Zakim> On the phone I see Thomas_Smailus, heycam
20:34:35 <ChrisLittle> I  will lurk - no phone. Sorry.
20:34:42 <heycam> ChrisLittle, no problem
20:34:59 <Zakim> +??P3
20:35:03 <heycam> Present+ ChrisLittle
20:35:04 <Zakim> +??P2
20:35:13 <Tav> Zakim, ??P3 is me
20:35:13 <Zakim> +Tav; got it
20:35:27 <stakagi> zakim, ??P2 is me
20:35:27 <Zakim> +stakagi; got it
20:35:58 <Zakim> +??P4
20:36:26 <nikos_> nikos_ has joined #svg
20:37:04 <heycam> Zakim, mute ??P4
20:37:04 <Zakim> ??P4 should now be muted
20:37:15 <Zakim> +[Microsoft]
20:37:26 <Zakim> -??P4
20:37:30 <BogdanBrinza> BogdanBrinza has joined #svg
20:37:41 <Zakim> +??P4
20:37:57 <nikos_> Zakim, ??P4 is me
20:37:57 <Zakim> +nikos_; got it
20:40:02 <heycam> richardschwerdtfeger, Zakim
20:40:23 <nikos_> Scribe: Nikos
20:40:29 <nikos_> Scribenick: nikos_
20:40:35 <Zakim> +Rich_Schwerdtfeger
20:41:05 <nikos_> Topic: SVG 2 accessibility appendix update
20:41:06 <Zakim> +??P7
20:41:20 <AmeliaBR> zakim, ??P7 is me
20:41:20 <Zakim> +AmeliaBR; got it
20:41:23 <nikos_> richardschwerdtfeger: until we add some additiona specs - e.g. taxonomy for graphics
20:41:35 <AmeliaBR> https://www.w3.org/wiki/SVG_Accessibility
20:41:36 <richardschwerdtfeger> https://www.w3.org/wiki/SVG_Accessibility
20:41:59 <nikos_> richardschwerdtfeger: in addition to api mappings, we're looking at navigation models and the semantics
20:42:11 <nikos_> ... so potentially we can have a new taxonomy to be referenced in the appendix
20:42:25 <nikos_> ... still flushing out the navigation model (stuff other than tab index)
20:42:31 <nikos_> ... not sure if it will make it in time for svg 2
20:42:51 <nikos_> ... one of the things that was asked was the parts of wikag(?) that apply to the lengths we refer to in the appendix
20:42:55 <nikos_> ... I haven't had time to do that yet
20:43:13 <nikos_> heycam: have you touched the currrent appendix?
20:43:16 <AmeliaBR> s/wikag(?)/WCAG/
20:43:17 <nikos_> richardschwerdtfeger: yes
20:43:34 <nikos_> ... we wanted to highlight the new features in SVG 2
20:43:50 <AmeliaBR> https://svgwg.org/svg2-draft/access.html
20:44:00 <nikos_> ... looking at this
20:44:27 <nikos_> ... we have new features - list all the places that have keyboard support - tabindex, keyboard handlers, scripting extensions for setting focus, determining active element
20:44:39 <nikos_> ... second thing, ARIA support and text alternatives
20:44:55 <nikos_> ... how they fit in terms of native language semantics
20:45:01 <nikos_> ... don't think I removed the animation stuff from the spec
20:45:14 <nikos_> ... we also talk about information in desc and title
20:45:17 <richardschwerdtfeger> https://svgwg.org/svg2-draft/access.html
20:45:22 <nikos_> ... and how aria-label and labelby work
20:45:37 <nikos_> ... finally, we link to specs that have direct applicability to vector graphics
20:46:02 <nikos_> ... all those documents combined state how svg documents are mapped to accessibility service layers on the major platforms
20:46:09 <nikos_> ... refer to aria 1.1 and wcag 2.0
20:46:19 <nikos_> ... much more comprehensive and svg specific than the old document
20:46:30 <nikos_> heycam: yeah looks a lot better - old appendix was all wishy washy
20:46:51 <nikos_> richardschwerdtfeger: the TF has been talking about authoring practices - depending on timing we may be able to include that
20:47:03 <nikos_> ... I think it's very strong - don't know if even html spec has this much clarification
20:47:47 <nikos_> heycam: further edits would be referencing other specs and explaining how they work
20:48:01 <nikos_> richardschwerdtfeger: e.g. keyboard suport - would be nice but not sur ewhen it'll be ready
20:48:31 <nikos_> richardschwerdtfeger: have a question regarding text elements - something new to aria 1.1 - we say that this image is text and we can apply the text like an aria label to it
20:48:37 <nikos_> ... so is that something you would want to do in svg?
20:48:38 <Smailus> Smailus has joined #svg
20:48:47 <nikos_> ... e.g. this sequence of path drawing calls would produce text
20:48:54 <nikos_> ... and put role=text and an aria label
20:48:58 <nikos_> ... is that something you would want to do ?
20:49:13 <nikos_> AmeliaBR: you would always be able to say role=text and aria label and it would be accessible for screen readers
20:49:23 <nikos_> ... the question is, should we make it accessible to other user agents in that way
20:49:32 <nikos_> ... so if you did ctrl-s on your webpage it would find it as text
20:49:43 <nikos_> ... or you copied and selected, it would copy and select with plain text included
20:49:47 <nikos_> ... this is something new
20:50:33 <nikos_> ... aria was very careful not to prescribe behaviour for browsers other than accessibility tools. So this would be something new.
20:50:49 <nikos_> ... giving that role attribute more power than it has for aria alone
20:50:54 <nikos_> heycam: this would be for more than just svg?
20:51:09 <nikos_> richardschwerdtfeger: could apply to html as well, but we thought it was powerful for svg
20:51:36 <nikos_> heycam: have you asked the html folks about the idea?
20:52:01 <nikos_> richardschwerdtfeger: no - we were just going through this with the TF and we said this capability in aria 1.1 could be leveraged in svg
20:52:04 <nikos_> ... so it's a new idea
20:52:12 <nikos_> ... but this is up to the host language - not aria
20:52:36 <nikos_> AmeliaBR: svg can be a testing ground for this
20:53:04 <nikos_> ... could it be more than just role=text. e.g. widget roles like buttons, sliders, etc
20:53:18 <nikos_> ... they could be mapped to keyboard roles automatically
20:53:41 <nikos_> ... right now to create accessibility interactive components in svg you need to write all the keyboard handlers yourself
20:53:47 <nikos_> ... it's a big limitation on people making svg accessible
20:54:10 <nikos_> heycam: in terms of level of difficulty of making it accessible - you have to write the keyboard handlers to have the normal behaviour anywa
20:54:21 <nikos_> ... I think of it as an integral part of the component
20:54:36 <nikos_> ... I'd be a bit worried if the browser was adding default keyboard handlers that might not be appropriate for the way the widget is presented
20:55:06 <nikos_> ... you might be using svg to realise some fancy design and the defaults wouldn't be appropriate.
20:55:21 <nikos_> AmeliaBR: there are aria attributes to customise behaviour like that
20:55:27 <nikos_> ... but at this point we don't have a detailed proposal
20:55:37 <nikos_> ... so just bringing the idea to the group to see whta interest there is
20:55:51 <nikos_> Tav: getting back to text - we talked about something like this when we discussed getting rid of svg fonts
20:56:05 <nikos_> ... so I think it's a good idea
20:56:15 <nikos_> heycam: I agree we should have something that allows you to mark up the graphics as text
20:56:20 <nikos_> ... so you can do seraching and whatever
20:56:30 <nikos_> ... might need to think about it some more to decide if role=text is the best way to do that
20:56:42 <nikos_> ... i'm a bit wary of attaching additional behaviour to the aria attributes
20:56:57 <nikos_> ... had a discussion a few years ago about making tooltips appear in response to aria roles - had the same wariness then
20:57:11 <nikos_> ... not sure if fundamentally it's a bad idea - or it just has'nt been done yet
20:57:16 <nikos_> ... so I don't have a strong feeling yet
20:57:25 <nikos_> richardschwerdtfeger: one of the places we'll see this show up is in digital books
20:57:34 <nikos_> ... we have an aria module that reflects digital publishing semantics
20:57:40 <nikos_> ... will be used in CMS
20:57:51 <nikos_> ... specifying browser functionality like - goto glossary
20:58:10 <nikos_> ... so it's starting to happen, but the aria working group wouldn't be the group to define that though
20:58:26 <nikos_> ... so the question is - do we want to work on the proposal - does the group want that?
20:58:56 <nikos_> heycam: I think there are some details to think about - like what happens in terms of highlighting the graphical element
20:59:04 <nikos_> ... that's the main one I'm thinking of
20:59:17 <nikos_> ... not an unsolvable problem
20:59:32 <nikos_> ... but my personal opinion is that I'm not against it - might be easier to evaluate with a proposal
20:59:45 <nikos_> ... in terms of that functionality of declaring some graphics as having text attached
20:59:49 <nikos_> ... that's a feature we want some how
20:59:55 <nikos_> AmeliaBR: we can look at other options as well
21:00:03 <nikos_> ... perhaps create a native svg way of doing the same thing
21:00:36 <nikos_> ... like here's some text - don't render, render this graphical object itself
21:00:50 <nikos_> heycam: that's what I was thinking - divide graphical object into vertical slices to represent each character
21:01:09 <nikos_> AmeliaBR: if you can come up with some solutions to that use case and see if role=text or some other method would be better, then that would be great
21:01:28 <nikos_> s/AmeliaBR: if you can come/heycam: if you can come
21:01:33 <nikos_> AmeliaBR: we'll get back to you
21:01:38 <nikos_> richardschwerdtfeger: what's the timeframe for svg 2?
21:01:51 <nikos_> heycam: we've made good progress closing issues - should get remaining ones discussed at the f2f
21:02:14 <nikos_> ... so I would say we are aiming for the end of the year or tpac for moving to the next publication stage (CR?)
21:02:25 <nikos_> richardschwerdtfeger: not sure how we would get a new navigation model in that time
21:02:32 <nikos_> ... but it would be nice to have some sort of taxonomy at least by then
21:02:36 <nikos_> ... we'll discuss in the group
21:02:47 <nikos_> heycam: there's always the time afterwards in terms of the test suite
21:02:56 <nikos_> ... so the spec won't be in CR for a short amount of time
21:03:09 <nikos_> richardschwerdtfeger: are you doing the workflow with multiple CRs?
21:03:13 <nikos_> heycam: depends on the issues raised
21:03:27 <nikos_> Topic: transform on root <svg>
21:03:43 <nikos_> https://lists.w3.org/Archives/Public/www-svg/2015May/0024.html
21:03:57 <nikos_> AmeliaBR: we have a couple of questions with respect to how transformations on the root element
21:04:08 <nikos_> ... in svg 1 you couldn't put a transform attribut eon an svg element
21:04:19 <nikos_> ... could do it indirectly with url fragments but not well defined and browsers are inconsistent
21:04:30 <nikos_> ... css allows transformatoins on everything
21:04:42 <nikos_> ... and gives guidance for a general root element case
21:04:54 <nikos_> ... but 2 thing specific to svg - viewbox is a transformation, which comes first
21:05:14 <nikos_> ... the way everyone has implemented it  for inline svg - the transformation attribut egets applied in the parent co-ordinate system, then the viewbox is applied for the children
21:05:21 <nikos_> ... so assuming that will be adopted for svg root elements
21:05:26 <nikos_> ... but transform-origin
21:05:32 <nikos_> ... the css specs have waffly language
21:05:59 <nikos_> ... to make up for the fact that svg elements hav etheir default transform-origin on the local co-ordinate system
21:06:14 <nikos_> ... but css offsets the center of the box
21:06:28 <nikos_> ... I've tested browsers and the results are inconsistent - so we need clear guidance
21:06:41 <nikos_> ... I agree with cam's comment that we need more explicit language in css transforms
21:06:52 <nikos_> ... right now it just says default is 50%,50%... etc
21:07:19 <nikos_> ... Cameron suggested to rewrite that as the default style rule for elements in the svg namespace
21:07:37 <nikos_> heycam: I think that's the most practical - I cc'd to the fx list so hopefully Dirk saw
21:07:53 <nikos_> AmeliaBR: the question is - are we going to rewrite that rule so that it applies to svg that is a root element"?
21:08:15 <nikos_> ... i pointed out that because we are allowing backgrounds and borders and padding that essentially becomes a css layout box
21:08:20 <nikos_> ... and should be treated the same
21:08:32 <nikos_> ... though it's more useful to rotate an entire image from the middle
21:08:48 <nikos_> heycam: I think it's consistent with root of html elements having 50%,50%
21:08:59 <nikos_> ... and svg child of FO being 50% as well
21:09:25 <nikos_> AmeliaBR: the other places where it would be a good consistency is when you have a transformation on a root svg and you use that svg inside an image you would have similar behaviour to inline svg
21:09:42 <nikos_> ... so I think we're agreed there - so next step is to approach css transforms about rewriting that wishy washy statement
21:09:53 <nikos_> ... as a specific default user agent style rule
21:10:20 <nikos_> ACTION: heycam to contact css working group regarding default style rule for transform on root element
21:10:20 <trackbot> Created ACTION-3792 - Contact css working group regarding default style rule for transform on root element [on Cameron McCormack - due 2015-05-28].
21:10:51 <nikos_> AmeliaBR: the other question is how the svg view fragment interacts with the transformation on the root element
21:11:07 <nikos_> ... all the other svg view parameters replace the attribute on the svg root element
21:11:16 <nikos_> ... so there has been some voice on the mailing list if it had similar behaviour
21:11:23 <nikos_> ... but its complex because you have to deal with css cascade
21:11:35 <nikos_> ... so when we discussed previously we said it would apply as an additional transformation
21:11:55 <nikos_> ... you take the svg as it is defined in a file and you put it inside group that has the transformation from the view
21:12:06 <nikos_> heycam: I had forgotten that the other view fragment thing replaces the attribut evalues on the root element
21:12:18 <nikos_> ... so it's a bit unfortunate to have transform work differently
21:12:40 <nikos_> ... but I think it's more useful to have transform on the outside rathe rthan have the author work out what transform the yneed to use in the middle of the transform stack
21:13:01 <nikos_> AmeliaBR: it's also very messy because of css cascade issue - if we do anything other than on top we are going to have to talk to css
21:13:10 <nikos_> ... we are saying a url value replaces a style sheet value
21:13:19 <nikos_> ... and nothing in the css cascade deals with that
21:13:24 <Smailus> Gotta drop of.
21:13:27 <Zakim> -Thomas_Smailus
21:13:30 <nikos_> heycam: could probably deal with it by saying it replaces the value given by the presentation attribute
21:13:49 <nikos_> AmeliaBR: then it would be confusing for authors if it overwrote presentation attributes but not styles
21:14:02 <nikos_> ... in this case you may be embedding an image - not looking inside the svg code
21:14:22 <nikos_> ... if the decision is to go with the idea that it's an addtional transformation on top, I will look at getting the exact text in
21:14:28 <nikos_> ... already have a relevant action
21:15:28 <nikos_> heycam: sounds like it's good enough to move forward then
21:16:12 <nikos_> RESOLUTION: the default value of transform-origin on a root svg element is a default of 50%,50%
21:16:41 <nikos_> RESOLUTION: the view fragment transform is applied outside all of the other transforms that apply to the root element
21:17:02 <nikos_> heycam: I did bring u pa small question in my email - what do we do with foreignobject?
21:17:07 <nikos_> ... e.g. the element itself
21:17:22 <nikos_> AmeliaBR: I think the FO lement itself should be treated as an svg element
21:17:36 <nikos_> ... you always have html elements inside it which would be transformed according to the html rules
21:17:46 <nikos_> ... but the FO itself - I think you can currently transform with a transform attribute
21:17:54 <nikos_> ... so we need to keep the current svg rules
21:18:04 <nikos_> heycam: I was a little confused because we said 'svg element
21:18:22 <nikos_> AmeliaBR: all the mor ereason to get that language replaced by something more precise
21:18:36 <nikos_> heycam: anything else to discuss?
21:18:43 <nikos_> AmeliaBR: think that covers all my points
21:19:23 <nikos_> heycam: don't forget we're switching to webex next week
21:19:28 <Zakim> -Rich_Schwerdtfeger
21:19:29 <Zakim> -Tav
21:19:29 <Zakim> -heycam
21:19:31 <nikos_> RRSAgent, make minutes
21:19:31 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/21-svg-minutes.html nikos_
21:19:31 <Zakim> -stakagi
21:19:34 <Zakim> -[Microsoft]
21:19:45 <nikos_> RRSAgent, make minutes public
21:19:45 <RRSAgent> I'm logging. I don't understand 'make minutes public', nikos_.  Try /msg RRSAgent help
21:19:49 <Zakim> -AmeliaBR
21:19:51 <nikos_> how do you make them public again?
21:20:25 <AmeliaBR> RRSAgeng, make log public
21:20:33 <AmeliaBR> RRSAgent, make log public
21:20:42 <nikos_> ahh make log public
21:21:12 <nikos_> didn't make minutes public use to work?
21:21:21 <AmeliaBR> You're not allowed to make public minutes of a private log, I guess?
21:21:40 <nikos_> would be a convenient shorthand though =0
21:21:57 <nikos_> heycam: clever!
21:22:11 <nikos_> delegating is good
21:22:24 <heycam> then it will also list out the Present line, too
21:22:30 <AmeliaBR> Make the robots work for you...
21:22:43 <AmeliaBR> trackbot, end telcon
21:22:43 <trackbot> Zakim, list attendees
21:22:43 <Zakim> As of this point the attendees have been Thomas_Smailus, [IPcaller], heycam, Tav, stakagi, [Microsoft], nikos_, Rich_Schwerdtfeger, AmeliaBR
21:22:51 <trackbot> RRSAgent, please draft minutes
21:22:51 <RRSAgent> I have made the request to generate http://www.w3.org/2015/05/21-svg-minutes.html trackbot
21:22:52 <trackbot> RRSAgent, bye
21:22:52 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2015/05/21-svg-actions.rdf :
21:22:52 <RRSAgent> ACTION: heycam to contact css working group regarding default style rule for transform on root element [1]
21:22:52 <RRSAgent>   recorded in http://www.w3.org/2015/05/21-svg-irc#T21-10-20