- 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>
Doug, 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 effort. 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 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 (agenda+) 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
Attachments
- image/gif attachment: graycol.gif
Received on Friday, 24 January 2014 12:58:37 UTC