Text in SVG: Some ideas on the usage and presentation of text containing elements in SVG

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. Somthing happend 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. But how this 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 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 CSS is used to shorten the argumentation. It is not expected, that the documents are really transformed into XHTML, this format is only used here, because it has well known and interpreted elements to markup text in a semantical way.

First simple approach

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.

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, obviously such a repetition is not required or even useful for aural presentation. For aural 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. Anyway, because these elements are not intended to have a specific structure, authors should avoid this anyway.

Simple content for root-title and root-desc

A 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 as background, 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 denerate situation without any further hint from the author to indicate something different. For a 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 capture 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 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.

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.

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 too 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 addtionally 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.

First approach samples

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 simply fact, that the document represents a game: Shrinking.

Second approach - more structure

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 cannot interprete content from other namespaces in these elements as an error, even if the namespace itself in 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 (X)HTML will be a good format 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 (X)HTML 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 presentation. Something like a dl list in (X)HTML might be helpful for predicate - object representations as well.

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.

Assuming, that all namespaces can be interpreted somehow the presentation might be similar to that of the following sample as a XHTML document.

Second approach samples

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 ...

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 similar alternative approach for documents with a lot of text are compound documents, for example SVG inside XHTML, as in this example, 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 details, 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.

Rendered content and text - further experimental approaches

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.

Unproblematic rendered text elements samples

In the SVG tiny 1.2 sample Dream to fly textArea 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 be 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.

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 (a poem in german). In this sample the class attribute is used to give even more information about the semantical meaning of the content and it shows at the same time a problem not only in SVG, because there is no specific attribute with predefined values to describe the semantical function of an element, the best 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. The XHTML2 working group works on the role attribute to provide some semantical meaning to elements, maybe this will be reused in future SVG versions too, however this does not help, if there are no predefined meanings for the values. A good approach could be to use element names from XHTML and some more to fill the semantical gaps of XHTML, to get something with a meaning for user-agents in the future.

The third 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.

Problematic rendered text elements samples

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.

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 (variant 2).

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 a hint to use an application 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 visualize experimental and theoretical data for resarch purposes in physics. The current preview version 6 has a 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 orignial 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. 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 and desc 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 not 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 can be pretty useful to provide some help for the user of the rendered image. This means on the other hand, that authors will use this feature for this audience and not only for the audience without a rendered image, therefore the order and arrangement of this 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 is obviously a hard challenge for authors and for an arbitrary example 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. For a text presentation the achievable approach will be the following: 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 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 propper 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 a 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 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 explain 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.
An 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. 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).

External resources and formats

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.

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 button: 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 children, it 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 a 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 additionally in the metadata. However, this can be easily combined: providing raw data using data protocol.

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. The root-metadata can be used too, to provide 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 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, of 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, titleor 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-agenst 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 a SVG document and may provide access to them as will in a content menu.
If no further information or reference to a resource with addtional 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 animation.

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. 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. It is not noted, what happens, if an authors used both internal and external content at the same time for graphical rendering, however for text presentation a user agent may care first about the internal content, then for the external content. The advantage of this approach is to present possible title, desc and metadata before the content. 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.

Reused or cloned content with text

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 to 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 to 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 the graphical rendering, such application 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.

Conditional processing

Languages are a general accessibility problem for anyone, because there is almost nobody being able to understand any language. Therefore even if a 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 it 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 (exluding 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.

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. But there remains a problem for the root-title, -desc, -metadata. If they are inside a 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 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 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. For those specific usage, authors have to avoid the g to group together different elements, because it cannot be expected anymore, that a user-agent is able to identify root-title etc anymore and will assume them as simple title etc of the g and not of the complete document.

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 propper format for image, audio or video.

Scripting

In SVG tiny 1.1 no scripting is available, in other profiles scripting may 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.

Some ideas on the usage and presentation of text containing elements in SVG

From single elements and attributes to a united composition

First simple approach

Simple content for root-`title` and root-`desc`

First approach samples

Second approach - more structure

Second approach samples

Rendered content and text - further experimental approaches

Unproblematic rendered text elements samples

Problematic rendered text elements samples

title and desc in rendered or container elements

External resources and formats

Reused or cloned content with text

Conditional processing

Scripting

References

Author

Some ideas on the usage and presentation of text containing elements in SVG

From single elements and attributes to a united composition

First simple approach

Simple content for root-title and root-desc

First approach samples

Second approach - more structure

Second approach samples

Rendered content and text - further experimental approaches

Unproblematic rendered text elements samples

Problematic rendered text elements samples

title and desc in rendered or container elements

External resources and formats

Reused or cloned content with text

Conditional processing

Scripting

References

Author

Simple content for root-`title` and root-`desc`