Re: Title as attribute or element?

> Olaf,
>
> No doubt you've understood some of my concern,
> it may be the WG decided to leave this issue to the UA developers,

would be useful to have something like a competition about the
best approach, to collect some (realised) ideas to get a practical
impression both for users and authors to see, what is useful, 
then this maybe could be described in more detailed for example
as non normative suggestions (what useful is or not depends
somehow on the viewer - for example from a general purpose
browser it can be expected, that title and desc are accessible
for different uses - as alternative view, tooltip, description on
demand etc; for a simple viewer this cannot really be expected
and users of a simple viewer will not expect an advanced 
interactive access to those features).

But if we look for comparsion on the link element in (X)HTML,
we can see, that this unfortunately does not always work well
(some useful implementation can be seen for example in 
Mozilla, SeaMonkey, Iceape but this is element is almost ignored
for example in MSIE or Konqueror - because it is not specified
in detail, how to display it?) And if we do not want to have such
a situation for title and desc in SVG, indeed some more detailled
proposals seem to be useful. Currently implemtentors cannot
do much wrong, therefore I do not understand, why the do not
try to be creative with this to show, that they have better ideas
than other implementors.


> but no doubt authors would like some coherence in behaviour and
> guidance on use.

For the same type of viewer this is maybe ok, but if a normative
text becomes too strict, this excludes better and more comfortable
access for users of advanced viewers, because such a coherence
will typically be on a low level...

>
> consider for instance
> should the tooltip onmouseover display the document title when
> hovering over the document, where no other title for the region is
> present? 

I think, the document title is an exception, if it is already displayed
elsewhere continuously, typically at the top of the window 
(problem for embedded documents with no heading line at the
top of the viewport).
But in general it is useful to have access to all applicable title
and desc elements either automatically for title or for title and
desc on demand. This means in general, that all title and desc
from parent elements are applicable for an element, which 
requires a structured display, something like section+h in
XHTML2 or section+h1 in HTML5. And if desc is given by the
author for svg, the document title belongs to this structure too,
even if it is displayed anyway at the top of the window.


> this could be irritating, so maybe not? but for the children: 
> what is a tooltip to display, in the case for instance where we have
> a bowl of "fruit" such as "apples" , "pears" and "strawberries".
> is it likely that "fruit" could ever be displayed?
> yes, if carefully designed, and

An advanced approach would be this structured display with
headings of different size, desc as paragraphs and indentation 
to pronounce the struture and maybe an extra marker for 
the 'current element'.

>
> bearing in mind there is a rather significant difference between
> navigating with a mouse or keyboard. for instance afaik there is not
> currently a single UA that displays a tooltip when navigating with a
> keyboard. I have filed enhancement bug reports.

One possibility here would be to split the display or to have an 
additional display on demand for the structured alternative text 
content including an additional marker for the 'active/current' 
element. Better ideas?
Amaya already splits the display if required, but the alternative
display could be still improved and there is no relation between
the current position in the graphics and the text I could identify. 


> Perhaps more fundamentally in SVG1.1 it is trivial to add titles to
> elements, and these will be displayed as tooltips onmouseover.
> However it is less clear how the keyboard navigator will benefit from
> these titles.
> eg they could be a handicap if they require to be navigated through.
> in html a number of workarounds such as skip links are being tried.
>
> also
> Jeff has for instance pointed out that title may be used to describe
> both the linked resource and the purpose of the link. But this is
> extremely confusing for both authors and users. html: alt and title
> already demonstrate this confusion well.

Well the xlink:href in an element refers to different content, 
therefore there is always a relation between the element and
the referenced content. The xlink:title describes somehow this 
relation. See here:
http://www.w3.org/TR/xlink/#link-semantics

'The title attribute is used to describe the meaning of a link or 
resource in a human-readable fashion, along the same lines as 
the role or arcrole attribute.'

In (X)HTML I cannot see any confusion about the alt attribute -
for the img element it is simply an alternative to the graphics.
Both represent the content or meaning of the element. 
Exactly one of them has to be displayed. If alt is empty, 
this simply means, the img element has no meaning at 
all - would be maybe useful to have a button in the viewer
to switch off those meaningless images ;o)
The title attribute seems to be an optional additional hint
or help from the author in general, but it has a more 
specific meaning for the link and the a element.
Because (X)HTML is markup for text and SVG markup for
graphics, the purpose of title and desc in SVG is
slightly different. It is more like (optional) additional
or alternative content or description, another textual 
approach to understand the graphical fragment or 
to give additional information, which ideas the 
graphical content repesents. Typically the title attribute
in (X)HTML the value of the title attribute is text too
like the content of the related element, therefore this
is not really another approach for understanding or an
alternative representation of the content.

