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

Re: SVG Accessibility

From: Doug Schepers <schepers@w3.org>
Date: Tue, 22 Feb 2011 23:51:05 -0500
Message-ID: <4D649239.6050400@w3.org>
To: Courtney Christensen <courtney.christensen@viewplus.com>
CC: www-svg@w3.org
Hi, Courtney-

Thanks for bringing this up here.  I agree that for SVG images 
referenced in an <img> element, all the <title> and <desc> text content 
is overkill, but for <iframe>, <object>, etc., the user should be able 
to drill down into the sub-elements.

We will be discussing accessibility a bit at our SVG WG face-to-face 
meeting next week, so I will report back on what's discussed.

-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs

Courtney Christensen wrote (on 2/18/11 4:06 PM):
> 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
> tooltip.
> Even if this functionality were implemented, how exactly would this map
> to traversing the SVG DOM? Doug's WebKit comment:
> ---------------------------------------------------------------------------
>  From WebKit Bug 54357:
> https://bugs.webkit.org/show_bug.cgi?id=54357#c2
> ---------------------------------------------------------------------------
>  From Doug Schepers 2011-02-16 20:14:32 PST
>>  There is presently no standard for what screen readers should do with
> inline
>>  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 this.
> 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 Wednesday, 23 February 2011 04:51:07 UTC

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