Re: accessKey - label and alternative keys

I think, typically authors and users do not really need/want
a relation between an element animate/animation and 
a begin/end event with a label. 
Often it is a more complex situation, especially if other
animations are syncronised to the interactively started
animation.
What could indeed help is something like a XHTML definition
list within metadata using RDF triples to indicate the
relation on a more abstract level.
If we have for example a group of elements representing 
an initially sleeping cat, this complete group can
include different animations to wake the cat with
some interactivity and maybe in different ways. 
The main issue is about the cat and how to awake it
or to get it sleepy again, not necessarily about
a single animation.
A formal and computer understandable relation 
indication is relevant, if as mentioned the viewer
needs to replace for example accessKeys or events
in general, because not all are avialable. 
Obviously this has to be done both in the description/label 
and within the begin/end list item consistently.

To do this, one has either to use such a
combination of elements from another language
with a richer structure for text like XHTML in
combination with something like RDF triples
to indicate the relation or there has to be
a new SVG-animation-accessibility group
of list like elements to indicate such relations.
Of course, with the second option the
probability of implementation is higher, 
because it can be specified more specific for
the intended purpose and it is much easier
to specify how to interpret this by a viewer.


If a 'text only' viewer without graphical 
capabilties or a general viewer to generate
an alternative text view extracts title, desc, metadata 
and other text containing elements, a solution with
multiple title elements would be pretty confusing,
because typically in a text representation something
has only one title (maybe an additional subtitle), and
this indicates, what it is about, not how to use it,
especially for a text representation it is not very
useful to get a title on how to start an animation,
if the viewer does not show the animation at all,
it is more relevant to get some information, what
the animation represents. Therefore tooltip like
information like a label is better noted in desc, or if 
more structure is required in metadata, and for
the example with the cat it is better noted as a
direct child of the group representing the complete
cat as within a single animate element. 
This is relevant too, because for some practical
reasons (rendering order etc) the animation elements 
are maybe in different places in the source code
or within a defs element. This is not relevant for
a specific accessKey solution, but for a more general
approach for interactivity.

This allows an author to provide a compact
descriptive structure for the cat group and maybe 
another for another group representing a mouse or a
dog (animation begin/end within these groups may
trigger some activities for the cat as well and vice
versa).

Sometimes (often), for better usability and understandability
it might be a good idea to provide those event lists in a
specific order, the author has to do this, because the
author has the capabilities to understand the intended
purpose. The viewer cannot do this automatically having 
only labels related only to begin/end list items or single
animation elements.


Olaf

Received on Monday, 22 June 2009 09:41:10 UTC