W3C home > Mailing lists > Public > www-svg@w3.org > July 2008

titles and descriptions in SVG in general (was: How to provide titles and descriptions in a second language?)

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Wed, 2 Jul 2008 17:56:58 +0200
To: "Jeff Schiller" <codedread@gmail.com>, j.chetwynd@btinternet.com, www-svg@w3.org
Message-Id: <200807021756.58907.Dr.O.Hoffmann@gmx.de>

Jeff Schiller:
> Jonathan,
>
> On 7/2/08, Jonathan Chetwynd <j.chetwynd@btinternet.com> wrote:
> > my accessibility concerns are far removed from this issue, though
> > naturally I welcome your suggestions.
>
> Your email suggested that user agents did not display a tooltip (though
> Opera, in fact, does).  Thus, I assumed you were interested in getting this
> evaluated and fixed across browsers.  One step in this direction is to
> generate a test suite that identifies what browsers should be doing,
> opening and tracking bugs, etc.  I was hoping you could help in this
> regard.  Can you clarify why your concerns are "far removed from this
> issue" ?
>

Squiggle displays both title and desc of single elements, this is already
even better than only displaying the title ;o)
Amaya provides an alternative text view - currently without much
structure but the best what I have currently seen, unfortunately
without a direct connection to the related graphical elements.

And because it is currently not specified, how to structure these
presentations of text alternatives, it could be maybe tested, 
whether all title and desc in a document are accessible at all
or no or even some of them - why to restrict, if one can get it all?

It would be pretty surprising for example to get such an 'hover-tooltip'
from Squiggle or Opera type for a SVG document printed on a 
sheet of paper - but it would be less surprising to get a complete 
and structured text alternative output from the printing program
on a sheet of paper.


And for an optional hover-tooltip-technique about the suggested
tests in http://www.w3.org/Graphics/SVG/IG/wiki/Accessibility_Activity

for example this one:
 <svg>
  <g>
    <title>FAIL</title>
    <circle>
      <title>PASS</title>
    </circle>
  </g>
</svg>

why should it be wrong to display both titles in a structured way?

An advanced user agent could for example transform this to 
something like this (using XHTML2/HTML5 as pseudo-code):

<html ...>
<body>
<section role="g">
  <h1>FAIL</h1>
  <section role="circle" class"current">
  <h1>PASS</h1>
  </section>
</section>
</body>
</html>

or old HTML4:

<html>
<body>
<div class="g">
  <h1>FAIL</h1>
  <div class="circle current">
  <h2>PASS</h2>
  </div>
</div>
</body>
</html>




This is even more useful as to show only 'PASS' as tooltip-output
and could be an approach for a non-visual presentation at the same
time.


Or what about such documents:

<svg ...>
 
    <title>Basic Shapes</title>
    <desc>Some samples for basic shapes in SVG.</desc>

    <circle cx="0" cy="0" r="10">
      <title>Circle</title>
      <desc>The circle element has the attributes cx and cy related to the
       center of the circle and r for the radius of the circle.</desc>
    </circle>

    <ellipse cx="0" cy="20" rx="10" ry="5">
      <title>Ellipse</title>
      <desc>The ellipse element has the attributes cx and cy related to the
       center of the circle and rx and ry for the radii of the ellipse in x
       respectively y direction.</desc>
    </ellipse>
 
 ...

 
</svg>

An advanced user agent could provide the complete structure as
output on demand. If for example the user wants to see a tooltip for
the ellipse, the circle text alternative is grayed out, document title
and description  and those of ellipse are in black to indicate, what is
currently relevant - or an advanced user agent may minimize information
in other desc elements to an icon like '>' to indicate, that there is more
information available on demand.

I think, it would be not very clever for tests to exclude those advanced
and much more helpful possibilities, to scarifice all this, just to ensure
that a minimal tooltip is popped up at all ...


Another approach could be to write a simple parser script (for example 
in PHP) and to provide it to interested authors to generate alternative 
text views automatically until viewers can do it on their own in a useful 
and usable way?
Together with some suggestions for authors how to write and to
structure documents to get some useful output with even a simple
parser this might show, what viewers/browsers should implement ...
Received on Wednesday, 2 July 2008 16:00:04 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:39 GMT