See also: IRC log
<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
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
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
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
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]