See also: IRC log
<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
<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
<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.[End of scribe.perl diagnostic output]