W3C home > Mailing lists > Public > www-svg@w3.org > February 2011

SVG Accessibility

From: Courtney Christensen <courtney.christensen@viewplus.com>
Date: Fri, 18 Feb 2011 13:06:21 -0800
Message-ID: <4D5EDF4D.9000501@viewplus.com>
To: www-svg@w3.org
I have recently been discussing some SVG accessibility concerns with 
Doug Schepers. From this discussion, the following WebKit bug report was 
filed. But these are general issues, not specific to WebKit. It seems 
that there needs to be a discussion to better define how assistive 
user-agents behave, especially in SVG islands in HTML.

The bug report shown below focuses on how <title> and <desc> tags should 
be exposed to screen readers -- suggesting that the rootmost <title> 
(and <desc>?) element(s) act as an <img>'s ALT tag would. Doug says 
below that this is discussed, but not normatively defined.

And indeed, using current browsers and screen readers, I have found very 
little support for this. The "odd man out" is IE9, which exposes ALL 
elements with <title>s to the screen-reader's buffer, regardless of 
depth. It also provides this info on mouseover. (Mentioned below as 
possible "overkill")

Foreseeing this interference with authorial intent, link [3] below 
strongly suggests using role="tooltip" for elements which are to expose 
their <title>s. I've found NO support for this yet; instead browsers 
expose everything with a <title> element, usually in the form of a popup 

Even if this functionality were implemented, how exactly would this map 
to traversing the SVG DOM? Doug's WebKit comment:
 From WebKit Bug 54357:
 From Doug Schepers 2011-02-16 20:14:32 PST

 > There is presently no standard for what screen readers should do with 
 > SVG islands.

The W3C Note 'Accessibility Features of SVG' [1], from 2000, does 
discuss SVG accessibility, but as mentioned, it does not normatively 
define precisely what screen readers should do.

Also, there are some specific suggestions in the SVG Tiny 1.2 spec [2] 
for both authoring content and screen readers, but it could use more 
precise and normative instructions.  The SVG WG plans to do this in an 
upcoming SVG Accessibility specification, and as part of SVG 2.

 > We are spearheading an effort by DAISY and the W3C SVG Working
 > Group to create SVG accessibility standards.  One proposal is that screen
 > readers read the root-level <title> and <desc>.

This is suggested in SVG, most recently in SVG Tiny 1.2 [3].

 > This is most elegantly
 > accomplished by having those two properties appear separately in the
 > accessible DOM elements exposed to screen readers.  Presently IE9 
does this
 > but also exposes <title> and <desc> of all graphical objects - which we
 > believe is overkill and annoying.   We have asked Microsoft to change 

If all the elements are exposed at once, this is indeed overkill, but if 
they are exposed as discrete elements when the immediate parent is in 
focus, then it is appropriate, just as progressively exposing any 
structure text content (e.g. in HTML) is useful.

The key is in defining the navigation behavior so users can explore the 
content, or skip over it, at their own discretion.  This will take 
coordination between the author of the content structure and the screen 
reader software, though a well-defined algorithm.

 > Other browsers seem to expose nothing in SVG to screen readers while
 > traversing a document linearly.  We are requesting that all browsers be
 > updated to include this feature, and we hope that Safari can be 
updated to
 > do this.

We also need to consider the order in which text content is made 
available (presumably document order should be the default, with 
possible overrides), and when labels should be used instead of 'title' 
and 'desc' elements.

This should all be discussed on the public SVG mailing list,  
www-svg@w3.org, and standardized as part of SVG.

[1] http://www.w3.org/TR/SVG-access/
[2] http://www.w3.org/TR/SVGTiny12/access.html
[3] http://www.w3.org/TR/SVGTiny12/struct.html#uiTitleDescBehavior
Received on Sunday, 20 February 2011 21:28:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:24 UTC