2008-01-01/2008-12-22 2009-07-04
SVG - Scalable Vector Graphics is only text. Because it is XML, it consists of pure text, not more. Any element and any attribute and its value has a well defined meaning. Therefore, only reading the source code of a SVG uncovers what the content of the document on a low level basis really is. Typically it is not much more than highly abstract geometrical shapes like rectangles, circles, ellipses, polygons, paths. This is maybe similar to an approach to observe single atoms to understand, how a creature works. This approach is not completely hopeless, but to derive the intentions, and the conceptions resulting from the thinking brain of the creature from the behaviour of single atoms is obviously not completely trivial. It is not completely trivial too to derive the purpose, the meaning, the usefulness of an SVG document just reading the composition of elements and attributes in a reasonable time for any audience. Therefore SVG provides other approaches for authors, to give an understanding of the document, using additional elements, which contain text with a descriptive purpose. Something happened when an author created the graphics from such simple entities like elements and attributes. And suddenly the document, the composition of elements and attributes became more than just an arbitrary accumulation of tags. And the author has in its mind, what it represents, therefore the author has the ability to explain exactly this.
SVG is a graphics format with the possibility to contain readable text in different ways.
Text content from elements like text, tspan,
tref, textPath or textArea (version tiny 1.2) is converted
directly into displayed graphics.
Text content from elements like title, desc, metadata
is not displayed directly as graphics inside the rendered image. Additionally for metadata
it is expected to contain elements from other namespaces and title and desc may
contain elements from other namespaces too. All these elements may contain (additional) textual information
about the image and it can be assumed that it is in general useful and helpful for any audience, if this information
is made accessible by any user-agent somehow. SVG tiny 1.2 for example recommends in the
appendix section F.3, that SVG
user Agents should provide mechanisms that allow assistive
technologies to achieve a useful text-only view. Examples include a DOM
explorer, a synchronized text only view, or an XSLT
style sheet to convert the textual content to XHTML.
But how a useful and meaningful text-only view is obtained, depends on the textual presentation capabilities of each user-agent. The access to this textual content cannot be seen as an equivalent alternative to the rendering of the graphics, because SVG is mainly a graphics format, therefore a typical SVG document is not completely represented with only a textual presentation. Anyway this parts of the document may contain the only information accessible to user-agents like screenreaders or in general for aural presentation or for a provisional presentation, if advanced graphical rendering in a user-agent is currently not yet implemented. Even if a user-agent is able to present the graphical content, a similar approach can be used to provide an access to the textual information of the document. This may happen for example with an interface or context menu to switch between the graphical and the text presentation on demand or for a standalone document with an optionally available split of the display window in two parts (see behaviour of Amaya or the combination of Konqueror+KSVG+KXML for example).
Because there is no recommended interpretation of not directly rendered text containing elements, it is a useful approach to collect some ideas how to create such an additional textual presentation by user-agents and how to structure documents and to use such elements by authors to help user-agents to produce something understandable.
To improve the understandability of the different presentation approaches XHTML or the Literature Markup Language (LML) and CSS are used to shorten the argumentation. It is not expected, that all user-agents transform the documents into XHTML or LML, these formats are only used here, because XHTML has well known and interpreted elements to markup text in a semantical way at least for the prose type of text. The newer LML has much more elements to markup text in a semantical way, even more useful, but less known.
The simplest approach for authors is to provide exactly one title element and one
desc element and maybe a metadata element as direct children
of the rootmost svg element. It is already strongly recommended by the
recommendations of SVG to provide not more than one title,
desc or metadata as a direct children of the same element.
And they should be before any other possible content of the element, to simplify the identification for
user-agents. It is already strongly recommended by the recommendations of SVG to provide at least the
title element. To identify these specific elements in this article, they will be typically
called root-title, -desc, -metadata respectively.
Therefore the first simple approach is to present (only) these three root text elements as textual
presentation of the image.
The following (almost empty) sample shows a good structured
document containing root-title, -desc and -metadata.
<?xml version="1.0" encoding="iso-8859-1" ?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG Tiny 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd"> <svg width="90%" height="100%" viewBox="0 0 1000 1000" xmlns="http://www.w3.org/2000/svg" version="1.1" baseProfile="tiny"> <title>Empty SVG Sample</title> <desc> In an SVG document additional textual information of the image can be provided by the author using the elements title and desc. The metadata element may be used to provide (structured) metadata about the image typically using elements from another namespace. </desc> <metadata> <!-- some metadata, maybe some RDF, here represented with untypical plain text, authors cannot expect, that plain text for metadata is understandable for programs or robots --> Author: Dr. Olaf Hoffmann Date of creation: 2008-02-09 Context: http://hoffmann.bplaced.net/svgtext/ etc </metadata> <defs> <!-- some not directly rendered (graphical) content --> </defs> <g> <!-- g element representing the graphical content to be rendered directly --> </g> </svg>
The presentation might be similar to that of the following sample as a XHTML document. The version XHTML+RDFa is used to preserve the meaning of the replaced elements.
<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html version="XHTML+RDFa 1.0"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:s="http://www.w3.org/TR/SVG11/"
xml:lang="en">
<head profile="http://www.w3.org/1999/xhtml/vocab">
<title property="s:struct.html#TitleElement">Empty SVG Sample</title>
<style type="text/css">
p.desc, p.metadata
{
white-space: pre-line;
}
</style>
</head>
<body>
<h1 class="title" property="s:struct.html#TitleElement">Empty SVG Sample</h1>
<div id="help">
<ul>
<li><a href="#description">Description</a></li>
<li><a href="#metadata">Metadata</a></li>
</ul>
</div>
<div id="description">
<p class="desc" property="s:struct.html#DescElement">
In an SVG document additional textual information of the image
can be provided by the author using the elements title and desc.
The metadata element may be used to provide (structured) metadata
about the image typically using elements from another namespace.
</p>
</div>
<div id="metadata">
<h1>Metadata</h1>
<p class="metadata" property="s:metadata.html#MetadataElement">
Author: Dr. Olaf Hoffmann
Date of creation: 2008-02-09
Context: http://hoffmann.bplaced.net/svgtext/
etc
</p>
</div>
</body>
</html>As an alternative the related presentation with LML sample document:
<?xml version="1.0" encoding="iso-8859-1" ?> <?xml-stylesheet href="../lml/lmlmetahover.css" type="text/css" title="LML default" ?> <?xml-stylesheet href="../lml/lmlBase.css" type="text/css" title="LML meta off" alternate="yes" ?> <?xml-stylesheet href="../lml/lmlmetastatic.css" type="text/css" title="LML meta on" alternate="yes" ?> <literature version="1.0" xmlns="http://purl.oclc.org/net/hoffmann/lml/" xmlns:h="http://www.w3.org/1999/xhtml" xml:lang="en"> <title>Empty SVG Sample</title> <meta> <index> <list ltype="uo"> <li><h:a href="#description" role=":#link">Description</h:a></li> <li><h:a href="#metadata" role=":#link">Metadata</h:a></li> </list> </index> </meta> <desc xml:id="description"> <h>Description</h> <p> In an SVG document additional textual information of the image can be provided by the author using the elements title and desc. The metadata element may be used to provide (structured) metadata about the image typically using elements from another namespace. </p> </desc> <s xml:id="metadata"> <h>Metadata</h> <l>Author: Dr. Olaf Hoffmann</l> <l>Date of creation: 2008-02-09</l> <l>Context: http://hoffmann.bplaced.net/svgtext/</l> <l>etc</l> </s> </literature>
The repetition of the title as a heading is only useful, if the title is displayed not directly together with
the other textual content, for example as a window heading in a visual XHTML presentation,
obviously such a repetition is not required or even useful for aural or tactile (braille) presentation.
For aural and tactile representation on the other hand the additional generated navigation after the
title might be helpful, the user can decide faster, which element content is to be presented first.
For screen display such a help may be skipped as less helpful, especially if the content of the
root-desc is short.
Instead of presenting the root-metadata content with an additionally heading and paragraph,
another approach is maybe to separate this in a different way from root-title, root-desc.
Obviously with this approach it is not even a problem, if an author provides more than only exactly one
title and desc pair as direct children of the rootmost svg
element - they can be simply presented as further headings and paragraphs in the same order as arranged in the
document. Only the root-title is derived from the first of those title
elements. Because these elements are not intended to have a specific structure, authors should avoid this
anyway.
title and root-desc
An SVG document with neither a root-title nor a root-desc
can be assumed to be pure decorative, this is not necessarily bad, for example if used only as a CSS
background image (this page for example uses SVG images with simple gradients as backgrounds, they have only an empty
root-title). Authors should use this approach only, if the document has no other function or purpose
at all, this is similar to a situation in (X)HTML with an img with an empty
alt attribute or even worse and wrong without an alt
attribute at all, or with an object without an accessible alternative content inside. All these
variants are meaningless from the view point of information. A user-agent and the audience may assume this
for such a degenerate situation without any further hint from the author to indicate something different.
For an SVG document there is an exception with conditional processing, this will be discussed
later.
Therefore a sufficient content of root-title and root-desc is an important
challenge for authors.
Even typical classical paintings and works of art or text documents have a title. Graphics or figures typically
have a caption, therefore the concept should be well known. The classical function of a title is something
like a short summary. Because for visual presentation the root-title is often displayed as window
heading, therefore the space is limited. However, the content should be characteristic for the
document even if the title is mentioned apart from the image in another context, for example if cited or
referenced with a text link from another document.
Lets assume as an example a portrait of the famous painter Vincent van Gogh. A title like
Vincent might be still sufficient if it is guaranteed that the context is
unambiguously - for example in a compound document XHTML+SVG
or LML+SVG
with some additional text about the painter.
For a standalone document however a title like Vincent van Gogh is already
much more informative. The typical expectation will be, that an image with the title
Vincent van Gogh will provide some visual presentation of this painter.
If it is important, that the image is a portrait, it might be useful to note
Portrait of Vincent van Gogh. Typically the author of the image will be
important too: Portrait of Vincent van Gogh by Dr. Olaf Hoffmann, 2008.
If the author provides more than one portrait of Vincent van Gogh, it might be helpful to
be even more specific: The Cubistic Dark Portrait of Vincent van Gogh by Dr. Olaf Hoffmann, 2008.
This is already pretty detailed. If already too long for example as a window heading, the user-agent may cut
something from the rear part and provide the complete title only in the additional textual presentation
together with a root-desc element.
The author may choose the variant with a shorter title and add more information using the root-desc
element without any specific limits for the length of the content. This approach implies, that typically both
root-title and root-desc are available together, if mentioned in another context.
The role of a desc element has no equivalent in classical paintings and is not exactly the same as the
caption of a figure in an article, but this explains too the content of graphics and different features inside
the graphics. Maybe something similar appears in art catalogues, auction or gallery descriptions. The root-desc
can be considered as something like an abstract or summary of the complete document, maybe including some tips
about the usage in the case of an interactive image.
This indicates already one possible role of the desc, to provide a more comprehensive
summary, a more advanced description of the meaning or role of the image. This advises already, what
the purpose of the desc element or a textual representation not is: A detailed description
about the used elements and their arrangement and styling to achieve the desired visual effect.
The root-title and root-desc provide text information about the meaning
of the image, what or which or whose ideas it represents, not necessarily how this is achieved. However even
this is not excluded, if it helps to understand the content of the image at all, especially without the visual
presentation. If the image is for example interactive, another part of the root-desc might
explain, how to use the image, or might contain suggestions about a typical usage like a collection of tooltips.
Typically superfluous and sometimes annoying are self describing cliches like:
"This image shows ...". It is obvious, that the document is an image and the description
is a part of it, such a cliche may even lead to logical inconsistencies, for example because the
desc gives a description too, the image does not only show something, it describes
at the same time what it shows. Therefore it is much better to describe directly the relevant purpose
or meaning of the image, if an (ostensive) contradiction is not directly intended, see for example
the titles of some of René Magrittes paintings.
For works of art the content of the root-title may be something different than just a short
summary, however this is at least the typical role for technical graphics and images with a purpose
beyond pure arts. For works of art an author may explicitly want to have no title, in this case it is
better to leave the root-title element empty than not to provide a title, because for digital
documents then typically the document name or the
URI of the document is choosen as the
title. For such degenerate cases with an intentionally empty root-title it will be helpful, if the
author adds some note inside the root-desc element explaining that the image has no title.
In some approaches for works of art the relation between the image and its title is more complex than
the role of a summary, see for example works of art from Salvador Dali, Marcel Duchamp, René
Magritte, Yves Klein and many more. For such cases the title is an intrinsic part of the image itself, the
work of art results from the relation of title and image, therefore obviously neither the title nor the
graphical part alone represent the work of art, it needs both and user-agents have to provide both to present
the work of art completely. In such cases typically the root-desc element too may have
a more complex relation to the graphics as just a description or an advanced summary. Anyway authors
should be aware of the possibility, that users-agents without graphical capabilities may only
present the textual content. This may lead to another approach coming from conceptual arts -
the pair of the root-title and root-desc are designed as an alternative
conceptual work of arts, available additionally to the graphical content. This is another reason, why
it is highly desired for any user-agent to provide an additional access to root-title and
root-desc on demand including some information, that this additional content is
available. Authors may prefer too to provide such additional information in an external document,
referencing this for example with an a element. The disadvantage of this
approach is, that the close relation between the two types of content is lost, if they are in two
different documents. Maybe this can be avoided or reduced with a compound document.
Anyway, whatever the approach of the author is, it cannot be expected and it is not required, that the user-agent knows anything about the intentions of the author. The task for the user-agent is in general to provide access to the graphical content and additionally to the textual information of the document, not directly rendered together with the graphics. The author has the responsibility, that both presentations are meaningful. This is a fair split of tasks, the user-agent does, what can be done automatically, the author cares about the creative part with higher intellectual requirements.
In theory it is possible with SVG for a user-agent to explain
any graphical detail to a blind user, because everything is expressed
as XML elements and attributes or CSS or
XSL properties, obviously
this will take a lot of time, until the blind user is able to visualize (?! possible maybe only
for people, who lost visual capabilities, not if they never had such capabilities) or to
understand the graphical content. Therefore an understandable pair of
root-title and -desc will save a lot of time and
frustration, if they already provide the general idea and purpose of the document without
looking into details. This applies too for many other people without any obvious
disabilities, because a combination of graphics with text is in general easier to understand
as only the graphics. On the other hand it should be much easier for authors too to
provide a good description of the complete document in one place as to spread this all
over the document in such a way, that the result is still understandable both with graphical
and non-graphical presentation.
To avoid the impression of too much (gray) theory, here is a real life example: Enlighten Maren. The description here is a mixture and includes conceptual information and the general idea as well as hints about the technical realisation and because it is a script with manipulation possibilities it contains information about the parameters available for manipulation and their effects on presentation.
The second example, Approximation of an Archimedian Spiral Using Bézier Curves has a simple description containing some information about the purpose of the image, it mainly demonstrates problems and constraints of SVG related to such simple paths.
Games or in general interactive animation is a general accessibility problem. Both a practical and simple approach
for a user without the required technical or personal abilities is, not to be frustated and to look for other sources
of pleasure, other authors may provide with other requirements, the user has. However, the author can simply
describe the intended game strategy to provide an idea about the purpose of the document and the simple fact,
that the document represents a game: Shrinking.
In general a description of the game is important for anyone wanting to play the game, because it cannot be
expected, that possible players will find out how it works by trial and error.
As already mentioned, title, desc, metadata
may contain elements from other namespaces. Because SVG provides
no further structure, especially for desc and metadata
the next approach for authors is to use elements from other namespaces to provide a defined
structure. Typically a validator will not be able to test such compound documents anymore,
therefore an author may test the fragments independently before joining them together, if
no validator is available for such a compound document. On the other hand, if the
XML
structure is ok, a user-agent will not interprete content from other namespaces in these
elements as an error, even if the namespace itself is unknown. However the user-agent is
not required to interprete content from another namespace, therefore in such a case a
typical approach of user-agents is to interprete unknown elements as inline elements without
specific presentation requirements, like span in (X)HTML.
If the user-agent uses the first approach above, conserving essentially line breaks inside
the desc element, authors can simply arrange the elements in such a
way, that there still is a graceful fallback and accessible presentation of the content, even
if the markup from the other namespace is not interpretable by a user-agent.
But if a user-agent knows the meaning of the elements from the other namespace and
has rules to present them, this will be a nice improvement of the textual presentation.
For the desc typically XHTML will be a good format
to structure the content or LML to structure the content in a more
advanced way. Trying this, authors should not mix the concept of the first approach,
starting for example with simple text and continuing suddenly later with some text with
XHTML markup. For user-agents for such an undesired mix the simplest
approach will maybe to ignore the additional markup as if the namespace is unknown,
see above. A more advanced approach would be to interprete inline elements as usually
and if there is content without further markup outside of a block element, assume that
this is a paragraph according to the simple first approach. It can be already seen, that the
interpretation of such mixed content of a desc would be ambiguous,
therefore authors are strongly recommended either to use no further markup inside the
desc or to use only other elements from another namespace
as the direct content of a desc element.
For metadata it is in general expected, that it contains only markup
from another namespace, for example
RDF. If the user-agent knows
this format, it should be no problem to present this in a useful way. If the user-agent does
not know, how to present the format, the same applies as for the desc
content. For RDF it could be for example a table containing
subject, predicate, object - or something simplified, if the subject is obviously the
document itself or if tables are too complex for aural or tactile presentation. Something like
a dl list in (X)HTML might be helpful for
predicate - object representations as well.
For RDF a basic visual presentation might be to display all elements
as block elements with the element name before the content. The relation indicated with
the about attribute (if not empty) can be realised with
a combination of a heading and a link.
If in a meta data format the information is not available as content, only as
values of attributes, authors should be aware, that this approach results in not
displaying the metadata content at all, if the format is unknown. In such a case
a user-agent may skip the complete metadata section but may
give a note at least, that not interpretable meta data are available in the document.
For the root-title due to its specific use in some user-agents as a
windows title, including further markup will be typically not a good idea and may
result in difficulties in less advanced user-agents. To avoid this, authors should only
use simple text inside the root-title. On the other hand, the
interpretation of additional markup inside the root-title is the
same as described for desc - either to ignore the tags, if not known
or not applicable and interprete it, if applicable and interpretable.
The second sample provides such an advanced approach. Assuming, that all namespaces can be interpreted somehow the presentation might be similar to that of the following sample as a XHTML document.
Another variant using LML for a similar empty sample is this SVG tiny 1.2 document structured description in metadata:
<?xml version="1.0" encoding="iso-8859-1"?>
<svg width="90%" height="100%" viewBox="0 0 1000 1000"
version="1.2" baseProfile="tiny"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="svg">
<title>Empty SVG Sample</title>
<desc>
How elements from a foreign namespace are used to provide
text alternatives in SVG tiny 1.2.
</desc>
<metadata>
<literature xmlns="http://purl.oclc.org/net/hoffmann/lml/" version="1.0">
<meta>
<ll><link xlink:href="#svg" xlink:type = "simple" xlink:show = "other" xlink:actuate = "other" /></ll>
<rdf:RDF
xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc = "http://purl.org/dc/elements/1.1/" >
<rdf:Description rdf:about="">
<dc:title>Empty SVG Sample</dc:title>
<dc:creator>Dr. Olaf Hoffmann, Hannover, Germany</dc:creator>
<dc:date>2008-02-09</dc:date>
<dc:format>image/svg+xml</dc:format>
<dc:language>en</dc:language>
<dc:relation>http://hoffmann.bplaced.net/svgtext/</dc:relation>
<dc:description>A sample about the usage of title, desc and metadata in SVG including other namespaces.</dc:description>
</rdf:Description>
</rdf:RDF>
</meta>
<s>
<p>In an <abbr>SVG</abbr> document
additional textual information of the image can be provided by the author using
the elements <code>title</code> and <code>desc</code>.
Because in <abbr>SVG</abbr> tiny 1.2 there should only text inside
<code>desc</code>, one has to put structured descriptions inside the metadata
element as meta data to achieve some further substructure with a semantical meaning
and an advanced presentation for the audience. The <code>desc</code> from
<abbr>SVG</abbr> can simply be used for a short summary like an abstract.
</p>
<p>
A possibility to use elements with a semantical meaning is the
<link xlink:href="http://purl.oclc.org/net/hoffmann/lml/"
xlink:type = "simple" xlink:show = "new" xlink:actuate = "onRequest">Literature Markup Language
</link> (<abbr>LML</abbr>) as in this example. Another one could be <abbr>XHTML</abbr>.
</p>
<p>
<abbr>SVG</abbr> tiny 1.2 defines the attribute <code><em>role</em></code>
(the same as defined in <abbr>XHTML2</abbr>) to provide the possibility to add
semantical meaning to <abbr>SVG</abbr> (text) elements too, with a
<acronym>CURIE</acronym> the related element definitions from
<abbr>LML</abbr>, <abbr>XHTML</abbr> or another language can
be used to specify the semantical meaning of graphical rendered text in
<abbr>SVG</abbr>.
</p>
<p>
The <code>metadata</code> element may be used to provide even more structured
metadata about the document itself or fragments of the document, typically using elements from
another namespace like <abbr>RDF</abbr> and the Dublin Core as in this sample.
</p>
<p>
In <abbr>SVG</abbr> 1.1 it is mentioned, that not more than one metadata element
should be provided per element. The simplest solution is to embed these other meta
information in an element for the already used language like the element <code>meta</code>
as shown in this sample.
</p>
</s>
</literature>
</metadata>
<defs>
<!-- some not directly rendered (graphical) content -->
</defs>
<g>
<!-- g element representing the graphical content to be rendered directly -->
</g>
</svg>
LML defines many elements indicating the semantical meaning of texts, even much more detailed than for example XHTML. RDF provides more machine readable meta information, this can be used additionally if required. The following shows an LML equivalent of the sample:
<?xml version="1.0" encoding="iso-8859-1"?> <?xml-stylesheet href="../lml/lmlmetahover.css" type="text/css" title="LML default" ?> <?xml-stylesheet href="../lml/lmlBase.css" type="text/css" title="LML meta off" alternate="yes" ?> <?xml-stylesheet href="../lml/lmlmetastatic.css" type="text/css" title="LML meta on" alternate="yes" ?> <literature version="1.0" xmlns="http://purl.oclc.org/net/hoffmann/lml/" xmlns:xlink="http://www.w3.org/1999/xlink" xml:lang="en"> <meta> <title>Empty SVG Sample</title> <desc> How elements from a foreign namespace are used to provide text alternatives in SVG tiny 1.2. </desc> <s> <h>RDF</h> <hs>rdf:Description rdf:about=""</hs> <l>dc:title: Empty SVG Sample</l> <l>dc:creator: Dr. Olaf Hoffmann, Hannover, Germany</l> <l>dc:date: 2008-02-09</l> <l>dc:format: image/svg+xml</l> <l>dc:language: en</l> <l>dc:relation: http://hoffmann.bplaced.net/svgtext/</l> <l>dc:description: A sample about the usage of title, desc and metadata in SVG including other namespaces.</l> </s> </meta> <s> <p>In an <abbr>SVG</abbr> document additional textual information of the image can be provided by the author using the elements <code>title</code> and <code>desc</code>. Because in <abbr>SVG</abbr> tiny 1.2 there should only text inside <code>desc</code>, one has to put structured descriptions inside the metadata element as meta data to achieve some further substructure with a semantical meaning and an advanced presentation for the audience. The <code>desc</code> from <abbr>SVG</abbr> can simply be used for a short summary like an abstract. </p> <p> A possibility to use elements with a semantical meaning is the <link xlink:href="http://purl.oclc.org/net/hoffmann/lml/" xlink:type = "simple" xlink:show = "new" xlink:actuate = "onRequest">Literature Markup Language </link> (<abbr>LML</abbr>) as in this example. Another one could be <abbr>XHTML</abbr>. </p> <p> <abbr>SVG</abbr> tiny 1.2 defines the attribute <code><em>role</em></code> (the same as defined in <abbr>XHTML2</abbr>) to provide the possibility to add semantical meaning to <abbr>SVG</abbr> (text) elements too, with a <acronym>CURIE</acronym> the related element definitions from <abbr>LML</abbr>, <abbr>XHTML</abbr> or another language can be used to specify the semantical meaning of graphical rendered text in <abbr>SVG</abbr>. </p> <p> The <code>metadata</code> element may be used to provide even more structured metadata about the document itself or fragments of the document, typically using elements from another namespace like <abbr>RDF</abbr> and the Dublin Core as in this sample. </p> <p> In <abbr>SVG</abbr> 1.1 it is mentioned, that not more than one metadata element should be provided per element. The simplest solution is to embed these other meta information in an element for the already used language like the element <code>meta</code> as shown in this sample. </p> </s> </literature>
Again a real world example, just in case someone liked the portrait of Maren above, here is another one:
Maren Lost in Mediation About a Blossom.
The initial paragraph is already more a short story about the situation of the portrait. The audience will
not retrieve any information available in the description just from the graphics. This is just the balancing
injustice of the world. One cannot get everything with just one view ...
The alternative LML variant provides some more semantical markup:
Maren Lost in Mediation About a Blossom (second variant).
A specific notation within the element metadata is used to indicate, that the
attribute class is used to provide semantical information for
elements from the SVG namespace derived from LML, because
the version 1.1 used in the document provides no role attribute themselves.
Another approach could be a compound document. Of course, this changes the relation between the text and
the graphics, in such an approach typically both parts are available at once in one viewport:
Maren Lost in Mediation About a Blossom (compound variant).
But this avoids the general problem of text in SVG, because now the graphics is embedded
in a text environment. In this example the text part represents already the alternative for the graphics, the
title is applicable for the complete document, the title of the svg
contains only the name of the person, the graphic represents,
because the graphics is an intrinsic part of the complete construction.
Sorry just arts, no sports, no games with the second example again:
Cubic Curve Trooping; Type 6 or maybe 6.1.
But did you get the meaning of it? Maybe it is hidden somewhere between the curves and the description. Maybe the
research and approximation is the truth of the life...
Already the title indicates something abstract, maybe from a series of documents or works of arts. Indeed it
presents troops of cubic Bézier curves in an abstract work of art. On the one hand it is pretty hard to
write a sufficient description of an abstract image. On the other hand, one might be creative again to provide
something related. This one is close to a conceptual art variant. This sample is mainly here to encourage
authors to get the head working to produce some descriptions fitting to their thoughts and ideas behind
the image or their philosophy, the image, the art is a part of. It won't be the key of understanding for
the audience, but another chance to get access to it.
Another example for a compound document with a lot of text is the following document consisting of
SVG inside XHTML, a 'proposal' for a new element for
SVG to note objects with discrete rotation symmetries like regular polygons, stars, blossoms and other objects
simpler to describe in polar coordinates than in cartesian coordinates: Polar Element.
Because the XHTML part of the document describes already the graphics in detail, there is no
really need for an additional textual representation of the SVG part. Authors may skip in such a
situation any further description inside the SVG part, where the XHTML part
exactly describes, what the graphics displays. In this example anyway root-title and -desc
are available in a very short form.
Currently SVG tiny 1.2 excludes the usage of elements from other namespaces inside the
desc. In such a case and if authors want to avoid the usage of elements from other namespaces
to structure the text alternative, a nested cascade of g elements including only
title and desc can be used to structure the text alternative already somehow
meaningful. With this approach the root-title is the document title, root-desc
is something like an abstract or summary. Directly behind that an element g can be added
containing only other g, title and desc elements.
Below this g there is another g containing all the graphics.
SVG tiny 1.2 introduces the new attribute role corresponding
to the XHTML role definition.
Predefined values can be CURIEs for example
taken from WAI-ARIA or other resources.
This can be used to specify the semantical purpose of the elements. As already shown, LML
can be used especially for this purpose to provide some more semantical meaning as possible with
WAI-ARIA or XHTML.
The advantage of this approach is, that it is in general possible to provide an access to any semantical structure, the disadvantage is, that the markup gets very complicated, if for example several inline markup elements have to be nested into a paragraph, because it results in a segmentation of the paragraphs in many fragments, in general for each children one segment before and after such inline element and the element itself.
For SVG 1.1 there is only the less specific attribute class available
for this approach instead of role, because there is no specific restriction on the value
of class in SVG 1.1, this causes no further technical problem for authors.
In such a WAI-ARIA approach the outer top g represents the complete text
alternative, therefore the role is #main
or maybe #region to pronounce, that the document has a text region on top and a graphical region below.
The g with the graphical representation can be identified as #region or as another #section
of the document.
Inner g, title and desc can represent quite different things.
#heading or #sectionhead in the case of title.
#section or #description for desc.
#article, #region, #section, #list, #listitem
for g.
If this is not enough, one may reference for example the definitions of (X)HTML elements with
a CURIE, for example for paragraphs the p element.
There are other sources for predefined values, which should be studied, before 'something more creative' is
tried out. But if there is nothing, that really fits, for example there are no semantical elements for poetry currently in
(X)HTML or elements to separate poetry from prose, one maybe has to define own role values
in a separate specification or one may reference even a wikipedia article about the role of the element. However
it cannot be expected, that own specifications or wikipedia articles are widely interpreted, therefore it is much
better to find already existing specifications especially for role values.
This is one of the reasons, why LML was developed, respectively this is one application of
LML it is intended for in contrast to (X)HTML or wikipedia articles.
The first sample is some naive visualisation of quantum mechanics. It is SVG tiny 1.2 and uses
role. Maybe it was not directly intended by the XHTML draft for
role to use for example a CURIE to define the semantical meaning
of an SVG element with a definition of the element p from
HTML4 and it is not directly intended by SVG to use the
g in such a way, however this is at least a meaningful approach to get some
structure and semantical meaning into an SVG tiny 1.2 document only using elements from
SVG and only the meaning from other namespaces. Note, that the indication for
p could be placed at the desc as well.
The structure with one g-p for each desc with the paragraph content is
required, because any element should not have more than one desc. The g cannot contain
the text itself, therefore the only choice is the desc to contain the text for the role.
Quantumbit.
Note that the use of role #img from WAI-ARIA is
somehow suboptimal, because in WAI-ARIA it requires a specific other attribute not available in
SVG, therefore it is not obvious, that the previous #main describes the content of the
#img.
Alternatively LML can be used for the same purpose: Quantumbit
(2. variant), this can be directly transformed:
Quantumbit (LML variant).
The second example is a work of art, containing some a philosophical statement and a description. Clearly
these paragraphs are an intrinsic part of this work of art and not really only a textual alternative to the graphics or
the other way round the graphics is not only a visual alternative to the text. Therefore both are indicated as sections
of the document. And because the paragraphs of the text are really paragraphs and nothing else, they are indicated
as paragraphs using the HTML4 definition:
Construction.
Alternatively LML can be used for the same purpose: Construction
(2. variant), this can be directly transformed:
Construction (LML variant).
Due to limitations in SVG (for example the painters model) and in the
intellectual capabilities of authors one cannot expect in general, that text inside rendered elements
is ordered and choosen in such a way, that the pure presentation of the text according to the
order in the source code will result in something understandable. Therefore it cannot be expected,
that such a display of text content will be useful for an arbitrary SVG document.
But using the elements title, desc inside elements with a
specific and explainable meaning may already help to increase the probability of a useful presentation.
In some cases however already such a simple presentation may be sufficient.
In the SVG tiny 1.2 sample Dream to fly textArea, tspan and tbreak are used to markup a poem. The desc contains a
hint, that the content is directly understandable, even if only as pure text presented. Typically container elements
and graphics elements may be interpreted as block elements, maybe similar to a section element in
XHTML2 or 'HTML5'. An exception is the element tspan,
as already indicated by the name, this is better presented like a span in XHTML
as an inline element and tbreak like br. Content of the element defs is never directly rendered, only if it is
cloned into a rendered part of the document. The example above may be presented like this
'Dream to fly' as a corresponding XHTML document.
The empty graphics element rect is simply ignored, because it is empty and provides no further
information. The container element g and the two elements
tbreak are presented as elements div (with the attribute
class with the value section, because the element
section from XHTML2 or 'HTML5' is not
yet available, for visual rendering a CSS decoration is provided, aural presentation
will be obviously aligned to the meaning of a cascade of chapters, sections, subsection in normal
books.
The alternative approach with the role and a better structure might look like this:
'Dream to fly' with role. It uses tspan
inside textArea to indicate the verse lines and uses RDF to provide the definitions
of poetry content used in the document, because currently there are no related semantical definitions in (X)HTML
or WAI-ARIA. Obviously it is in most cases not effective to have such self-containing definitions.
Typically a language with a predefined meaning like LML can be used:
'Dream to fly' with roles and metadata from
LML. And this is the corresponding representation in LML only:
'Dream to fly' with LML.
The following example shows the usage of LML to indicate the semantics within SVG
and RDF inside metadata to provide machine readable meta information,
desc from SVG is only used to provide a short
description related to the metadata content:
Kaktus und Maus (de).
The largest part of the document can be directly transformed into LML, assuming that
the meaning of RDF and Dublin Core elements is known, this can be transformed too into
LML: Kaktus und Maus (LML) (de).
If RDF and Dublin Core are assumed to be not known, they can be displayed as a section with a list:
Kaktus und Maus (alternative LML Version) (de).
Another unproblematic sample is this poem using textPath - for each strophe line a pair
of text and textPath in the correct order:
Was der Knabe zuhause verschwieg
(de). In this SVG 1.1 sample the class
attribute is used to give more information about the semantical meaning of the content and it shows at the same
time a problem not only in SVG1.1, because there is no specific attribute with predefined values to
describe the semantical function of a text element, one choice for the author is the use of
class with values having a meaning in the language, the document is written.
Obviously an arbitrary user-agent (and its user) cannot profit from this, because the user-agent does not know
anything about the meaning. Therefore the role is introduced in newer versions.
The alternative LML version uses a specific namespace declaration to indicate
class value items beginning with 'lml_' as roles, therefore even SVG1.1
documents following this approach can be marked up unambiguously with semantical meanings. So called
microformats use a similar more ambiguous approach typically for other formats. Note, that for the microformats
approach in SVG it is required, to define the related microformats profile within the
metadata element referencing the applicable profile.
Was der Knabe zuhause verschwieg (2) (de) and
the related text only representation: Was der Knabe zuhause verschwieg (LML) (de).
The next sample, a haiku, uses a similar approach with class attributes, this time in english and
with text only: Frog and Pond. The desc contains
a short discussion including the haiku itself in english and german. But language switches, available too with
SVG will be discussed and used in later sections of this article. Obviously from this document it is
quite simple to produce an LML+SVG compound document with both text and
graphics in one viewport and an LML text only variant automatically.
Frog and Pond (compound document) and Frog and Pond (text only).
The following example shows a typical relation between graphical objects and text, the text is only useful in this relation,
therefore it does not really help, if such text is displayed without the graphical objects. Even more, in this sample the
graphical objects are only path elements, which do not indicate what they represent. However this is not
really a problem, if the root-title and -desc contain the information about the
complete graphics and the relation between graphical elements and text elements.
Experimental Setup: Differential Optical Collisions, Direct Observation of Collision Pairs.
This is a sample from my experiment in atomic physics and a sample for something like a technical drawing too.
The next example is concrete poetry: Entropy. In this case there is no really
problem with the text content in the element text, however without the presentation of
the animation it is quite useless. But in this case, the element desc provides an alternative
approach, some type of concept art, therefore this content is the main source of information. Both for the
author and the audience it is a much easier approach as an alternative approach using title
and desc inside the animation elements. Therefore this strategy for a text alternative
is provided using LML.
In the example Philosophie
(a poem in german again) the text elements represent the strophes or stanzas of the
poem, the strophe lines inside are represented with tspan elements.
This is already the best approach with SVG 1.1 to structure a poem with some kind
of semantical meaning. This approach is aided again with class
attributes with related values. Typically it is useful to interprete tspan as
inline, in this case obviously not. However a user-agent has an indication - the tspan
elements have attributes x and y -
in such a case it is a better interpretation to present such tspan having either
x or y as a block element.
A less sophisticated and more stable approach is to identify strophes as containers for text not as text
itself, then the element g can be used for the strophes and text for
the strophe lines: Philosophie (Variante 2).
Additionally LML can be used again to clarify the semantical meaning:
Philosophie (Variante 3), and the
corresponding text only representation: Philosophie (LML).
This animation test contains some rendered text too - this is pretty
helpful, if rendered together with the graphics and the animation, but provides no useful information
within an only textual presentation. The description is sufficient to understand the test itself, but
obviously it can be only checked, seeing the animation and having a pointing device and the ability
to target a changing object. That rendered text is used as an application hint or as lettering of
some graphics will be often the case and often authors won't be able or willing to provide information
with this without the rendered part of the image. The user-agent on the other hand will not be able
to analyse, if these text information is useful, therefore the audience should be not surprised, if the
resulting presentation is not very useful in such documents. The more important in such a case is
sufficient information in the root-desc.
To see how it works with a graph, I used the program grace to create
a graph with a molecular potential system related to my work. An earlier version 3 or 4 is my
preferred program to visualise experimental and theoretical data for resarch purposes in physics.
The current preview version 6 has an XML format to store the data, this is pretty good,
because it preserves the original raw data (like the older versions too), have a look at it:
the original grace file. grace is able to create an output in several
formats, for example an
EPS: encapsulated post script with grace
or directly SVG with grace. EPS
is the typical format used to embed graphics in LaTeX (a markup language or typesetting system, typically
used to write resarch reports like diploma thesis, doctor thesis, scientific papers).
The program inkscape is for example able to convert EPS
to SVG: EPS to SVG
result with inkscape. The big disadvantage both with EPS and SVG
is, that the original data are lost, because they are transformed from meaningful data to meaningless paths.
In the SVG output from grace I had to fix the styling a little bit, not very much, the graphical
display is ok after the fix. In the SVG output from inkscape the multiplicity of the
molecular states in the lettering is lost (the small numbers top left from the greek glyphs). And if we have
a look in the source code we find no text at all anymore in the inkscape output. grace keeps the text
(this means too, it was easy to fix a typo, not possible with the inkscape output).
However without a root-title and root-desc the graph is surely
not understandable just looking at the text. And as already mentioned, the raw data information is lost
completely. If for example someone wants to use the potentials, they are not accessible anymore,
therefore SVG cannot be used to archive such data in this way. This would require a new
module for example in SVG 1.2 providing a transformation from raw data to
graphical information (see the different scales on the axis, this cannot be useful done with the
usual transform attribute from the current SVG 1.1).
If an author really wants to use such output, it is required to clean up much more and to add
root-title and root-desc to provide something useful. Typically
either the raw data have to be added to the root-desc again or there has to
be a link to a file with the raw data to keep them accessible and usable. Together with some
further clean up the final result including description and title is even smaller than the
original grace output and more than a factor of 11 smaller than the inkscape result:
Optical Collision pump-probe scheme.
title, desc and metadata
in rendered or container elements
title and desc inside other elements than the root svg
element may have different purposes, for example Squiggle/Batik (1.7) displays both, if a pointer is above
the parent rendered elements with a popup window (sometimes called a tooltip). Opera 9ff displays
at least the title of the parent element or if it has no title itself, the
title of the next parent container element is displayed except the root-title.
This means, with these two programs not all title and desc related to
an element are accessible, but already this partial access could be used to provide some help for the
user of the rendered image. title and desc are not intended for
such a usage. This will cause a problem, if authors start to change the contents of title and
desc to 'optimise' them for tooltips. If authors will use this feature for this audience with
a graphical rendering and not only for the audience without a rendered image or only for the text alternative,
this will course a lot of problems for the usability of these elements within the text alternative.
The order and arrangement of these elements is determined by the painters model,
which determines the order of elements in the source code to decide, which element is below and which is on top.
To cover both applications as tooltip and as text alternative is obviously a hard challenge for authors.
For an arbitrary example of such a tooltip 'optimised' document it cannot be expected, that these elements occur in
a useful order for a text only presentation. This is similar to the situation with rendered text elements.
And even worse, it cannot expected anymore, that the content of such elements is related to a title or a
description of the fragment. Often it will be more related to a help for an interactive application.
However, because in some viewers such functionality is already available, users of the alternative text
presentation have to take into account, that such documents with corrupted content for
title and desc may appear.
For a text presentation the achievable approach will be the following:
Authors should always have in mind, that title and desc are
not intended for tooltips, therefore the content of these elements is not that of a tooltip, it is
still a title, respectively a description. A tooltip is maybe a part of a description, but covers
typically not the complete functionality of a desc element.
Authors can use declarative animation to display styled tooltips, this does not interfere with the
functionality of title and desc and has more possibilities.
For a presentation, each element with a descendant having either rendered text or
title or desc is assumed to be a
section, descendants are nested sections or subsections and so on. For a visual or tactile presentation this may
be indicated by an indentation or a margin and a display of the title elements with
a cascade of different sizes similar to the XHTML h? elements.
For aural presentation the following properties may be used to indicate
the title cascade correspondingly to the heading cascade as suggested by the
CSS 2 recommendations as default style for HTML 4:
voice-family, stress, richness, pitch, pitch-range for sections
an indication with cue-before, cue-after, cue, pause-before, pause-after, pause
might be used as proper default styling. Typically it will be helpful as already suggested in the previous
sections to present the complete content area only on demand.
See the example The philosophy of the uncertainty principle of perfection and knowledge
and compare with the related text representation (note that the aural style sheet is
only a rough theoretical guess, because I do not have a tool for aural presentation to check it).
As can be learned already from this simple analoguous wallclock, the rendered
content of an SVG document might not be very useful at all without the rendering and
even if title or desc describe the purpose of each group or
element, this does not always provide the information intended for the complete document, if rendered.
Such a composition is more than the single particles and in this case the animation provides the main
time dependent information by the alignment of some rendered elements.
Therefore root-title and root-desc have to be used to describe
this. But even the root-title provides only a general information, but not that
information, that might be the most interesting for the audience.
Even more, the animated clock itself could be provided as a static file. To derive an approximately
equivalent accessible information in the description requires the use of a server sided script to
determine the current time. This might be even different from the guess of the viewer due to the
local oscillator of the computer used to display the SVG document. And sometimes the
wallclock value is currently not yet supported by the viewer, what is a different problem.
If a connection to the internet is available for the script to catch data from other servers, it might be a
good idea to get the time from another server with a connection (NTP)
to an atomic clock synchronised precisely
to UTC and to set the clock with the script, not with the
wallclock value for begin. Ironically, if the user-agent
does not support wallclock values, here the (wrong) rendered image might even provide
a completely wrong information, but the information inside the root-desc will be
correct but is not up to date, therefore one has to reload the document for an update of the
root-desc. This analoguous wallclock
is simply set by the server (but requires the support of negative offsets for
begin, other variants with begin
0 and with additional transformations are possible too of course). Therefore at the
load of the document both text information and the rendered clock provide the same information
about the UTC as assumed by the server.
If SVG is used for educational, scientific or technical purposes, for example to
illustrate an issue or a context, this will typically combine graphics with text, both explaining each other.
Often the graphics will appear within a larger text, but sometimes it is already sufficient to provide
some basic text information within the graphics, for example if it is assumed, that the general context
is already known or explained in other available and common sources. Typically the author will use
title or desc both for the root svg element,
rendered elements and grouping elements too.
The first example is a simple animation with a double star system.
Classical mechanics and gravitation is already known a long time, therefore such animations are mainly
used to illustrate the timing and the trajectories, already known from theory. Therefore it is sufficient
to provide only the essential parameters of the system. Because there are not only bound systems,
a scattering case is provided too.
And this is an example with more details and interactivity for the graphical display:
Solar System.
Here interactive declarative animation is used to display text information like a tooltip as mentioned above.
But the text information is arranged in such a way in the source code, that it is still quite informative for a
pure text presentation. root-desc
contains a short description about the graphical content, available GET parameters for the
PHP script and a help how to display the additional text information (mouseover an object
to display, click display to remove etc).
SVG1.2 provides different additional possibilities to indicate a tooltip, using the
new common attributes like role, property,
about and content. Because a tooltip
is basically meta information and title or desc have different purposes
than tooltips, the metadata element can be used to provide the tooltip functionality:
shapes with tooltips.
This can be used as a fallback too, if the tooltip is realised with declarative animation, what is the more
advanced and stylable method. And because animation is not optional in SVG, this is
in general the more reliable method. However, both methods can be combined for those viewers with
gaps concering declarative animation: shapes with declarative tooltips.
Another example from my research project in atomic physics: Simplified diagram of an optical collision. The root-desc element contains more details about the collision process, title
elements help to identify what the graphical objects represent. The rendered text is a logo, clicked or activated
it provides some functionality described both in the root-desc and the desc of
the logo. This assumes, that there is the information in the root-desc available for the
user or that of the logo. Additionally this is indicated using the LML method to provide the
semantical meaning including an indication as a 'tip' for the logo.
Obviously the title elements are not very helpful, if the graphical objects are not displayed.
This is indicated with LML as a help.
However the root-desc element contains the
main textual information and explanation about the process, independently from the question, whether only a textual
representation is available or a graphical too.
Several elements can be used to reference external resources, either to link to them or
to embed the external content. For this purpose attributes from XLink
are used, including the typically used prefix, these are: xlink:href,
xlink:title, xlink:show,
xlink:role, xlink:arcrole and
more with only one value (those are typically not explicitely noted). xlink:href
is used to reference an external resource, xlink:title describes the purpose,
the relation between the referencing element and the referenced document (fragment) and may give a hint
to the audience about the referenced document.
To link to another document, the element a
is used: simple link example. If only text is presented, it may be a good idea
for the user-agent to provide an additional help with a collected list of links to external elements. Especially
for aural presentation this may save a lot of time for the user, if mainly interested in the referenced documents:
XHTML equivalent of the simple link example. Obviously
such a helping list is more useful, if the document has a lot of text content. Inside the content area there is
the stronger relation between the link and the children of the a element preserved.
If no xlink:title is available, the name of the referenced file may be used as a resource for
the text representing the link. Note, that the contents of the title elements are quite different
from the values of the xlink:title attributes.
The next example uses links mainly to continue the animation, it demonstrates the behaviour of a Lorenz attractor.
The text representation consists mainly on the description including the differential equation system to describe
this famous attractor. Additionally GET parameters are explained to manipulate the behaviour of the
PHP with a new load. Simple buttons are used as visual representation of the referencing areas.
xlink:title is used to explain the purpose of each referencing link:
Lorenz attractor. This is a simple projection example too. The attractor itself
is three dimensional. Because SVG is two dimensional, after a random alignment of coordinates
the attractor is projected to two dimensions for the graphical output.
A similar example is a Double Pendulum. To pronounce the difference
between the purpose of the links and that of the buttons, the buttons have an additional desc.
Such a strategy is more useful of course in more complex applications. Warning: Once,
when I was a child, I constructed such a double pendulum with wooden slats and ball bearings and some
illumination. This worked really for a few minutes, but due to large forces at some turning points it was destroyed
and several parts of the construction rushed away with a good chance to harm anyone around. Therefore
today I prefer either to simulate this or I mandate a professional workshop to build such experiments in
a stable way ;o)
Above was already mentioned, that for graphs the raw data are lost with the conversion into an SVG
document. With the a element the problem can be reduced in such a way, the audience of the
rendered graphics has still a direct access to the raw data:
providing raw data as external reference. This does not solve the problem,
that the raw data is not archived within the same file, but they can be added additionally to the metadata
element: providing raw data in the metadata.
Obviously an advanced user-agent with RDF capabilities will identify, that the reference
is within the metadata element and will switch automatically to the text only display and
provide the raw data together with the other meta information.
However, this can be easily combined completely within the element a:
providing raw data using data protocol.
Of course, it would be much better, if it would be possible to transform the raw data inside the document into presentable
path data and something like a multiuse element for symbols.
An advanced approach to solve or even to avoid this problems is proposed as an extension or as a new
SVG with RDML.
To embed other images, the element image is used, for SVG tiny it is required to
support the formats PNG and
JPEG. Additionally for SVG 1.1 full
it is required too to support SVG documents itself. If the documents are served by a server,
content negotiation can be used.
SVG tiny 1.2 has requiredFormats for conditional processing
(see below) to check, whether (other) formats are supported or not. If the embedded file itself contains sufficient
and accessible text information, this should be sufficient and this content can be used to provide a text
representation. Typically for raster image formats this is not the case and again a need occurs to provide some
information about the embedded image. The author may use the elements title, desc,
metadata as for other elements for this purpose, additionally the xlink:title
can be used too. While the elements provide information about the purpose and functionality of the referenced
image as a part of the current document, xlink:title may contain information
about the referenced image itself, this can be quite different information.
The root-metadata can be used too, to provide meta information about the embedded
document independently or it can reference the image element, if it has a fragment identifier
(Note that there are maybe problems with fragment identifiers from different namespaces, if
xml:id is not used
(not available/mentioned in SVG 1.1 but in SVG tiny 1.2 already. A way out in
SVG 1.1 might be to note the URI of the document with a fragment identifier,
then it is obvious, that the fragment identifier from the host language SVG is used).
A simple image and a example and
another similar image and a example and the
related text presentation of the simple image and a
example using XHTML.
Authors may use xlink:role and xlink:arcrole to
reference other resources with more information about an image or about that what is shown in an image.
xlink:role is typically more related to the image itself or what it represents
in general, while the target resource of xlink:arcrole is more related to the specific
situation of the link itself, it could reference for example a detailed description of the image, if not already
provided inside the desc, it could describe the purpose or meaning of the link itself (what
is often obvious for simple links as used in SVG).
In this case the xlink:arcrole of each image is very specific, it is an example,
therefore the purpose is not related to xlink:role,
xlink:title, title or desc and contains a
quite different information.
Any user-agent has to provide somehow access to the resources of xlink:role
and xlink:arcrole, if provided by the author. Unfortunately often current
user-agents have not implemented those attributes, therefore the audience has to take into account, that
the information accessible with such a user-agent is incomplete.
User-agents with a graphical display may add this URIs to the alternative text representation
of an SVG document and may provide access to them as well in a content menu.
If no further information or reference to a resource with additional text information related to the embedded
image is provided by the author, the image can be assumed to be completely decorative and without
any importance for the meaning of the purpose of the embedding SVG document.
xlink:role or xlink:arcrole can be used too
for example on animation elements to provide an internal or external reference to an explanation of the
purpose of the animated element and the relation between the animation and the animated element.
Often this will be obvious, therefore this might be only used in very specific cases, where the relation
is not obvious.
In galleries for digital raster images, typically the audience is expected to be able
to view such images, therefore alternative text is typically short. However if the
content can be simply summarised with a heading or description, this will result in a
better access for any audience. For example if only a sufficient document title
is provided, a user may already have a chance to search for some text infomation
about the theme from other resources, without any display of raster images and
without any text information the user will be completely lost.
In my photo gallery (german)
I use a combination of XHTML, SVG and CSS, the gallery is devided in exhibitions about different themes,
exhibitions are provided alternatively in XHTML with different
CSS stylings or in SVG with or without CSS styling. The exhibitions have only a short title indicating
the general theme, other information is more about the usage of the gallery and
the exhibitions itself.
audio, video, animation, foreignObject in SVG tiny 1.2 are more elements to include
external documents, the behaviour is similar to the image element, audio is intended
for audio formats and provides no grapical rendering, video is for video and optional audio formats,
animation is intended for other SVG documents. Except foreignObject
all are timed elements.
Concerning text presentations the possibilities are the same as for image, but for audio
and video no specific format is required to be supported, therefore it is even more important for authors
to use conditional processing (see below) or alternative text content for any user, which has no access to these formats for
whatever reason. foreignObject is already available in SVG 1.1 to embed external
formats as fragments, not as external documents, the last possibility is added in SVG tiny 1.2.
foreignObject is not a timed element and no specific format is required to be supported. For text
presentation the user-agent can analyse and present the content similar to title, desc and
metadata for internal content and similar to image for external content.
In both cases in SVG tiny 1.2 the foreignObject can contain applicable
title, desc and metadata.
For a text representation this is before the content as for other elements too.
This approach is useful for the other elements referencing external content
too and is aligned to the recommended behaviour to have title, desc,
metadata before any other content in the source code to simplify processing for the user-agent.
In SVG it is easy to reuse content. For this purpose already the
doctype declaration can be extended with specific entities, as done for example in
Was der Knabe zuhause verschwieg,
(already discussed above), or Philosophie
to use entities for Umlaute and the ß ligature as in XHTML
(to be independent from the encoding question and from using mysterious numbers),
but this can be used more intensively, if some content is used more often in one
document. For example the document title might be repeated as root-title,
text and maybe again in the metadata - this
could be defined by an entity to provide more flexibility and avoiding errors, if
changes have to be applied to the document.
A simple example is Transition Dipole Moments for Na-CO,
a map like content. The graphics itself has a symmetry axis, therefore only the half graphics
is directly noted, to get the bottom half, the element use clones this
content, which is simply mirrored using transform.
Obviously it is required for a text representation too to interprete the entities. To clone
the reused part too for the text representation, is here neither really important not
should it be a problem.
Lunar centric world view is an example referencing
content from the element defs for technical reasons - it is slightly easier
to understand the required transformations and animations to get the desired effect with
such a structured source code. To present the content a text viewer obviously has to be
able to copy such content on the intended place from the defs, because
it contains some text content too. The recommendations explain in detail, how this cloning
is done - in this case the use is simply replaced with a g
containing the referenced content.
But it might become somehow useless to repeat all text fragments in the same way as the
graphics content, if (text) content is reused many times, to get the
desired effect, as for IFS:
Tree like IFS (the rendering may take a moment
due to the massive reuse of use elements). In such a case it might be useful
to identify the first appearance with a fragment identifier, attribute id,
respectively xml:id and to reference it only at the other
places with links to the fragment identifier.
An example for the use of text content is a
timer with animated use. Especially for the character data
of text there is the element tref to reuse text fragments, this can be used
for the same purpose here:
timer with animated tref. The problem with the timer is
similar to that of the clock above - the main information is provided by a declarative animation,
in this case including interactivity. Without support for interactivity and declarative animation,
such applications get quite useless and authors cannot provide a simple alternative with comparable
accuracy, this could be a real tool someone can use as a timer. For the clock it was sufficient to
use static information from the server to provide a comparable time information.
To send calls to the server to get the application of a timer will not be accurate enough
in many cases, because the internet connection will add additionally, unpredictable
offsets to start and stop of the timer, therefore the accuracy will not be comparable.
And obviously the access to animated text would require, that for the text presentation
the user-agent has to interprete declarative and interactive animation and has at least
to read out the result, when the animation is stopped by the user - not a trivial task
for a traditional screenreader maybe, but not impossible for programmers with some
interest in more tricky things. Typically it cannot be expected, that an animation with
100 glyphs per second can be aurally presented in a useful way - this does not even happen
typically in the graphical rendering and even if this is managed somehow, the human eye will not be
able to analyse such fast changes anymore - only the final display after the timer is stopped.
As done in this case, the authors are encouraged to provide several methods for the interactivity,
not only the use of a pointer device for example. In general, all information is accessible even without
graphical rendering. The animation can be started and stopped in a text only version too - the final
result can be read out, after the animations is stopped. If a text only viewer manages all this, the
important functionality and information is available. Note, that declarative animation and
interactivity are not optional in SVG and authors can in such cases provide an
accessible text only version, if the user-agent is able to interprete declarative animation.
Note, that a use element can have an xlink:title
attribute too. A user agent may provide a simple tooltip with the content of the
xlink:title as a simple possibility for authors to provide a tooltip
about the referenced fragment, as done in the following sample:
used shapes with xlink:title.
Languages are a general accessibility problem for anyone, because there is almost nobody
being able to understand any language. Therefore even if an SVG document
has text, this might be not understandable or the graphics is better understandable than the
text written in a language not known by the audience. With SVG the
author can improve the situation, providing text in different languages, using conditional
processing, especially with the element switch. Other approaches like
content negotiation and similar tricky things are available in general and are not discussed
here, furthermore this is typically only applicable, if the document comes from a server.
If authors want to have everything in one static document, conditional processing is
the method to be used.
Concerning languages SVG has the attribute systemLanguage
with a comma-separated list of language names, for example systemLanguage="de, la, nl, en".
If one tag of the user list fits to one of this list, the related element will be presented. For details
see the recommendations. If such elements with a systemLanguage are direct
children of a switch element, the first with a fitting condition will be presented, the
others not. Authors may use it to have different language variants in one document. However,
currently this method has some restrictions, because the author obviously cannot know, which
language is preferred by the user, therefore the order of direct children of the switch
is a guess of probabilities, what might fit at the best. For example it can be assumed, that many
people are able to understand english as a foreign language, but would prefer to read a document
in their first language (excluding bad computer translations of course). A german author addressing
mainly german and english audience will put the german variant on top and the english variant
below, because it is a good guess, that many germans will have both language tags in their user-agent,
but would prefer the german variant. Obviously native english speakers with german as a foreign language
will see the german variant too, but this will be less people with a suboptimal choice than the author
would have with the english variant on top.
To avoid, that no condition matches at all, the author may skip the systemLanguage
for the last direct children of switch to use this variant as default, if nothing else
fits. Another (better?) approach could be an interactive switch or a separation in two documents and
links to each other.
Within one document, an author can provide alternatively a manual selection using interactive and declarative
animation to display one of several available language variants, basically based on an animation of the
display property. This is similar to the simulation of a paged media.
If more than one element has to be selected, then authors can put the different language variants each
in one g element and all these g elements into the switch.
Because unfortunately in current SVG versions systemLanguage is not
available for any element, especially not for title, desc or
metadata, those elements need an additional container like g or
another switch.
This is especially a problem for the root-title, -desc, -metadata.
If they are inside a g or switch, they are no direct children of the
root-svg anymore.
It is not a good idea, if the author tries to have multiple root-title etc, each with
a switch with systemLanguage , because then
more than one of them can be choosen.
Therefore a specific rule is required to solve this problem. If root-title etc are already
identified, apply no specific rule. Else if a switch is a direct children of the
root-svg and it contains as direct children a g or switch with title, desc or metadata, these are assumed as candidates for
root-title etc, the first of them in the source code with a fitting
systemLanguage is choosen
as the root-title etc.
Note, that related to a discussion about this article, some language switching was introduced in
SVG tiny 1.2 for these critical elements. Therefore in SVG tiny 1.2
it is possible to switch those elements too, if required.
There are other attributes for conditional processing, not directly related to text, see the recommendations.
Especially requiredFormats introduced in SVG tiny 1.2
might be very interesting to optimise the selection of a proper format for image,
audio or video.
A simple example for conditional processing and the corresponding XHTML equivalent in german and the XHTML equivalent in english.
Another example is a two language variant of the Frog and Pond Haiku.
In SVG tiny 1.1 no scripting is available, in other profiles scripting can be supported. But it
is no specific script language required to be supported, additionally the user may have switched scripting
off for several reasons. For authors this means, that it is neither reliable, that a specific script language is supported
nor that it is interpreted, if it is supported. This results in the requirement, that a document provides the same
information with or without script interpretation. If there is no information at all without scripting, the
document contains no information at all. But the author may use scripting to improve understandability or
usability for some user groups, maybe with specific problems or disabilities in this area.
For text presentation this means, for a first approach it cannot be important to provide a possibility to
interprete scripting, especially because it can be considered, that just a minor part of the scripted things in
graphics are related to text content. However it cannot be excluded, that script interpretation may improve
the usability for some user groups for a text representation too.
role attribute