<trackbot> Date: 07 August 2015

<richardschwerdtfeger> meeting: SVG Accessibility Task Force

<richardschwerdtfeger> https://lists.w3.org/Archives/Public/public-svg-a11y/2015Aug/0002.html

<scribe> scribe: LJWatson

SVG Accessibility API mapping

RSS: I incorporated Amelia's changes.
... Need to review the changes, but overall it's a much better version.
... We want another heartbeat draft. Would like to do it by end of August if we can.
... Everyone, please review and provide comments.
... Thanks Amelia.

ABR: Need to make a couple more changes. Will create a branch and do those.
... Also the SVG WG meets F2F at the end of the month.

RS: We'll need to add the mappings to the Graphics module too.

<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html

Graphics module

<fesch> http://rawgit.com/w3c/aria/master/aria/graphics2.html

FS: It's now in the correct W3C format, and all roles, states and props.
... Starting with Section 4 (Graphics roles).

ABR: Perhaps we should start with Jason's broad comments?

JS: I'll check that my comments were considered in the new draft.
... We need to concern ourselves with names at some point, but that doesn't lend itself to meeting discussion.

<richardschwerdtfeger> http://rawgit.com/w3c/aria/master/aria/graphics2.html#graphics-doc

JS: When roles extend ARIA 1.1 roles, but just as graphical counterparts, we need to think about whether the taxonomy is appropriate.

ABR: Don't think it can be automatic. Not all SVG will be a graphic, in the conventional sense of the word.
... Perhaps a property instead of roles?

LW: Not sure I understand the issue?

ABR: Do we need graphics-document when we have document role already, for example.

RS: Reason we have role="document" in ARIA is that it tells AT they can be in browsing mode.
... Question is what we want to tell AT when in a graphics-document?

JS: The difference is in navigation.
... The navigation model will depend on the nature of the type of graphical content.

LW: The question is whether the AT or the browser should handle the navigation, not *what the navigation should be.

RS: We want to introduce spacial navigation for SVG, and we'll need to convey that at some point.

LW: But we can only recommend how navigation might work.

ABR: The role would tell the AT to switch into 2d navigation mode.
... The navigation should be consistent for all graphical types though I think.

LW: Not hearing anything different about graphic-document as opposed to document.

ABR: Organising layout - large print, braille etc.
... that this content has meaning based on layout.

JS: Some of that is done with style sheets already.
... Agree with Rich that if we want these kinds of roles, they're super-class roles.
... Not clear whether we need these roles, since the ARIA original roles seem to do the job.

DS: Agree that the nature of the graphic is important - structured graphics, non-structured graphics etc.
... we need to make a strong distinction between these types of graphic.
... For every data visualisation we look at, there is a different set of considerations.
... Think we should define certain kinds of interaction, so ATs have clear guidance.

<richardschwerdtfeger> w?

FS: Like the idea of being able to cue navigation. Totally disagree about having the AT understand the graphic.
... Statistically the information in a graphic is there to build the graphic. You would need to put the entire original dataset in there otherwise.
... That's not what SVG is for. The author needs to provide that information through ARIA labels, or titles etc.

JS: It isn't clear that we can define a single interaction model to cover all kinds of graphics.
... We can have super-class roles, then more granular roles along with guidance for ATs.

FS: There are differences of navigation interaction modes for AT users (screen reader users) and sighted users.
... We say "this is a graphic, turn on 8 way navigation".
... Don't think we need lots of different roles, only roles where different navigation is needed.

JS: The other benefit of roles, is that the AT could derive summary information.

FS: No, that can't be done statistically.

DS: I've done it.

FS: Unless you provide the original dataset and the stats you want, you won't get the right data.

DS: I don't agree with that, or don't understand.

FS: In a plot graph, how would you identify the medians for example, and how would you know how that information was derived?

DS: Why can't you do that?

FS: Your SVG would sweel - it could represent millions of datapoints.
... People may not want to share original data.

DS: True, people may not want to share their original data.
... We're not talking about people who don't want to share data, but those who do.
... When talking about box/whiskers, you don't visually represent all of the datapoints - you abstract data and display that.
... The point of data visualisations is that they're a refinement of the data.
... These things can be represented. Yes you can perform statistics on things. Would like to see more evidence for the notion this is invalid before we throw any ideas out.

JS: There is a need to extract or summarise information, for non-sighted users for example.

LW: If we plan to recommend navigation patterns, we have a huge research task ahead of us.

ABR: When I suggested a general navigation model, I just meant as much as possible.
... Defining basic interactions - next/previous etc.
... Parent/child etc.
... The idea is that the defaults then fit within the generalised model.
... As Léonie said, we need to define the different types of graphic and from there the relationships/navigation patterns.

<richardschwerdtfeger> https://rawgit.com/w3c/aria/master/aria/aria.html#aria-kbdshortcuts

LW: I think if we can define the relationships in the data, that's where we should stop. It isn't our field of expertise to define how to navigate between those objects.

<richardschwerdtfeger> Examples of valid keyboard shortcuts include:

<richardschwerdtfeger> "A"

<richardschwerdtfeger> "Shift+Space"

<richardschwerdtfeger> "Control+Alt+."

<richardschwerdtfeger> "Ctrl+%quot;"

<richardschwerdtfeger> Examples of valid values for the aria-key attribute, which can include more than one space-delimited shortcut, include:

<richardschwerdtfeger> aria-kbdshortcuts="Alt+Shift+P"

<richardschwerdtfeger> aria-kbdshortcuts="/ Ctrl+F"

<richardschwerdtfeger> aria-kbdshortcuts="Meta+C Meta+Shift+C"

DS: Was this keyboard shortcut thing discussed at Google with you, Chaals, John Foliot and others recently?

LW: Yes.

RS: This is not a replacement for accesskey. Hear a lot of hand waving, but no-one delivers.

LW: Dominic Mazzoni has agree to add a test implementation of a revised accesskey spec, behind a flag in Chrome.

RS: So where's the spec?

LW: Chaals is working on it.

RS: So where is it?

LW: Will be posted when a first draft is ready I think.

DS: Q1 is the plan for SVG 2.0 to reach CR - and stable.

<Tink> DS: WOuld people be open to changing this meeting day/time?

<Tink> ABR: Make a poll?

<Tink> RS: My schedule is pretty full in the rest of the week.

<Tink> DS: It's affecting my productivity quite seriously.

<Tink> ABR: Plus the group's productivity when people can't make the call.

<Tink> DS: Could you do an hour later?

<Tink> LW: Yes, I could. That would make it 3pm UK and 4pm Europe time.

<Tink> RS: Can do that.

<Tink> ABR: Me too.

<Tink> RS: Ok, let's change it. DS can you do the necessary changes?

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)

Found Scribe: LJWatson
Inferring ScribeNick: LJWatson
Present: shepazu AmeliaBR Rich Fred Leonie Doug Amelia
Found Date: 07 Aug 2015
Guessing minutes URL: http://www.w3.org/2015/08/07-svg-a11y-minutes.html
People with action items: