SV_MEETING_TITLE -- 25 May 2016

<fesch> regrets Chaals

<scribe> scribe: Brian

Round the table, news, additions for the agenda

fesch: any news or additions?

News from SVG WG

fesch: any updates features at risk, progress, decisions that affect us

AmeliaBR: can't sya there's any change since last update

Data and SVG

<AmeliaBR> https://github.com/w3c/aria/pull/373#issuecomment-221654595

<fesch> https://lists.w3.org/Archives/Public/public-svg-a11y/2016May/0026.html

fesch: I'm not sure how far off we are all from this. The main issue is stroke and fill in the accessibility tree
... the main thing is SVG tkaing data, even if it's not visible to the user and take it to the accessibility tree. Much like input type="hidden"
... WebAIM gives an example of when you would like to do something like that, it's not a usual case
... I don't want to see authors be confused. They start scaling something adn suddenly something drops off the accessibility tree because htey have a non-visible item.

shepazu: I don't know exactly how to say this. I see where you're coming from, but framing it as "is SVG a data or graphics format" It's pretty clear it's a graphics format.
... if you're concerned with it being in the accessibility tree, an aria value, we need to make sure it's in the tree
... I may have a group, if there's nothing in it, no graphical things. If we add aria to it to say "put this in the accessibility tree", then it can be put in the tree. But, is it a data format, no

fesch: point taken
... if you put stroke: none, it would be not in the tree, exclusion rules take precidence over inclusion rules

AmeliaBR: I agree with Doug's point. Talking about it as a data language is a non-starter. Those graphic elements can have meaning as representations of data
... I want to reemphasize, we already allow elements that do not have corresponding colored pixels to be included in accessibility tree. For both performance and logical reasons

<shepazu> (something outside the current viewport, also)

AmeliaBR: 0 opacity would still be included, a valid fill color that happens to be transparant would still be included. Anything that is continuous that goes down to 0 will be in the tree
... the reason fill none and stroke none were used was that they are in the specs as something that tirggers interactivity or not, pointer events, property
... the way I wrote the spec is that it will defer to the pointer property
... This does then result in a complicated set of interactive properties. Which is an unfortunate situation. It also results in some invisible shapes, a 0 height bar, which are included. Or, a shape in a math where you're using opacity 0. But if you included the smae thign with fill none it would not be included
... for simplicity and consistency, I'd consider changing fill none and stokr none as hidden
... visiblity hidden would still be hidden. But, as far as the AAM, we could say "visibility hidden means the element is hidden unless it is interactive based on the pointer-events property"
... does that sound like a reasonable compormise?

fesch: I'm happy with not having stroke none and fill none exclude stuff from the accessibility tree. But, I thought that might be hard on authors. Fill or stroke set to none can happen programmtically without you realizing it
... I don't have a lot of problems with that. The way the rules are exclusion takes priority over inclusion. Short answer is, yes I'm happy dropping stroke and fill none stuff

Rich: seems reasonable

shepazu: I think it seems reasonable. As we get into the details, of how people structure documents, data visualizations specifically, we'll find exceptions, and we will need to change it
... that requires experience, let's not dwell today on what we don't know

AmeliaBR: we will always find real world examples that don't take into account assistive tech. If they are, they're doing it based on how support exists now, which is inconsistent
... it's about finding something reasonable while having a logical spec for going forward.

shepazu: sounds good as a starting point, let's reexamine if it causes problems

<AmeliaBR> proposed resolution: Change SVG-AAM so that fill:none and stroke:none are not considered native semantics for hiding an element

RESOLUTION: Change SVG-AAM so that fill:none and stroke:none are not considered native semantics for hiding an element

