Re: SVG and Screen Readers

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.

Received on Saturday, 10 February 2007 13:41:35 UTC