See also: IRC log
<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_
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
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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/wikag(?)/WCAG/ Succeeded: s/AmeliaBR: if you can come/heycam: if you can come/ Found Scribe: Nikos Found ScribeNick: nikos_ Default Present: Thomas_Smailus, [IPcaller], heycam, Tav, stakagi, [Microsoft], nikos_, Rich_Schwerdtfeger, AmeliaBR Present: Thomas_Smailus [IPcaller] heycam Tav stakagi [Microsoft] nikos_ Rich_Schwerdtfeger AmeliaBR ChrisLittle Regrets: Erik Agenda: https://lists.w3.org/Archives/Public/www-svg/2015May/0025.html Found Date: 21 May 2015 Guessing minutes URL: http://www.w3.org/2015/05/21-svg-minutes.html People with action items: heycam[End of scribe.perl diagnostic output]