Re: Let's Make SVG Accessible!

Hi all,

On Sun, 11 Aug 2013 09:00:05 +0200, Doug Schepers <schepers@w3.org> wrote:

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

Me too!

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

Yep.

> Chaals McCathie-Nevile (Yandex), my co-chair for this community group,

Sorry I have not appeared until now...

> wrote a specification [1] many years ago...

And as Doug and I agreed in private conversation, it is showing its age.  
It would be good to identify what things in there are still valid, what is  
wrong, what is written in the hopes of a parallel future that won't happen  
and what is written for a future that can still happen.

In particular, I think it is important to figure out what in that note is  
a bad idea, and submit an update or a subsequent version.

> Rich Schwerdtfeger (IBM) has been working [...]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.)

I think these are important steps. In particular, look at the thread  
beginning with the message  
<http://www.w3.org/mid/OF4AB58B0A.55A9A726-ON86257BDB.00663EF4-86257BDB.00673CDD@us.ibm.com>  
about some things that work now.

> 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.

Some comments inline

> == 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.

In parallel, I think it would be good to collect a set of links to useful  
SVG content on the open web. This has the benefit of being a proven use  
case, and lets us understand what people are really doing already.

> 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?

Same questions for the desc element...

> * 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.

Yep. This is stuff we should coordinate closely with the SVG Working  
Group, who are already looking at some of these questions.

> == 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*!

Yes, actually running tests is important :)

[...]
> 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.

I think this is something we should be doing continuously. And I am afraid  
that often, as in my case, we are hardly doing it at all :(

> 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.

Rather than a single hackathon, we might just piggyback on events like  
Test the Web Forward, whose scope is broad enough to include what we want  
to do.

> == 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.

This is a pretty big step, but a worthwhile goal if we do the preparatory  
work.

> == 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).

Yep.


> 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.

I'm not big on teleconferences, but I think having one or two to get us  
going might be useful. Assming we can find a time taht works for a  
majority of us (we stretch across most of the planet, so we're unlikely to  
get this perfect), who is interested in attending a teleconf, say in the  
second half of September? (If we have enough people say yes I'll set up a  
poll to find a time...)

I suggest that part of the agenda be a survey of testing at W3C, and how  
to get the most value from the work we do.

> 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/

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Wednesday, 4 September 2013 12:08:31 UTC