Re: Let's Make SVG Accessible!

Hi, Léonie–

Thanks for the support and the thoughts.

Yes, the “Accessibility Features of SVG” spec was last updated 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.

There is documentation on writing tests, but it's evolving. I'll find 
out the current state. I think for this specific task, it may be useful 
to subset the documentation, and to provide a few examples.

Regards-
-Doug

On 8/11/13 12:11 PM, Léonie Watson wrote:
> 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
>
>
>

Received on Monday, 12 August 2013 04:50:37 UTC