Re: Proposal for New ARIA Roles for SVG Information Graphics (agenda+)

Hi Doug
This is very interesting. I think some of these would be properties not roles. I feel that the aim should be higher -  to make machine processable/ understandable graphs and charts. and the value for apps would be huge.
 
My initial  suggestion for roles for this type of graphs and charts is:

1. node (vertex in graph theory )
2. line (or  we could call it connection or data-line  - edge  in graph theory , but let us worry what to call it if we like the concepts)  

A group role of graph would also be good -( possibly also a child of figure - but we havent come to it yet)  that might be what you inteded as chart area. A graph must contain nodes and/or lines.

Nodes could support your properties
* property x-y pair : x-value,  y-value  (possibly suport 4 pairs if nodes can be bigger then a dot) In a pie chart the sections could be nodes and they would have a simple value .

Lines could connect two nodes or have a start x y pair and an end x y pair. (need to work on the semantics)

A graph could support properties of 
* property : x-axis  - what is  the denomination of the x axis such as mm rainfall or thousands of Yen (possibly deliminated list , possibly associated with value pairs -see bellow)
* property : y-axis - as above

Most importantly we need to support symbol value pairs or classes and work that into the model.
For example we need to be able to say  blue represents the northern train line (on an edge) or squares represent stations with escalators (for a node) or pink represents 2002 values and blue represents 2006 values. 

If we agree let me know and I will start thinking of the semantics for it. It will work better of we know if we are alowing extedability, becuse then a square node would simply be a type of node with label of "stations with escalators"

All the best

Lisa Seeman

Athena ICT Accessibility Projects 
LinkedIn, Twitter





---- On Fri, 24 Jan 2014 07:45:30 +0200 Doug Schepers<schepers@w3.org> wrote ---- 


Hi, Janina, Rich– 
 
Judy informed me today that you are at the PFWG f2f, gathering use cases 
and requirements for the future of ARIA beyond ARIA 1.0. 
 
I'd like to make sure that you are aware of a use case that we have for 
SVG around accessible information graphics. (I don't know the proper 
list, so forgive me if this isn't the right one.) 
 
Basically, to allow scripts (or even accessibility UAs) to be able to 
interpret charts and graphs, we need to be able to mark up specific 
elements with descriptive roles. 
 
This could go off the rails if we're not careful, because it will be new 
work, not something that mirrors existing OS-level accessibility APIs; 
so, we need to be moderate and spare in what new roles and states we 
define, especially at first. 
 
The specific case we've explored this for is a sonifier app [1][2][3] 
that I worked on with Benetech, which takes an SVG line chart as input 
and uses the Web Audio API to generate a tone that rises and falls based 
on the position of a cursor on the line. In order to get the sonifier to 
work, I had to manually configure it to detect hardcoded elements from 
known output, based on their element type and position in the DOM; this 
is too brittle to work on any other output. 
 
So, I'm proposing the following roles, based on this use case; some of 
them can be generalized to other charts, as well: 
 
* role: x-axis 
* role: y-axis 
* role: data-line 
* role: chart-area (?) 
* role: chart-width (?) 
* role: chart-height (?) 
 
The latter 3 are subject to discussion; we need to know the extent of of 
the width and height of the chart, and this could easily be determined 
by a <rect> or <path> element that is given the role of "chart-area", 
but we need to determine if we want to require that having such an 
element is required for making the chart accessible, or if we could get 
the width and height some other way; I think <rect role="chart-area"> is 
the easiest approach, but I'm open to other ideas. 
 
Rich knows about this from discussions he and Gerardo and I have had, at 
the SVG f2f at TPAC. We will write this up in a more formal way in the 
coming weeks, but I wanted to be timely about reporting it, in case Rich 
didn't raise the issue. 
 
I'm happy to dial into a telcon to discuss this if you have time on your 
agenda. 
 
[1] http://svg-sonifier.com/index.svg 
[2] https://github.com/benetech/SVG-Sonifier 
[3] https://github.com/shepazu/SVG-Sonifier 
 
Regards- 
-Doug