Accessible SVG Roadmap v1.0

SVG, as a text format for graphics, already has a lot of potential for accessibility. It’s not just that SVG can be made accessible, it’s that SVG can be much more accessible than other graphics formats, with very little extra effort on the part of developers and designers.

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

To specify requirements on user agents, we will look to SVG2 and related modules. Rich Schwerdtfeger (IBM) has been working hard in the SVG Working Group on porting existing ARIA attributes and some HTML5 accessibility features into SVG 2.  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?
• and so on…

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 accessibility technology (AT), and specifically people who use these AT on a daily basis, people who rely on it!

We can sit around together 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. Using the popular Test the Web Forward event structure and infrastructure should be a good match for this.

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 the HTML WG).

Community Group Deliverables

What does this mean for this, concretely? I’m proposing the following sets of deliverables:

Tests

As mentioned above, we should usefully create a body of tests based on existing specifications and anticipated features, and make implementation reports showing which UAs pass or fail each test.

Use Cases and Requirements

The results of these tests and discussion should be formalized as a set of use cases and requirements, to be reported to various established working groups, not the least of which is the SVG WG.

Developer Documentation

Accessibility expert Léonie Watson noted that the “Accessibility Features of SVG” spec needs to be updated. It was written in 2000, and there have been drastic changes since then, both to the web and to the user agent landscape. We should provide up-to-date information on how best to use SVG accessibly. The standards landscape has changed as well, so we should consider what should be written in a specification (basically, normative authoring requirements) versus what should be written up in developer guidelines and tutorials on WebPlatform.org (and elsewhere).

This community group should make an effort to help lead the documentation effort.

Normative Specs? Unlikely

It’s not the intent of this group to write technical specifications, neither authoring requirements nor browser/AT requirements. That work is better done by working groups already chartered, based on the use cases and requirements generated here. So, it’s unlikely that we will update the  Accessibility Features of SVG spec. But if we do our job well with our other activities and deliverables, that spec won’t be necessary.

Getting Started!

This post 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 are likely to have an initial telcon, and subsequent periodic IRC chat sessions and email conversations. We can train people in best practices on writing W3C tests, as well, so people feel equipped to start the task.

Does this sound interesting to you? Are you ready to roll up your sleeves and get your hands dirty to improve the state of SVG accessibility? Then this is the group for you! Come join us.