<trackbot> Date: 01 May 2015

<cpandhi> Thanks Chaals

<chaals> Best practices for WebEx at W3C...

<chaals> [Use IRC not webex chat. That way we get zakim queue/agenda management, rrsagent logging, trackbot integration, and it is a lot more accessible]

<chaals> scribe: chaals

Coga meeting

<fesch> https://www.w3.org/WAI/PF/cognitive-a11y-tf/wiki/Svg_comments

RS: Yes, there are things being put into an agenda in the coga wiki.

… will be in #coga on irc, 11am Boston W3C standard time, Monday May 11

infrastructure

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

CMN: I've collected a bunch of images and am still collecting and looking for more, on the wiki.

… basic structure is a "use case" name, named after the image, a thumbnail and description, then looking for good or bad practices in the code, ideas about navigation, and there is a pointer ot the image on github.

… The idea is that we'll discuss the images and figure out how to make them better, test proposals for improvement through github, and then collect up waht we did, as guidance for best practices.

FE: We should leave the raw ones raw somewhere. I branched the github repo.

<AmeliaBR> +1 to keeping the originals for comparison

… added my SVG tool, etc.

CMN: there are originals in the wiki that don't really get touched.

… in github you can branch from the originals, submit things that seem obvious like adding a title as a pull request, but make a branch for playing around rather than submitting pull requests on random ideas.

DS: you're not suggesting we don't have an "original" version somewhere÷

<inserted> scribe: LJWatson

CMN: To recap... the original files are on the wiki. We'll use Github to experiment with the files. Github will handle versioning for us. If making small changes to the Github files a direct edit is ok, but otherwise create a fork and issue a pull request to get your changes pushed back into the Github repo.

FE: What if people make changes we disagree with?

CMN: If people start making non-sensical changes, we'll kick them off the repo.
... Some of the examples are unclear in terms of content. Particularly those from IBM.

FE: Check, there might be reasons, but I'll also know what they're trying to do.

CMN: Trouble is that in anonymising it, we've lost critical data needed to understand the content.

ABR: We should send our authoring guidance to WCAG so they can create techniques.

<AmeliaBR> more w/ links in my email: https://lists.w3.org/Archives/Public/public-svg-a11y/2015Apr/0029.html

CMN: If people find things that are wrong on the wiki, let me know and I'll update it.
... Things worth noting down... authoring guidance and techniques, and also what happens when we try to get information out of SVG content - like descriptions.
... We could hack a browser extension? Some discussion about tools we have and tools we'd like would be good - perhaps a wiki page?
... Happy to edit an authoring guidance document, but it isn't worth starting yet - we don't have enough information. Should change in the next couple of months hopefully.

JS: Don't think anything has been done since the original authoring guidance.
... Some will still apply.

LW: We did start on a replacement within the CG.

RS: What's happening with connectors?

DS: Think we understand the use cases and requirements. Could be useful to work on those in parallel, but someone needs to work on the spec itself.
... I should focus on it and get it to an implementable state.
... I talked to implementors a while ago. There wasn't much interest as they had other things to focus on at the time.
... We need to press upon them that this is an accessibility requirement now.

CMN: Is it feasible to consider Connectors as a role, rather than a graphic element?

DS: Think we should do that. Will be cases where you don't want to use a connector, and there should be an accessible way to do that.
... Think it would be bad to do only connector role.

<chaals> [thinks <connector fill="none" stroke="none" … might meet some use cases too]

DS: If something moves around you have to maintain the visual connection (if there is one), and that has to be done separately. Things could go out of sync.

JS: Would rather it was implemented in the language.

<fesch> q*

<Zakim> chaals, you wanted to respond

LW: If we map an implicit role to the native element, it can be applied explicitly.

CMN: Don't think the invisible metadata problem is as likely as it is in other situations. It depends on how you construct the connectors.
... Agree having ARIA as accessibility API only is a stupid idea, but that applies to all of ARIA.

FE: Everyone will use paths. Having a special connector that is a path but unused, makes no sense.

RS: Problem with putting connectors into the native language is that is means the UAs have to build something, and that takes forever. Agree having connectors in SVG itself would be good, but if we want it to be standard in the host language we have a long wait.
... It probably won't be a successful strategy.

<richardschwerdtfeger> +1

<fesch> +1 on connector role

DS: My concern is that while a small number of people will use the connector role, because they didn't have the feedback about whether it works or not, it won't get used correctly/at all.
... There might be a situation where a connector moves, if the thing it's connected to moves.
... Don't think it's an either/or situation - can we have connector role? Yes, we can and should.
... When you connect something you can give a title and desc to the nature of the connection.
... If we have a connector role we must make sure people understand the nature of how that role should work - with title and desc.