<AmeliaBR> ACTION: Amelia to update SVG-AAM re fill/stroke none & exclusion rules [recorded in http://www.w3.org/2016/05/25-svg-a11y-minutes.html#action01]

<trackbot> Created ACTION-2024 - Update svg-aam re fill/stroke none & exclusion rules [on Amelia Bellamy-Royds - due 2016-06-01].

AmeliaBR: after I've done that, are you ok with me merging that branch into main?

OTHER SVG-AAM EDITS

<AmeliaBR> https://github.com/w3c/aria/pull/373

<AmeliaBR> https://rawgit.com/w3c/aria/svg-aam/svg-aam/svg-aam.html

fesch: any comments on Amelia's edits?

AmeliaBR: the other main normative changes were cleaning up includsion/exclusion based on presentation none being overrriden by certain factors
... the other change here was role mappings now use the new graphics roles by default

RESOLUTION: Accept Amelia's edits to SVG-AAM pending completion of 2024

ARIA PRESENTATION NONE

Rich: the common module got partially reviewed
... they wanted a majaor rewrite of the whole section. I'm going to push for ARIA 1.2
... hasn't added a lot to hte section other than adding native language host semantics. We didn't have that before, it was something Amelia asked for
... we also changed the title of the section
... I'm trying to take ARIA 1.1 so there's no changes and we can move forward with SVG2

fesch: So, as far as we're concerned in this task force. The part Amelia was concerned with, the roles, that's all done and we have nothing to worry about?

Rich: Correct. We just have one more review to get through. I think we're ok

AmeliaBR: related to that. Do you expect to be able to merge that into the master branch this week?

Rich: the process is this, we need to have a resolution, and because of calls it'll have to be 7 days

AmeliaBR: in SVG-AAM I'd like to have a clearer link, but until that gets into master. Once the edits go through I'll make the links

fesch: anyone have any comments on none/presentation and how it impacts us?

Publication Schedules

Rich: We're trying to lock down aria 1.1
... I can't do that in the next 3 weeks. We'd need to go through the ARIA spec and need to make sure there's nothing we need to add for states properties roles
... I know SVG has a different timeline, Amelia I know you were gonna restructure that section to be easier to read for authors
... what i'd do, is I'd try to sync work with SVG-AAM and the graphics module. But, that hasn't really changed

AmeliaBR: we made some editiorial changes. The thing that's holding us up is the new graphics-aam. We need to have the other spec published at the same time. That's where the dependency is. The mappings for the new roles
... We may need to publish an initial working draft, the first of the graphics-aam
... even though it may have lots of gaps and empty cells in tables
... we may need to publish it so we can have links to other specs

Rich: did we update that for graphics-doc?

<Rich> https://rawgit.com/w3c/aria/master/graphics-aam/graphics-aam.html

<fesch> ACTION: fesch to add introduction AAM [recorded in http://www.w3.org/2016/05/25-svg-a11y-minutes.html#action02]

<trackbot> Created ACTION-2025 - Add introduction aam [on Fred Esch - due 2016-06-01].

<fesch> ACTION: fesch to coordinate release of 3 docs with ARIA 1.1 - talk with MC [recorded in http://www.w3.org/2016/05/25-svg-a11y-minutes.html#action03]

<trackbot> Created ACTION-2026 - Coordinate release of 3 docs with aria 1.1 - talk with mc [on Fred Esch - due 2016-06-01].

<Brian_> fesch: any more updates?

Authoring Practices Document

<Brian_> fesch: doug, take it away

<Brian_> AmeliaBR: what updates do you have on the document?

<Brian_> shepazu: I have been working a lot on this document in the past few weeks

<Brian_> shepazu: It's really really rough still, but I'm really pleased with how much I've gotten done with it in the past few weeks

<Brian_> shepazu: I've added stuff on responsive images, followed up on chaals' suggestions on title

<fesch> http://w3c.github.io/svgwg/specs/svg-authoring/

<Brian_> shepazu: a bunch of examples. All the ways of embedding SVG in HTML

<Brian_> fesch: doug, you did miss one - you did not use the embed element

<Brian_> shepazu: that's been deprecated

<Brian_> fesch: ok good

<Brian_> AmeliaBR: it doesn't add anything over object

<Brian_> fesch: we're not going to encourage it's usgae

<Brian_> shepazu: we could add a note that embed is functionally equivalent to object

<Brian_> shepazu: I added stuff around animation. Lots of stuff around animation in here

<Brian_> shepazu: lots of stuff around responsive images

<Brian_> shepazu: most of this is not, at this point, about accessibility. I've worked accessibility into it

<Brian_> shepazu: the first parts. Structure, navigation and activation, to some extent resizablity, touches on accessibility

<Brian_> shepazu: unless people tell me to add stuff about accessibility, until I add the aria sections and data visualizaiton sections

<Brian_> fesch: any comments?

<Brian_> fesch: any feedback for doug?

<Brian_> fesch: I saw you had an SVG image and you didn't give it an alt attribute.

<Brian_> shepazu: that's true, I should probably add that

<Brian_> fesch: there is an image and it says hover to see the name

<Brian_> AmeliaBR: can't hover an image

<Brian_> shepazu: that's the point

<Brian_> shepazu: if you look at the section on SVG and objec,t and look at hte one below that where there are two side by side

<Brian_> shepazu: maybe I should add in the figure about interactivity

<Brian_> shepazu: I wanted there to be text, animation, and interactivity

<Brian_> fesch: I jumped from the table of contents and images and didn't read the stuff in between

<Brian_> AmeliaBR: it's as simple as changing the caption

<Brian_> shepazu: I'll go ahead and add that there too

<Brian_> fesch: hopefully we'll have enough ot meet when rich is on vacation

<Brian_> Rich: I've got a quick question. Where are we on SVG and CR?

<Brian_> shepazu: I can't say specifically, end of June. When we have a plan I'll let you all know

<Brian_> shepazu: The one thing I want to note is that my orbits animation is pretty awesome

<Brian_> AmeliaBR: it is

<Brian_> shepazu: I looked up the relative radiuses and orbital rates and added them into the animation

<Brian_> AmeliaBR: if you could slow down on the overall speed, it's making things hard to hover

<Brian_> fesch: I couldn't get it to hover on the image

<Brian_> AmeliaBR: the system tooltip hover doesn't always catch. Oh, nevermind, I'm getting it

<Brian_> AmeliaBR: the orbital also triggers to tooltip

<Brian_> shepazu: it's not the orbital itself. I made a ticker ring behind it to always catch the tooltip

<Brian_> AmeliaBR: shows a lot of things at once

<Brian_> shepazu: I really liked it. Also, my responsive image demo.

<Brian_> shepazu: The second responsive image demo, with the clock

<Brian_> shepazu: as you shrink the numbers turn to tick marks, and as it shrinks further it, it becomes an icon

<Brian_> fesch: I think that is nice

<Brian_> fesch: anything else?

<Brian_> regrets Leonie,chaals

<Brian_> regrets chaals

<Brian_> trackbot, close telcon

<trackbot> Sorry, Brian_, I don't understand 'trackbot, close telcon'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

<AmeliaBR> trackbot, end telcon

- DRAFT -

SV_MEETING_TITLE

25 May 2016

Attendees

Contents