- From: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>
- Date: Fri, 22 May 2015 09:30:52 +1000
- To: <www-svg@w3.org>
- Message-ID: <555E6AAC.1070304@cisra.canon.com.au>
Formatted minutes at
http://www.w3.org/2015/05/21-svg-minutes.html
SVG Working Group Teleconference
21 May 2015
[2]Agenda
[2] https://lists.w3.org/Archives/Public/www-svg/2015May/0025.html
See also: [3]IRC log
[3] http://www.w3.org/2015/05/21-svg-irc
Attendees
Present
Thomas_Smailus, [IPcaller], heycam, Tav, stakagi,
[Microsoft], nikos_, Rich_Schwerdtfeger, AmeliaBR,
ChrisLittle
Regrets
Erik
Chair
Cameron
Scribe
Nikos
Contents
* [4]Topics
1. [5]SVG 2 accessibility appendix update
2. [6]transform on root <svg>
* [7]Summary of Action Items
__________________________________________________________
<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> [8]https://www.w3.org/wiki/SVG_Accessibility
[8] https://www.w3.org/wiki/SVG_Accessibility
<richardschwerdtfeger>
[9]https://www.w3.org/wiki/SVG_Accessibility
[9] 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> [10]https://svgwg.org/svg2-draft/access.html
[10] 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>
[11]https://svgwg.org/svg2-draft/access.html
[11] 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>
[12]https://lists.w3.org/Archives/Public/www-svg/2015May/0024.h
tml
[12] 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
[13]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
Summary of Action Items
[NEW] ACTION: heycam to contact css working group regarding
default style rule for transform on root element [recorded in
[14]http://www.w3.org/2015/05/21-svg-minutes.html#action01]
[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.
Received on Thursday, 21 May 2015 23:31:36 UTC