Doug Schepers wrote:
"Thoughts?"
Sounds like a good approach to me.
I think a telecon would be a good idea to set things in motion, and an IRC channel would be a useful base for ongoing discussions.
Holding a hackathon makes sense. It's probably the most effective way to bring together the necessary skills and knowledge, and quite possibly the most productive.
Is there any documentation on writing W3C tests?
My only other thought is that the note that Chaals wrote could do with updating. In the first instance to reflect WCAG 2.0, but later to include some/all of the information we accumulate here.
Léonie.
-----Original Message-----
From: Doug Schepers [mailto:schepers@w3.org]
Sent: 11 August 2013 08:00
To: SVG Accessibility CG
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