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

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
>
>

Received on Friday, 24 January 2014 08:16:23 UTC