RE: Let's Make SVG Accessible!

Doug,
Bravo for putting up something to shoot at! Sounds more like something to shoot for.  SVG A11Y CG Roadmap 1.0.
Katie


* katie *

Sent from my Samsung Galaxy Note® II 

-------- Original message --------
From: Doug Schepers <schepers@w3.org> 
Date: 08/11/2013  3:00 AM  (GMT-05:00) 
To: SVG Accessibility CG <public-svga11y@w3.org> 
Subject: Let's Make SVG Accessible! 
 
Hi, folks–

I'm pleased to see so much interest in making SVG accessible!

First, I think it bears saying that SVG, being a text format for 
graphics, already has a lot of potential for accessibility.

Chaals McCathie-Nevile (Yandex), my co-chair for this community group, 
wrote a specification [1] many years ago with some great tips for basic 
accessibility and some mapping between SVG 1.1 and WCAG 1.0. That 
document defines authoring and content requirements, rather than 
requirements on “user agents” (browsers and screen readers).

Rich Schwerdtfeger (IBM) has been working hard in the SVG Working Group 
on porting some HTML5 accessibility features, and ARIA, into SVG 2. This 
specifies requirements on user agents. We also have plans for adding 
even more accessibility requirements directly into SVG. (I have some 
pretty fancy ideas for this myself.)

But I think there's some useful work to be done even before the spec 
work. I'm going to propose a roadmap for us here.

== Step 1: Identifying shortcomings ==

Right now, although SVG support is very good in browsers, they've mostly 
paid attention to the visual and scripting aspects, and not necessarily 
the accessibility aspects.

Part of that is due to a lack of clear requirements, and clear tests. I 
have faith that if we give browsers and screen readers this clear 
direction, they will be eager to rise to that goal. So, we need to 
imagine the various scenarios for SVG usage, and how that can improve or 
harm accessibility, and write tests to cover those use-cases. As a starter:
* is the <title> element (SVG's answer to the 'title' attribute) 
exposed? in what way? as a tooltip? is that the desired behavior? can we 
turn that tooltip on and off? is the 'title' attribute treated the same?
* can you zoom and pan the content?
* do screen readers read SVG titles? if so, does it work the same in 
various referencing contexts: standalone SVG files; SVG files referenced 
in HTML through <iframe>, <object>, <embed>, <img>; SVG content inline 
in an HTML file; SVG as CSS background images?
* are elements focusable and keyboard-navigable?

We could take those few items and make dozens (or hundreds!) of tests to 
ensure that (1) browsers and screen readers know what to do and (2) they 
actually do it. This is not sexy work, but it is the kind of attention 
to detail that makes a real difference.

But this goes beyond testing... we should also think creatively and 
pragmatically about what features simply don't work right, or aren't 
defined, for SVG accessibility, things that would enhance the language.


== Step 2: Hackathon ==

Once we have some tests, it would be ideal to get together, do some 
brainstorming and testing in real-world scenarios. For this, we'd need 
people equipped with screen readers and other AT, and specifically 
people *who use these AT on a daily basis, people who rely on it*!

We can sit around and test these AT against the tests we've already 
made, make new tests, find even more important edge cases, write code 
and script libraries to prototype features, and generally hack at the 
problem.

At the end of this, we could report back to the implementers of these 
browsers, screen readers, and other AT with our results, and provide 
them a clear path for improvement.

This would help address the current state of the art.

This hackathon could be done fairly quickly and informally; there might 
even be more than one, in different locations.


== Step 3: Workshop ==

Armed with this new knowledge and some momentum as a baseline, we could 
then hold a W3C Workshop, with position papers, presentations, and 
proposals for new features or change requests. This would bring in all 
the relevant stakeholders, and be a more rigorous event than the 
hackathons, with the expected result being formal specification 
requirements.


== Step 4: More specs and features ==

We would take these requirements, and formalize them in various specs: 
some things might go into SVG 2; some into SVG modules; and some might 
even be handled by other Working Groups (like WAI groups or HTML).


This is just a strawman for how we could proceed. I'm open to discussion 
and other ideas. And if people like this approach, we're obviously eager 
to get people to help.

Depending on people's inclinations, we could have an initial telcon, or 
an IRC chat session, or email conversations, or some other way to get 
started. We could train people in best practices on writing W3C tests, 
as well, so people feel equipped to start the task.

Thoughts?


[1] http://www.w3.org/TR/SVG-access/

Regards-
-Doug