SVG Working Group Teleconference -- 21 May 2015

<trackbot> Date: 21 May 2015

<ChrisLittle> I will lurk - no phone. Sorry.

<heycam> ChrisLittle, no problem

<heycam> richardschwerdtfeger, Zakim

<scribe> Scribe: Nikos

<scribe> Scribenick: nikos_

SVG 2 accessibility appendix update

richardschwerdtfeger: until we add some additiona specs - e.g. taxonomy for graphics

<AmeliaBR> https://www.w3.org/wiki/SVG_Accessibility

<richardschwerdtfeger> https://www.w3.org/wiki/SVG_Accessibility

richardschwerdtfeger: in addition to api mappings, we're looking at navigation models and the semantics
... so potentially we can have a new taxonomy to be referenced in the appendix
... still flushing out the navigation model (stuff other than tab index)
... not sure if it will make it in time for svg 2
... one of the things that was asked was the parts of WCAG that apply to the lengths we refer to in the appendix
... I haven't had time to do that yet

heycam: have you touched the currrent appendix?

richardschwerdtfeger: yes
... we wanted to highlight the new features in SVG 2

<AmeliaBR> https://svgwg.org/svg2-draft/access.html

richardschwerdtfeger: looking at this
... we have new features - list all the places that have keyboard support - tabindex, keyboard handlers, scripting extensions for setting focus, determining active element
... second thing, ARIA support and text alternatives
... how they fit in terms of native language semantics
... don't think I removed the animation stuff from the spec
... we also talk about information in desc and title

<richardschwerdtfeger> https://svgwg.org/svg2-draft/access.html

richardschwerdtfeger: and how aria-label and labelby work
... finally, we link to specs that have direct applicability to vector graphics
... all those documents combined state how svg documents are mapped to accessibility service layers on the major platforms
... refer to aria 1.1 and wcag 2.0
... much more comprehensive and svg specific than the old document

heycam: yeah looks a lot better - old appendix was all wishy washy

richardschwerdtfeger: the TF has been talking about authoring practices - depending on timing we may be able to include that
... I think it's very strong - don't know if even html spec has this much clarification

heycam: further edits would be referencing other specs and explaining how they work

richardschwerdtfeger: e.g. keyboard suport - would be nice but not sur ewhen it'll be ready
... 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
... so is that something you would want to do in svg?
... e.g. this sequence of path drawing calls would produce text
... and put role=text and an aria label
... is that something you would want to do ?

AmeliaBR: you would always be able to say role=text and aria label and it would be accessible for screen readers
... the question is, should we make it accessible to other user agents in that way
... so if you did ctrl-s on your webpage it would find it as text
... or you copied and selected, it would copy and select with plain text included
... this is something new
... aria was very careful not to prescribe behaviour for browsers other than accessibility tools. So this would be something new.
... giving that role attribute more power than it has for aria alone

heycam: this would be for more than just svg?

richardschwerdtfeger: could apply to html as well, but we thought it was powerful for svg

heycam: have you asked the html folks about the idea?

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
... so it's a new idea
... but this is up to the host language - not aria

AmeliaBR: svg can be a testing ground for this
... could it be more than just role=text. e.g. widget roles like buttons, sliders, etc
... they could be mapped to keyboard roles automatically
... right now to create accessibility interactive components in svg you need to write all the keyboard handlers yourself
... it's a big limitation on people making svg accessible

heycam: in terms of level of difficulty of making it accessible - you have to write the keyboard handlers to have the normal behaviour anywa
... I think of it as an integral part of the component
... 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
... you might be using svg to realise some fancy design and the defaults wouldn't be appropriate.

AmeliaBR: there are aria attributes to customise behaviour like that
... but at this point we don't have a detailed proposal
... so just bringing the idea to the group to see whta interest there is

Tav: getting back to text - we talked about something like this when we discussed getting rid of svg fonts
... so I think it's a good idea

heycam: I agree we should have something that allows you to mark up the graphics as text
... so you can do seraching and whatever
... might need to think about it some more to decide if role=text is the best way to do that
... i'm a bit wary of attaching additional behaviour to the aria attributes
... had a discussion a few years ago about making tooltips appear in response to aria roles - had the same wariness then
... not sure if fundamentally it's a bad idea - or it just has'nt been done yet
... so I don't have a strong feeling yet

richardschwerdtfeger: one of the places we'll see this show up is in digital books
... we have an aria module that reflects digital publishing semantics
... will be used in CMS
... specifying browser functionality like - goto glossary
... so it's starting to happen, but the aria working group wouldn't be the group to define that though
... so the question is - do we want to work on the proposal - does the group want that?

heycam: I think there are some details to think about - like what happens in terms of highlighting the graphical element
... that's the main one I'm thinking of
... not an unsolvable problem
... but my personal opinion is that I'm not against it - might be easier to evaluate with a proposal
... in terms of that functionality of declaring some graphics as having text attached
... that's a feature we want some how