The original historical meaning of title/caption/heading
is similar to an abstract or a summary.
To sum up the ideas of a graphical fragment is slightly
different than a summary for an article containing text, 
but this original meaning can still be a guide for authors 
for the usage of title and desc in SVG - desc is more for
a longer representation/description/purpose of the
related fragment, title is only the short form.
Because the concept of understanding graphical
content and textual content is very different, it is
always useful to have both in an SVG document
to represent more complex content.
Today for books or in newsletters titles have 
additional meanings, they cannot be excluded
too, but I think, such additional possibilities are
not the main applications for title and desc.


>
> It seems evident to me that we need examples of good practice,
> possible including a test suite to demonstrate these examples and
> others.

Yes.

> perhaps you could contribute some suitable examples?

Hmmm - most of my examples in english language are test samples,
others are in german and some have titles with a hight abstaction 
level like

<title>Lisa</title> 
<desc>Alienated portrait of Lisa in an animated false color 
representation.</desc>

The image itself with the animation is very complex, but this
is arts and the title has a specific meaning related to arts,
it is not really used as an abstract or summary. 
The desc gives just the general technical concept of the
image. Both together are only a representation on a high
abstraction level. But this requires only a basic or simple
access to title and desc without a further relation to
specific fragments

or:

<title>Lissajous</title>
<desc>Animated coloured circles on Lissajous trajectories with
random phase and period. The phase-shift between adjacent
circles is constant, x-, y-position, radius and colour of a circle
represent a dimension of a four dimensional Lissajous figure.</desc>

This is some mixture of arts and mathematics. If a reader nows
the mathematics, title and desc give already an impression about
the graphical content, both are a help to search for the mathematical
basics of the graphical representation.
Typically such samples too have only simple requirements for
the access to title and desc.


or:

<title>Motion in a Central Potential</title>
<desc>A sample for an accelerated motion.
A planet moves around a sun in a reduced two
body problem.</desc>
....
In this example the sun, the planet and a dotted
representation of the trajectory have 
additional title elements, g elements have 
title or desc elements decribing the purpose to
the transformations used to get the motion.
In a similar slightly more complex example due 
to an assumed disturbance the Runge-Lentz 
vector is not conserved anymore, represented 
with a slow rotation of the elliptical trajectory.

This is already a more complex, maybe
educational application. To be useful, there
has to be always a direct relation between
the element and its title and desc, therefore
an advanced display of title and desc is
required often for such educational samples.


There is a similar sample with our solar system,
circles or ellipses represent the planets, title 
elements contain for example the names of
the planets, desc elements could contain more
detailled information either about the planet
or the trajectory of the planet in a more advanced
sample. 
For educational purposes such advanced adventure
samples may contain a lot of additional information 
especially in the desc element, users may want to
explore on demand.

Or I have a sample for a system sun/planet/moon
with a 'moon centered' world view - you can
imagine, that this contains more interesting
transformations with the requirement for
some description to be understandable and
accessible ;o)
For such an example, there can be different
approaches for title and desc, either to explain 
why such 'moon centric' or 'geo centric' world 
views are not very useful to understand what 
happens, or this can be used to explain
transformation mechanisms and approximations
and back transformation related to two body
problems. For the first purpose, one document
title and one document description might be
sufficient, the second requires access to title and
desc in a more advanced way, typically
interactive. And to do this with even more
declarative and interactive animation blows 
up the source code and the complexity of
such documents very much, therefore such
samples are already a good choice to test
the usability of the implementation of title and
desc and how accessible they are especially
with animated elements moving around ;o)


>
> regards
>
> Jonathan Chetwynd
> Accessibility Consultant on Media Literacy and the Internet
>

Hope this helps - the samples mentioned above really
exist either in my art gallery or in one of my tutorials, the 
translation to english I did only on the fly ...

Received on Monday, 7 January 2008 15:26:21 UTC