<Zakim> AmeliaBR, you wanted to discuss connectors as graphics

ABR: To emphasise the need for a connector element isn't just for accessiblity, it's also a need for graphics.
... Connectors can snap to different points in the content.
... With dynamic/responsive SVG, having that built-in graphical code is beneficial.

<Zakim> chaals, you wanted to say for many use cases being able to have a connector and not draw the path itself seems like a good optimisation - but there are other use cases where the

CMN: I'd like people to look at the use case stuff on the wiki and scribble on it.
... Can think of at least two or three diagrams up there that are cases for why we need connectors.
... Recognise Doug's point that we have use cases already, but think refining/reviewing the use cases and requirements already collected seems like a good approach. Then we need to start work on the doc and making proposals.
... Would like to propose we start going through use cases on these calls - spent time today considering a use case, how it works etc.
... Think we'll get value by taking a deep dive into the SVG content we've got. Perhaps not the whole call, but taking some time to look at connectors in the first instance would be a good approach.

<chaals> [+1 to finding memes, jokes, and cartoons as use case examples]

DS: Agree. Think we'll find lots of example for connectors. See a lot of use in collecting use cases and requirements. Would welcome it - it'll help us talk to browser vendors.
... Don't want it to stall work on documents being done though.
... Would rather work in parallel.

<fesch> +1 working in parallel

<chaals> [+1 to being able to work on spec in parallel to collecting and analysing use cases - it's important they feedback to each other…]

FE: Is there something we can do to move the spec forward?

DS: If I can find two consecutive days, yes. Would help if we had a short use cases/requirements period, so I can make sure I'm on the right page when I start though.
... Propose short session, perhaps 30mins, to collect use cases and requirements.

FE: When will you have time to do this?
... Do what?
... Whatever for connectors.

DS: Suggesting the first thing we do is spend time on a call collecting use cases and requirements.

RS: Think that's great. This is a strategy discussion... Has the Connector spec been vetted by the major browser vendors?

DS: No.

RS: That's important.

DS: Yes, but in order for them to take it serously enough to review we need something more concrete.

FE: If you can do the role/accessibility, doesn't that cover it?

<chaals> LJW: I am happy to spend some time putting use cases together

<chaals> [that is always a good thing to do…]

<Zakim> LJWatson, you wanted to say would be happy to spend time offline with Doug putting together use cases if we can't find call time.

RS: Do you think browsers are more engaged now?

DS: Definitely more engaged.

FE: Jason and Rich... can you help gather more SVG examples?

JS: Can bring ideas and analysis, but not examples.

RS: Didn't Ann from Boeing send examples?

CMN: They're on the wiki.
... If you see examples in the repo but not the wiki, feel free to do the work yourself.

<chaals> LJW: have some examples I can share...

LW: Have exampls from UK Gov and Google I can share.

<chaals> [Please please please put them into the github repo]

<chaals> [I am taking things one by one from the repo into the wiki, adding description, etc…]

RS: Changed map to "none" to no map. Elements with tabindex have to have an acc name, so so have identified this in the spec too.

DS: Made arrangement to meet with editor of CSS UI spec. Whenever we want to meet with him, we can - he's interested in talking about focus.

<chaals> [PLEASE get him on a call]

RS: Would really like that - especially for navigation.

<scribe> Meeting: SVG A11y TF weekly meeting

FE: Have a concern with CSS, we may need to drive it forward if they're not doing it...

DS: Not sure what you mean?

FE: Sorry, Connectors not CSS.

RS: Would like to get a real directional navigation model into SVG 2.0 if we can pull that off.

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/ge ttouched/get touched/
Succeeded: i/CMN: To recap/scribe: LJWatson
Succeeded: s/q//
Succeeded: s/thw iki/the wiki/
Found Scribe: chaals
Inferring ScribeNick: chaals
Found Scribe: LJWatson
Inferring ScribeNick: LJWatson
Scribes: chaals, LJWatson
ScribeNicks: chaals, LJWatson
Default Present: Doug_Schepers, Fred_Esch, +1.512.238.aaaa, LJWatson, [IPcaller], chaals, cpandhi, Rich_Schwerdtfeger, AmeliaBR, Jason
Present: Doug_Schepers Fred_Esch +1.512.238.aaaa LJWatson [IPcaller] chaals cpandhi Rich_Schwerdtfeger AmeliaBR Jason
Found Date: 01 May 2015
Guessing minutes URL: http://www.w3.org/2015/05/01-svg-a11y-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.