Re: SVG and Screen Readers

Hey, Dr. O-

Yeah, you've hit the nail on the head.

In my own way, I've already been doing this.  I made a small library 
freely available on my SVG-Whiz.com site, which displays a rich tooltip 
based on 'title' and 'desc' content, and it is pretty widely used. 
Opera has also taken a step forward and displays the content of the 
'title' as a tooltip natively. (Go Opera!)

This gives authors a concrete reason to use 'title' and 'desc', if they 
are using my tooltip code or the Opera browser.

I appreciate your pragmatic approach.

Regards-
-Doug

Dr. Olaf Hoffmann wrote:
> Hello,
> 
>> Finally, I am eager to take into account any feedback on how the SVG 
>> spec could be made more accessible by these implementors or authors with 
>> specific advice. I am also available to discuss and explain the 
>> accessibility features we already have.
>>
>> Regards-
>> -Doug
> 
> I think, the first step to improve accessibility is to make such 
> elements like title and desc in general more attractive or 'sexy' 
> for any author ;o)
> 
> In SVG 1.1 it is only mentioned:
>> Each container element or graphics element in an SVG drawing can 
>> supply a 'desc' and/or a 'title' description string where the 
>> description is text-only. When the current SVG document fragment 
>> is rendered as SVG on visual media, 'desc' and 'title' elements 
>> are not rendered as part of the graphics. User agents may, however, 
>> for example, display the 'title' element as a tooltip, as the pointing 
>> device moves over particular elements. Alternate presentations are possible, 
>> both visual and aural, which display the 'desc' and 'title' elements 
>> but do not display 'path' elements or other graphics elements. 
>> This is readily achieved by using a different (perhaps user) style sheet. 
>> For deep hierarchies, and for following 'use' element references, 
>> it is sometimes desirable to allow the user to control how deep they drill 
>> down into descriptive text.
> 
> 
> It should be already useful to add something like:
> "user agents have to provide a simple method for the user to get an easy 
> access to the information in desc and title elements. How to do this
> is not specified here and depends on the possibilities of the user agent.
> Competitions between different user agents might show in the future 
> different ergonomic solutions for the best accessibility of the content
> of these elements. 
> For example for user agents with advanced graphical abilities an
> additional entry in a content menue to open an additional window or tab
> with the information of desc and title would be sufficient. Others
> might provide an alternative structured text view or an structured
> aural presentation of the document including all text containing elements 
> on demand."
> 
> 
> Only if it has a usable function for any user and author and
> anyone has a clear benefit from such elements as title and
> desc, more and more authors will use them - maybe several
> of them not in the intended way, but anyway they will start to
> think about using it and hopefully many of them in a useful
> way for any user.
> If the support is only optional or just possible or only needed,
> if the graphical representation is not possible, most authors
> will not care, because there is no benefit for them in their
> preferred (graphical) user agent. In the current situation we have
> the possibility for authors to do something useful, but because
> they cannot observe any benefit in their preferred user agent,
> they will not do it. Improvements here are mainly psychology
> of the average author - if they see the elements have a general
> impact and purpose, they will be used, if not, these elements to 
> improve accessibility are just a lip service in the specification 
> without any practical relevance... 
> 
> 
> Another parallel approach is to optimise examples in the
> specification and test suite, for example to use good title
> and desc elements and to prefer events like '(on)activate' additionally
> or instead of '(on)click', if the last one is not explicitely tested.
> This will focus the attention of developers and authors more on such
> device independent events - if they are supported, they can be used,
> if authors see in the examples, that they are used, they will continue
> to use it. Again, to improve accessibility, it is mainly psychology
> of the average author. They even have not to know something about
> accessibility, if they just use such elements and events additionally
> or instead of others, if the others are not needed explicitely. 
> And they will use them, if they see a general benefit.
> 
> 
> 


-- 


Research and Standards Engineer
6th Sense Analytics
www.6thsenseanalytics.com
mobile: 919.824.5482

Received on Saturday, 10 February 2007 17:56:45 UTC