W3C

- DRAFT -

Protocols and Formats Working Group Teleconference
15 May 2015

See also: IRC log

Attendees

Present
Rich_Schwerdtfeger, Fred_Esch, Leonie_Watson, Doug_Schepers, chaals, AmeliaBR, Jason, fesch
Regrets
Chair
Fred
Scribe
Rich

Contents


<trackbot> Date: 15 May 2015

<scribe> Meeting: SVG Accessibility Task Force

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

<fesch> agenda above

<scribe> scribe: Rich

<scribe> chair: fesch

Doug: I spoke to the ChemML people in 2009 and they have a lot of stuff that most chemistry applications do use. Their use of ID is inconsistent with all other XML markup

Working with Coga

fesch: I am looking for volunteers to coordinate requirements with Coga

doug: I think it is more important to find out what we want to do there
... I had a discussion with Michael Cooper about this. They are very early on. I suggest we take the low hanging fruit
... I suggest we incrementally do it.

<chaals> +RichS

<chaals> +DougS

<fesch> rs: agrees with Doug we need to work with coga in an iterative way, not developer ready

<chaals> [I'd like to understand what the ChemML people do differently with ID. But I am not having any success connecting to Webex]

<fesch> rs: we can take low hanging fruit, and take from a aria-coga spec,

<LJWatson> +1 to working iteratively with CogA

<fesch> rs: we have to scope what to take in, Fred is proposing new scopes for roles, Cogo is 3-5 year effort

doug: I agree. navigation has implications beyond coga.
... we can identify overlapping things with coga
... we send those new features to the coga task force to get sign off
... they mary or may not have use cases
... there were one or two things that I thought were functional things that we could do that were unique to coga
... these could be actionable items for SVG

fesch: what if we include media query like things?
... What about their request on media queries?

<fesch> rs: may have to wait for charters, may affect media queries - if there is any metadata we need to support media queries coordinate with

Rich: To deal with media queries, coordinate with new ARIA working group which will work with CSS working group on new functionality

fesch: should we plan for it?

Rich: yes, but it is a longer roadmap item

Amelia: So, yeah I do agree if there is work that is going on elsewhere we should keep it in mind and not try to duplicate it. More generally, it sounds like there are a couple areas to address. There are things to keep in mind wrt. author guidance but don’t involve technical work.
... we need to ensure we don’t impact other user groups
... there were discussions on overriding styles. There are other use cases where for visual impairments you might want to override styles. These could be handled with browser add-sons but that we need semantics that other tools can work with

Doug: at least you can get in

Fred: We don’t need active participation. We will iteratively take things in. We will accomodate what we they need in the infrastructure.

RESOLUTION: We will take the low hanging fruit from COGA and incorporate it with the work being done and continue to work with them

Chemical Examples Provided by Volker Sorge

http://progressiveaccess.com/chemistry/

http://progressiveaccess.com/chemistry/data/

https://en.wikipedia.org/wiki/Chemical_reaction#/media/File:Baeyer-Villiger-Oxidation-V1.svg

Amelia: these are use cases for chemistry but they look like a network graph type diagram

Fred: an input is the interactivity of the drawings

fesch: will come back to chemistry examples in 2-3 weeks
... ARIA does not chang behavior

amelia: Could we use roles more than a way than effected accessibility technology
... the role in SVG should be more powerful to be used for more than just accessibility
... if it is a button then all the normal keyboard controls for activating a button should be applicable

Leonie: this has been discussed in the HTML arena
... Such as when a label is being used to label an element
... there are problems with backwards compatiblity

Rich: but not in SVG

Leonie: If we do it in SVG can we do it in another

chaals: So, yeah, I am a big supporter of doing this. It is a logical thing to want
... This works fine in SVG, but we want to look at it for HTML
... You either trap stuff and prevent default or slide it off to the element

chaals. We need to look at backward compatibility. I will put this on the agenda

chaals: The ARIA folks have asked if they can camp on this meeting?

<chaals> HTML a11y TF meeeting (with some aria time)

<chaals> [July 8-10 in Zaragoza, Spain]

<fesch> rs: this insn't the only place this is happening, digital publishing want to do this too

<fesch> rs: to do this effectively, we are putting a process to extend into a module so we can do this

<fesch> rs: but they have to do an API mapping spec, but designed to avoid name collisions... ARIA working group won't be a bottleneck for the web

<fesch> rs: will try to get it on SVG working group agenda

<fesch> rs: makes a lot of sense

Amelia: Both Doug and I are on that call. So, we can take requirements over

Doug: The SVG working group has never pushed back on accessibility requirements
... They don’t have expertise so the burden is on us

Fred: A related item was role=“text”

Rich: Yes, Amelia and Doug agreed to take this forward if Rich put the proposal together and put it on the proposal

Amelia: Is the appendix done?

Rich: Yes, if I add wcag support that Jason wanted

Doug: I am hopeful that SVG2 could reach a state of completion by the end of the year.
... I will have time to work on connectors in 2 months

Rich: It is done with the wcag feature provided we don’t have new semantics and navigation

Sample Markup for defining Navigation order

Fred: I have been using jQuery to navigate treelike. The taxonomy and how it will be used is an interesting intellectual thought.
... What should we consider with the markup. What guidance we can give. I think role should be inherited
... We need to work on markup to find out what will and won’t work
... Navigation and AT support must be the easiest things to work on

Amelia: I think when we are talking about navigation, there are 2 layers. What type of navigation do we want to support and how do we put this in the markup
... We need to agree on the syntax and agree on a common goal. I have been meaning to write things up. There are 3 modes of navigation: navigation, hierarchical (whether it is based on strict documetn tree architcture or attributes to adjust it), and geometric 2 dimensional navigation.
... is it conceptually possible to have all three modes.
... Only after we've decided that, then we can discuss how are authors going to communicate about these.

chaals: there are several other navigation modes. …. A semantic navigation of a directed graph or structure (as opposed to geometric navigation). We may want to allow multiple topological navigations. We need to determine what types are navigation for an image/drawing
... We are trying to describe the administrative boundary hastily
... there is a further thing I wanted to respond to. assistive technology … I don’t have control over their function
... here are the sort of things we see and get a better sense of scope for these

<LJWatson> +1 identifying problems before we look for solutions.

chaals: it is not harmful to describe solutions. We may not want to define a single pattern for everything

Doug: I do think that there Amelia is right that we have different navigation mechanisms.

Fred: That is what chaals was proposing when he said topological

chaals: yeah, connector is a form of topological navigation mechanism

<Zakim> shepazu, you wanted to ask what "markup" means in this context

Amelia: I will follow up on that. Connectors are one form of vehicle for communicating a navigation approach.
... The idea of navigation … hierarchical is a subset of topological. You can talk about hierarchical but you can’t talk about loops and nodes

Leonie: We don’t want to be too prescriptive

<chaals> [+1 to Léonie]

Doug: say I have some sort of flow chart. If I am at start point A and I have options A1 and A2. That would be the outcome of a logical flow of navigation. I could choose to abandon that.
... not by picking a choice but by a navigation. That should be an option. That does not seem too prescriptive.

Leonie: if you say move to the left it does not mean a lot. We need relationships to determine that

Amelia: We want navigation to be based on semantics and logic. For sighted users using the keyboard we are talking about layout which conveys information. Hou should have a way of conveying that. So if you have dots on a scatterpoint that refer to names on a scale. … Go to the next item in sorted order based on this scale.

leonie: you have provided a number of related information. for different modalities of input your navigation mechanism will vary

fred: what do you mean by layout?

Amelia: geospatial inforamtion inherent in the graph

<chaals> Some directed graphs in SVG, where layout can be important.

Amelia: In a map e.g. it is east, northwest, south, etc.

chaals: Leonie and Amelia are both right. So, going left is inherently a differnt mechanism than moving back
... +1 to not saying how the navigation should work
... ARIA keyboard navigation specifiying the interactions reduced a lot of space for innovation in user interaction
... although we gain consistency . ..

fred: do we want to start markiing up examples?

fesch: do we do this on a meeting or via email

jason: we need to define what types of navigational operations should be suported by SVG
... what type of command set they want to associate with that
... the encoding of relationships is fundamentally important.

chaals: I will describe what happens in other systems to an extent - Opera
... it is helpful to do some of this on email and on these meetings
... so where is your stuff and until I can see what you are doing I can’t comment

fesh: I can put it in on git or on the wiki

chaals: it is better to put it up on the wiki so that we can compare

doug: I am setting up a meeting in a couple with the CSS UI people

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/05/15 14:02:57 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/one of the things is we want to influence SVG/This works fine in SVG, but we want to look at it for HTML/
Succeeded: s/Topic: Markup/Topic: Sample Markup for defining Navigation order/
Succeeded: s/Ameiia: how/Amelia: Only after we've decided that, then we can discuss how/
Succeeded: s/very/vary/
Succeeded: s/made it difficult/specifiying the interactions reduced a lot of space for innovation in user interaction/
Succeeded: s/call/compare/
No ScribeNick specified.  Guessing ScribeNick: richardschwerdtfeger
Found Scribe: Rich
Present: Rich_Schwerdtfeger Fred_Esch Leonie_Watson Doug_Schepers chaals AmeliaBR Jason fesch
Found Date: 15 May 2015
Guessing minutes URL: http://www.w3.org/2015/05/15-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]