W3C home > Mailing lists > Public > public-pfwg@w3.org > January 2014

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

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 24 Jan 2014 06:57:59 -0600
To: Doug Schepers <schepers@w3.org>
Cc: Michael Cooper <cooper@w3.org>, Gerardo Capiel <gerardoc@benetech.org>, Janina Sajka <janina@rednote.net>, Judy Brewer <jbrewer@w3.org>, Philippe Le Hegaret <plh@w3.org>, public-pfwg@w3.org
Message-ID: <OF432B8AAF.5E40A551-ON86257C6A.0045C92F-86257C6A.004739EB@us.ibm.com>

What I am trying to get agreement on is to modularize ARIA so that we can
form subgroups off of ARIA that extend the ARIA taxonomy for other efforts
like SVG charting and graphics as well as structural e-book semantics.

This sub-group would specify such a taxonomy of semantics. ARIA 1.1 needs
to focus on synchronizing with HTML 5.1 but the subgroup would build a
separate taxonomy that would build role, states, and properties needed for
graphics or a subset of graphics like charts as you are indicating. We
should look at charts holistically. ARIA 1.1 has very tight timelines to
align with HTML 5.1.

A couple of comments: chart-width is not a role. It is property of a chart
(aria-width, aria-height) and they would be applied to an SVG element
having a role of "chart-area" which would probably be a subclass of the
aria role "group".

Having ARIA modules, if done in moderation, allows us to form teams who
need to focus on a specific area of knowledge without impeding the main
group. ARIA was modelled using OWL and so we have an implied semantic
hierarchy that we can build off of to model what is needed for graphics. It
is not something we need to expose to end users but it will help us in the

Also being discussed is a "role description" which would require author
translation. We are evaluating the impact of bringing this beyond the
desktop to the broader web. This would mean essentially custom roles. If
done in excess it could have a negative impact on ATs but if done in
moderation it may have a very positive effect on both authors and ATs.


Rich Schwerdtfeger

From:	Doug Schepers <schepers@w3.org>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS, Janina Sajka
            <janina@rednote.net>, Judy Brewer <jbrewer@w3.org>, Philippe Le
            Hegaret <plh@w3.org>, Gerardo Capiel <gerardoc@benetech.org>,
            Michael Cooper <cooper@w3.org>, public-pfwg@w3.org
Date:	01/23/2014 11:45 PM
Subject:	Proposal for New ARIA Roles for SVG Information Graphics

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

[1] http://svg-sonifier.com/index.svg

[2] https://github.com/benetech/SVG-Sonifier

[3] https://github.com/shepazu/SVG-Sonifier


(image/gif attachment: graycol.gif)

Received on Friday, 24 January 2014 12:58:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:44:59 UTC