AmeliaBR: we can look at other options as well
... perhaps create a native svg way of doing the same thing
... like here's some text - don't render, render this graphical object itself

heycam: that's what I was thinking - divide graphical object into vertical slices to represent each character
... 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

AmeliaBR: we'll get back to you

richardschwerdtfeger: what's the timeframe for svg 2?

heycam: we've made good progress closing issues - should get remaining ones discussed at the f2f
... so I would say we are aiming for the end of the year or tpac for moving to the next publication stage (CR?)

richardschwerdtfeger: not sure how we would get a new navigation model in that time
... but it would be nice to have some sort of taxonomy at least by then
... we'll discuss in the group

heycam: there's always the time afterwards in terms of the test suite
... so the spec won't be in CR for a short amount of time

richardschwerdtfeger: are you doing the workflow with multiple CRs?

heycam: depends on the issues raised

transform on root <svg>

https://lists.w3.org/Archives/Public/www-svg/2015May/0024.html

AmeliaBR: we have a couple of questions with respect to how transformations on the root element
... in svg 1 you couldn't put a transform attribut eon an svg element
... could do it indirectly with url fragments but not well defined and browsers are inconsistent
... css allows transformatoins on everything
... and gives guidance for a general root element case
... but 2 thing specific to svg - viewbox is a transformation, which comes first
... 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
... so assuming that will be adopted for svg root elements
... but transform-origin
... the css specs have waffly language
... to make up for the fact that svg elements hav etheir default transform-origin on the local co-ordinate system
... but css offsets the center of the box
... I've tested browsers and the results are inconsistent - so we need clear guidance
... I agree with cam's comment that we need more explicit language in css transforms
... right now it just says default is 50%,50%... etc
... Cameron suggested to rewrite that as the default style rule for elements in the svg namespace

heycam: I think that's the most practical - I cc'd to the fx list so hopefully Dirk saw

AmeliaBR: the question is - are we going to rewrite that rule so that it applies to svg that is a root element"?
... i pointed out that because we are allowing backgrounds and borders and padding that essentially becomes a css layout box
... and should be treated the same
... though it's more useful to rotate an entire image from the middle

heycam: I think it's consistent with root of html elements having 50%,50%
... and svg child of FO being 50% as well

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
... so I think we're agreed there - so next step is to approach css transforms about rewriting that wishy washy statement
... as a specific default user agent style rule

<scribe> ACTION: heycam to contact css working group regarding default style rule for transform on root element [recorded in http://www.w3.org/2015/05/21-svg-minutes.html#action01]

<trackbot> Created ACTION-3792 - Contact css working group regarding default style rule for transform on root element [on Cameron McCormack - due 2015-05-28].

AmeliaBR: the other question is how the svg view fragment interacts with the transformation on the root element
... all the other svg view parameters replace the attribute on the svg root element
... so there has been some voice on the mailing list if it had similar behaviour
... but its complex because you have to deal with css cascade
... so when we discussed previously we said it would apply as an additional transformation
... you take the svg as it is defined in a file and you put it inside group that has the transformation from the view

heycam: I had forgotten that the other view fragment thing replaces the attribut evalues on the root element
... so it's a bit unfortunate to have transform work differently
... 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

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
... we are saying a url value replaces a style sheet value
... and nothing in the css cascade deals with that

<Smailus> Gotta drop of.

heycam: could probably deal with it by saying it replaces the value given by the presentation attribute

AmeliaBR: then it would be confusing for authors if it overwrote presentation attributes but not styles
... in this case you may be embedding an image - not looking inside the svg code
... 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
... already have a relevant action

heycam: sounds like it's good enough to move forward then

RESOLUTION: the default value of transform-origin on a root svg element is a default of 50%,50%
... the view fragment transform is applied outside all of the other transforms that apply to the root element

heycam: I did bring u pa small question in my email - what do we do with foreignobject?
... e.g. the element itself

AmeliaBR: I think the FO lement itself should be treated as an svg element
... you always have html elements inside it which would be transformed according to the html rules
... but the FO itself - I think you can currently transform with a transform attribute
... so we need to keep the current svg rules

heycam: I was a little confused because we said 'svg element

AmeliaBR: all the mor ereason to get that language replaced by something more precise

heycam: anything else to discuss?

AmeliaBR: think that covers all my points

heycam: don't forget we're switching to webex next week

how do you make them public again?

<AmeliaBR> RRSAgeng, make log public

ahh make log public

didn't make minutes public use to work?

<AmeliaBR> You're not allowed to make public minutes of a private log, I guess?

would be a convenient shorthand though =0

heycam: clever!

delegating is good

<heycam> then it will also list out the Present line, too

<AmeliaBR> Make the robots work for you...

<AmeliaBR> trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

21 May 2015

Attendees

Contents

SVG 2 accessibility appendix update

transform on root <svg>

Summary of Action Items

Scribe.perl diagnostic output