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

Hi Doug

I would be happy to hear you ideas if you think it would help. If  you want to chat on Skype , my handler is lisaseeman. 

My two cents would be that we should make the ARIA coverage of the concepts as thorougher as possible - even  if the syntax exisits already in SVG. People can use the native SVG, but ARIA would be complete, and that would be useful if some other platform needed it.

All the best

Lisa Seeman

Athena ICT Accessibility Projects 
LinkedIn, Twitter





---- On Fri, 24 Jan 2014 10:16:09 +0200 Doug Schepers<schepers@w3.org> wrote ---- 


Hi, Lisa– 
 
Actually, I have a proposal (and script library) for native graphs in 
SVG, called SVG Connectors [1]. That way, graphs wouldn't need ARIA; if 
graphs were native constructions in SVG, both visually and "logically", 
they would have the benefit of being accessible without so much extra 
authoring effort. I have to carve out some time (at least a couple 
weeks) to revise this spec and make it more rigorous and detailed, but 
the SVG WG has tentatively accepted it as a deliverable already. 
 
About the aim being higher, this is what I was cautioning about. I've 
thought pretty deeply about this for a few years, and I agree that there 
are some simple ways to categorize most charts, but I want to start from 
clear use cases, like the ones we had for the sonifier. 
 
I'd love to talk to you more about this at your convenience. 
 
[1] http://dev.w3.org/SVG/modules/connector/SVGConnector.html 
 
Regards- 
-Doug 
 
 
On 1/24/14 2:40 AM, lisa.seeman wrote: 
> 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 
> <http://accessibility.athena-ict.com/default.shtml> 
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter 
> <https://twitter.com/SeemanLisa> 
> 
> 
> 
> 
> ---- 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 
> 
>