Re: SVG and Screen Readers

Hello,

some more thoughts about this.

Another reason why we need an attractive display
of such elements like desc and title and the attribute
xlink:title on any viewer is because many authors
use 'any viewer' to check their work and have no
screenreader. Therefore there is a need to specify
that an alternate text view including title and desc
is not optional.
Even if authors are willing to create something useful, 
they need some useful structured display in their 
preferred viewer as a control and a reward, some 
chocolate to be sure to have done the right thing. 

For example I have no screenreader on my linux-machine 
therefore an alternate text view is the only choice I have 
to check, if the output is somehow structured and 
hopefully useful for all users. And not all
users with display or accessibility problems have a
screenreader or something else specific - therefore 
accessibility features are important in any viewer.
Sometimes it is already enough, if someone does not
understand abstract art, to need some alternate text
as an accessibility feature.
Or in a simulation of a solar system, several people
might want to know, that the small red dot is Mars
and want to know some properties of this object
while other people do not need them, because they
already know them by heart ;o)


The other thing is, it should be not too difficult for
developers to provide such an alternate display.
This means, it is not useful to specify normative, 
how such elements are displayed, but some hints
are always useful for developers just to start with
something to get own ideas.


Well, lets have a short view on the current 'state of the art' 
of display for the elements desc, title and the attribute 
xlink:title in my preferred 'test victims' accessible for me -

1. Amaya 9.51

- main title displayed as document title
- no hint for more elements or attributes in the primary view
- alternate view available, title and desc structured as block
  elements, indented for elements nested in groups, but no
  possibility to distinguish between text elements, title and desc, 
  a cascade of different sizes and weights for title elements on 
  different nested levels would be helpful, similar to the 
  XHTML h1-h6 cascade - why does Amaya not automatically create 
  such a cascade of different appearing titles if needed? - would be
  already almost perfect as an alternate text view of the complete
  document.
- structure view using a list display to distinguish between
  levels of nested elements and the meaning of elements.
  Attribute values are accessible too, maybe a little bit too
  detailed for an alternate view but already pretty good 
  support for a non graphical display
- no tooltips or on demand popups for title, desc and xlink:title
  of single elements or groups or another possibility to
  get only title and desc of exactly one element as a help.
  An on demand display of an elements title and desc and
  those of its descendents and of the ancestor group(s) if
  nested in groups would be pretty to improve accessibility
  and usability of the graphical display in general - who
  wants to search in an alternate text view of the complete
  document, which title and desc is related to the
  little gray path bottom left of an image?
  
2. Konqueror with plugins/extensions KSVG1 + KHMTL + KXML editor

- one title element and one desc element (if short enough)
  directly displayed as document title and description in KSVG1
- no hint for more elements or attributes in the primary view 
- alternate view available using KHTML display, but this is
  plain inline text without any structure 
- structure view with KXML editor using a list display to distinguish 
  between levels of nested elements and the meaning of elements.
  Attribute values are accessible too, maybe a little bit too
  detailed for an alternate view but already pretty good 
  support for a non graphical display
- no tooltips or on demand popups for title, desc and xlink:title
  of single elements or groups or another possibility to
  get only title and desc of exactly one element as a help
  
3. Opera 9. ...

- main title displayed as document title
- no hint or on demand popups for desc elements in the primary view
- title and xlink:title displayed as tooltips for the innermost
  element with one of them, title of outer elements like groups then ignored
- alternate view only with a source code viewer not really
  useful for this purpose
  
4. Geckos 1.8. ... (SeaMonkey, Firefox...)  

- main title displayed as document title
- no hints for more title or desc elements
- tooltip for xlink:title
- no tooltips or on demand popups for title, desc and xlink:title
- alternate view only with a source code viewer not really
  useful for this purpose

Excursion:    
This situation with Geckos and Operas partial support is very dangerous.
If authors detect this for more than one version, we run into trouble getting
some nonsense like

<a xlink:href="#" 
xlink:title="
some text to popup
trying somehow with several tricks to get a new line
or other nasty things
"> <!-- some more SVG--> </a>  

Therefore there is an urgent need for some useful and complete support 
of all title, xlink:title in desc in those 'general purpose' viewers, to
ensure good quality of daily use SVG documents.

And - come on, these browsers are used to display text with complete
or almost complete support for XHTML including tooltips, popups, tabs.
It should be no problem to produce an alternate view of the complete
document or a document fragment on demand using a simple 
'transformation' to get a structured display (using the cascade h1-h6, ul, 
li, div, pre as a replacement for nested groups, desc and title and maybe 
a for the use element).  
Current gaps are maybe the result of the specification too - the descriptions
of title and desc do not really inspire developers to support them with a
high priority and in a useful way. Maybe an additional suggestion for a good
display in one appendix would already help to spark off the fire of fantasy. 

A structured text view of SVG documents could be a first approach of support
of SVG and would be a progress in accessibility too in pure text browsers 
like lynx, links, elinks and curently less advanced graphical browsers like 
Dillo or MSIE.




5. adobe plugin (used in Konqueror)

- desc, title and xlink-title completely ignored
- not even a source code viewer available, if not the extensions or 
  plugins of Konqueror are used
  (the entry in the content menu of the adobe plugin does not work)
  
  
 6. inkscape (041) 

- no display for title, desc or xlink:title
- structure view with XML editor using a list display to distinguish 
  between levels of nested elements and the meaning of elements.
  attributes values are accessible too, maybe a little bit too
  detailed for an alternate view but already pretty good 
  support for a non graphical display
  
  
7. Gimp (2.2), ImageMagick

- nothing to comment, completely no support for these elements and attribute
 

Excursion - well an alternative text display for viewers formerly specialized
in the display or compositing of images is a little bit harder - but if
inkscape for example is already able to provide its own XML editor, it should
be not a big problem to generate a structured alternate text view as well. 
And inkscape is able to pick out any path fragment - what is the problem to
display on demand some popup with title and desc for a single element?
Especially if authors use such composers for SVG, they need an easy access 
to title and desc to write and to check them to create a good document. 
This should be a prominent part of a good composer to help authors to 
create good SVGs.

Received on Sunday, 11 February 2007 15:51:02 UTC