SVG/ Barrierefreiheit

Wie alle Auszeichnungssprachen, die vom W3C empfohlen werden, ist auch SVG mit zahlreichen eingebauten Automatismen und Hilfen für den Autor ausgestattet, mit denen die Zugänglichkeit von Dokumenten in diesem Format verbessert wird.

Die eingebauten Automatismen bestehen vor allem darin, dass es sich um ein XML-Format handelt, die Dateien selbst also aus Text bestehen, der mit unspezifischen Werkzeugen lesbar und bearbeitbar ist. SVG ist an sich also Klartext, der ohne spezifische Programme interpretierbar ist. So lässt sich anhand der Namen der verwendeten Elemente und Attribute prinzipiell erkennen, welcher graphische Inhalt repräsentiert wird. So ist es von der Zugänglichkeit her also sinnvoll, statt eines allgemeinen Pfades das Element circle zu verwenden, wenn ein Kreis gemeint ist. Das ist dann auch besser als das semantisch weniger spezifische ellipse oder gar ein rect mit entsprechend abgerundeten Ecken. Entsprechendes gilt für die anderen Basisformen von SVG. Wenn ein gleichseitiges Polygon zu malen ist, ist offenbar auch das Element polygon eine bessere Beschreibung als das Element path, wo die Eigenschaft, dass es sich um ein Polygon handelt, erst mühsam aus dem Wert des Attributes d extrahiert werden muss, was deutlich aufwendiger ist, als dies anhand des Elementnamens zu erkennen. Andersherum ist es nicht so hilfreich, beliebige Kurven mittels polyline oder polygon anzunähern, wenn die tatsächliche Kurve viel besser und effektiver mit kubischen Kurvenfragmenten innerhalb eines path dargestellt werden kann.

Die meisten zu präsentierenden Strukturen werden komplexer als Kreise, Ellipsen oder Rechtecke sein. Wenn sich eine Struktur allerdings aus mehreren Unterstrukturen zusammensetzen lässt, so solche für jede separierbare Unterstruktur auch ein eigenes und dafür passendes Element verwendet werden. Zusammengehörige Elementen sollten dann zudem gruppiert werden. Dies Vorgehen hat gleich mehrere Vorteile. Es ist so leichter zu ermitteln, aus welchen Strukturen ein Objekt besteht. Es ist somit anhand der Dokumentstruktur besser verständlich, wie ein dargestelltes Objekt inhaltlich aufgebaut ist. Einzelne Strukturen lassen sich getrennt viel besser dekorieren, manipulieren oder auch animieren. Gruppen lassen sich gemeinsam transformieren und auch mit einer gemeinsamen Textalternative versehen.

In der Praxis fällt es bei nicht trivialen Dokumenten indes schwer, das beabsichtigte Objekt ohne geeignetes graphisches Darstellungsprogramm zu visualisieren. In anderen Fällen wird einigen Betrachtern die Bedeutung der graphischen Repräsentation nicht klar sein, weswegen diese ebenfalls gerne auf eine Textalternative umschalten werden, welche die graphische Repräsentation ergänzt oder einen anderen Zugang zum Verständnis des Bildes ermöglicht.

Für den Fall, dass ein graphisches Darstellungsprogramm nicht verfügbar ist, aber auch um ergänzende Textinformationen angeben zu können, bietet SVG mit den Elementen title, desc und metadata dem Autor Hilfen an, um praktisch zu jedem Element eine Textalternative oder -ergänzung bereitstellen zu können. Der Inhalt dieser Elemente kann auch durch Elemente aus anderen Namensräumen strukturiert werden, um die Les- und Verstehbarkeit der Textinformation zu verbessern. Elemente aus anderen Namensräumen stellen andererseits aber auch wieder erhöhte Anforderungen an das Darstellungsprogramm, weil dies diese anderen Formate kennen und interpretieren können muss, um die Struktur sinnvoll in der alternativen Betrachtung präsentieren zu können. Ist dies nicht gegeben, muss der Autor nach wie vor mit einer nicht strukturierten Präsentation rechnen. Zudem ist damit zu rechnen, dass Validatoren, die mit Dokumenttypdeklarationen (DTD) arbeiten, solche Dokumente mit gemischten Formaten nicht korrekt validieren können, wenn die Dokumenttypdeklaration nicht entsprechend angepasst wird. Für Darstellungsprogramme ergibt sich indes in der Praxis kein Problem, weil denen die Angabe des Namensraumes reicht, um Formate zu identifizieren. Aufgrund der Beschränkungen der Möglichkeiten von Dokumenttypdeklarationen wird auf diese bei neueren Versionen (SVG tiny 1.2) ohnehin verzichtet.

Im Vergleich mit anderen Formaten, besonders Pixelgraphik, wirkt der Begriff Zugänglichkeit auf den ersten Blick vielleicht etwas befremdlich, was hat denn ein Graphikformat mit Barrierefreiheit zu tun? SVG bietet schon alleine dadurch, dass es ein Vektorgraphikformat ist, einen großen Vorteil: Es ist stufenlos skalierbar. Eine weitere Eigenschaft gibt es umsonst, in einem SVG ist der Text nicht in Form von Pixeln und auch nicht als Kurven gespeichert, sondern in Form von Buchstaben, welche in einem text-Element stehen. Daher kann auch zum Beispiel ein Vorleseprogramm (englisch: screenreader) den Text erkennen und einem Blinden vorlesen. Was hingegen in einer Pixelgraphik dem sehenden Betrachter als Text erscheint, sind eigentlich nur Pixel oder Farbverteilungen, denen ein einfaches Programm keine inhaltliche Bedeutung als Text zuordnen kann, wodurch solche Farbverteilungen in Pixelgraphik Blinden ohne spezielle Programme, die dann versuchen, die Information zu raten, unzugänglich werden.

Auch Verweise sind in SVG problemlos zugänglich und leicht anhand des verwendeten Elementes zu erkennen. Damit diese funktionieren, braucht das Darstellungsprogramme (egal ob für eine visuelle oder sonstige Präsentation) noch nicht mal SVG zu interpretieren. Diese werden angegeben mit der Sprache XLink, einer relativ grundlegenden XML-Funktionalität. Wobei inzwischen allerdings die Interpretation von SVG und XLink in SVG weiter verbreitet zu sein scheint als XLink in beliebigen XML-Dokumenten, man betrachte etwa damit eingebetteten Inhalt in diversen Darstellungsprogrammen - was in SVG problemlos funktioniert, wird in einem beliebigem XML-Format zum Problem für so manches Darstellungsprogramm. XLink selbst wiederum bietet Möglichkeiten zu beschreiben, wozu ein Verweis gut ist oder um was es sich beim Verweisziel handelt, das ist zwar bei vielen Darstellungsprogrammen nicht nachvollziehbar, bietet dem Autor aber ganz unabhängig von den Möglichkeiten der Darstellungsprogramme eine weitere Chance, Inhalt und Funktion von Verweisen und referenzierten und eingebetteten Inhalten zu verdeutlichen.

Aber was ist mit dem Inhalt, der Bedeutung einer Graphik oder einer Anwendung, die auf SVG aufbaut? Es ist sehr wohl möglich, zum Beispiel für Blinde eine Graphik nutzbar zu machen. Ein Vorleseprogramm etwa oder auch ein Darstellungsprogramm mit graphischer Ausgabe kann die Inhalte von Text-Elementen, der Elemente title, desc und metadata in einer alternativen Textdarstellung zugänglich machen, alternativ oder zusätzlich zur graphischen Darstellung der Datei. So ist ein unabhängiger Zugang zur inhaltlichen Bedeutung des Dokumentes jedem Nutzer, insbesondere auch Blinden, verfügbar.

Wie genau die Textalternative zu präsentieren ist, ist in den SVG-Spezifikationen nicht festgelegt und hängt stark davon ab, für wen und in welcher Relation zum graphischen Inhalt die Darstellung erfolgen soll.

SVG bietet ferner die Möglichkeit der bedingten Verarbeitung, der Autor kann also Alternativen angeben, wenn bestimmte Möglichkeiten beim Darstellungsprogramm oder beim Nutzer nicht verfügbar sind, darunter auch eine Selektion von Text in mehreren Sprachen, je nach Einstellung des Nutzers.

SVG tiny 1.2 bietet dem Autor ferner die Chance, mit neuen Attributen Funktion und Bedeutung von Elementen und Konstruktionen anzugeben, einmal um die semantische Qualität des Inhaltes zu verbessern, zum anderen aber auch, um bei Nutzungseinschränkungen die Möglichkeit zu geben, dass das Darstellungsprogramm die angegebene Funktionalität auf einem alternativen Weg bereitstellt.

Jedenfalls wird von den Spezifikationen dringend empfohlen, mindestens das Haupt-svg-Element (root-Element) mit einem title-Element als erstes Kindelement zu versehen. Der Inhalt dieses Elementes wird als Dokumenttitel verwendet - zum Beispiel im Kopfbereich des Darstellungsfensters - und kann auch gut dazu dienen, innerhalb von Textumgebungen auf das Dokument zu verweisen oder es im Textfluss zu bezeichnen.

Titel sind auch bei klassischen Bildern in der Kunst etabliert und finden sich dort oft irgendwo neben dem Bild oder darunter. Bei SVG ist der Titel in das Dokument integriert. Von der historischen Herkunft her ist ein Titel oder eine Überschrift eine Kurzzusammenfassung des Inhaltes, also eine Kurzrepräsentation in Textform oder aber auch ein Bezeichner des gesamten Werkes. Im Bereich der Kunst und Literatur wird dies oft etwas freier gehandhabt und der Titel als inhärenter Bestandteil des Werkes steht manchmal in einer assoziativen Relation zum Inhalt und ist nicht nur eine Kurzzusammenfassung, man denke etwa an Werke von René Magritte oder Salvador Dalí. Der Titel als Bezeichner des Gesamtwerkes ist jedoch durchgehend etabliert, so dass dem Autor zu empfehlen ist, einen ausdrucksstarken und signifikanten Titel zu wählen, der das gesamte Werk gut repräsentiert.

'unbekanntes Dokument' wird zumeist ein schlechter Titel sein, weil er kaum mit dem Inhalt korreliert ist und sich auch kaum als Bezeichner des Werkes eignet. 'Meine Perle' mag für ein Portrait der aktuellen Freundin in einem eindeutig lokalen Umfeld ausreichend sein, ohne weiterem Bezug in beliebigem Zusammenhang aber unzureichend. Besser wäre da etwa: 'Gunilla Schneider; Portrait von Siggi Haase, Hannover 2009'. Dies ist eine recht formale Herangehensweise im Sinne einer Kurzzusammenfassung. Das auf das title-Element folgende desc-Element kann vom Autor genutzt werden, um weitere Zusammenhänge zu erhellen. Etwas künstlerisch kreativer mag Siggi vielleicht auch formulieren: 'Gunillas geheimnisvolles Lächeln in Erwartung ihres Geliebten'. Weitere Angaben schreibt Siggi dann wieder im desc-Element oder maschinenlesbar mit RDF und Dublin-Core im auf das desc-Element folgende Element metadata, indem er ebenfalls notiert, welchen Nutzungsbedingungen das Bild unterliegt.

Bei einem Kunstwerk kann es durchaus erwünscht sein, dem Werk keinen Titel zuzuordnen. Trotzdem ist dringend zu empfehlen, ein title-Element anzugeben, dies dann aber leer zu lassen und auf den Sachverhalt im desc-Element hinzuweisen. Sonst ist es durchaus plausibel, dass sich der Dateiname oder die URI des Dokumentes als Bezeichner etabliert, also vermutlich wird damit genau das Gegenteil von dem erreicht, was eigentlich beabsichtigt war. 'Ohne Titel' als Inhalt des title-Elementes führt wiederum zu einem Widerspruch zwischen Funktion und Inhalt, ist das nicht gerade Bestandteil der Aussage des Kunstwerkes, ist dies dann sicher die falsche Wahl für den Inhalt eines title-Elementes, wenn kein Titel angegeben werden soll. Manche Künstler behelfen sich auch erfolgreich damit, stattdessen eher technische Bezeichner als Titel anzugeben, etwa 'BlaueSerie2009-10-16T12:03:07.3Z'. Das ist als Bezeichner hinreichend signifikant, vermeidet aber weitgehend die gegebenenfalls ungewollte Funktionalität einer Kurzzusammenfassung.

Die Verwendung von title, desc und metadata ist bei praktisch jedem Element möglich und repräsentiert dann entsprechend die Textalternative des jeweiligen Elementes oder der Gruppe von Elementen, die das jeweilige Elternelement umschließt.

Der primäre Zweck insbesondere von title und desc liegt also darin, eine alternative Textrepräsentation für das jeweilige Dokumentfragment bereitzustellen. Einige graphische Darstellungsprogramme stellen diese Information ähnlich dem title-Attribut in (X)HTML als Nutzungshinweis (tooltip) dar, das kann für Autoren insofern irreführend sein, als dass diese insbesondere im title-Element Nutzungshinweise statt einem Titel oder einer Überschrift, einer Textalternative unterbringen. Schlecht ist in dem Zusammenhang etwa ein Titel wie: 'Anklicken oder Aktivieren, um Animation in 3s zu starten'. Das ist ein Nutzungshinweis, kein Titel und gehört zumindest so nicht in das title-Element, kann aber Bestandteil des Inhaltes von desc sein. Besser wäre also ein Titel wie 'Knopf, um das Karussel zu starten' mit einer Beschreibung im desc-Element wie: 'Mit dem Anklicken oder Aktivieren dieses Knopfes wird nach drei Sekunden eine Animation eines Karussels gestartet, fröhliche Kinder drehen sich auf einem Kinderkarussel in die Runde.'

Da die graphische Darstellung und die Zeichenreihenfolge im Malermodell von SVG oft bestimmt, in welcher Reihenfolge Elemente im Dokument angeordnet sind, kann es oft schwierig sein, eine passable Textrepräsentation bereitzustellen, indem man allen oder vielen Elementen title und desc hinzufügt. Oft ist es einfacher, die Beschreibung nur für das gesamte Dokument vorzunehmen oder für größere Fragmente, die einen in sich abgeschlossenen Sinnzusammenhang ergeben. Es wird dann beschrieben, was das Dokument oder das Fragment repräsentiert, weniger wie dies praktisch realisiert ist (was ja ohnehin anhand des Quelltextes analysiert werden kann).

SVG
1.1	1.7 (teilweise, falsch im Sinne von tiny 1.2)	8 (nur Dokumenttitel), 9 (teilweise, falsch im Sinne von tiny 1.2)	4 (Gecko 2.0; teilweise, falsch im Sinne von tiny 1.2)	3.2 (Dokumenttitel; komplett mit weiterem plugin)	-	?	?	?

Nahezu jedes SVG-Element kann ein Element title als Kindelement haben, dies sollte dann immer das erste Kindelement sein. Der Inhalt des title-Elementes ist zumeist einfacher Text. In SVG 1.1 sind auch explizit Elemente aus anderen Namensräumen vorgesehen, was jedoch wegen der bereits oben beschriebenen besonderen Verwendung beim title-Element des Haupt-svg-Elementes nicht zu empfehlen ist. Das Haupt-svg-Element sollte immer ein title-Element haben.

SVG tiny 1.2 empfiehlt explizit, nur einfachen Text als Inhalt zu wählen. Ein Element sollte maximal ein title-Element enthalten. Dieses ist dann der Titel oder eine Kurzzusammenfassung für das Element selbst und seine Kindelemente (insbesondere bei Gruppen). title zusammen mit desc dienen primär dazu, eine Textalternative für den graphischen Inhalt bereitzustellen. Andererseits ist es generell als nicht ausreichend anzusehen, den Inhalt statt des graphischen Inhaltes anzuzeigen, wenn eine graphische Repräsentation durch SVG vorgesehen ist.

Wie Darstellungsprogramme im einzelnen die Textalternative darstellen, ist nicht festgelegt. Jedenfalls ist es Aufgabe des Autors, dafür zu sorgen, dass die Abfolge der Texte und Textalternativen in einem Dokument hinsichtlich der Barrierefreiheit und Zugänglichkeit einen Sinn ergibt, der im wesentlichen einen Ersatz für die graphische Repräsentation darstellt, wenn dem Nutzer eine solche nicht zugänglich ist.

Amaya stellt eine alternative Textrepräsentation etwa in einem anderen Darstellungsbereich dar, wenn der Nutzer dies wünscht. Batik/Squiggle zeigt die komplette XML-Struktur als alternative Textrepräsentation, dies kann beim Konqueror ähnlich eingerichtet werden. Einige Programme blenden manche, aber nicht alle title-Elemente je nach Struktur des Dokumentes auch als Nutzungshilfen ein. Generell ist die strukturierte Darstellung von Textalternativen für SVG-Dokumente in Darstellungsprogrammen nicht einheitlich und ist zumeist noch stark verbesserungswürdig.

In SVG tiny 1.2 ist explizit vorgesehen, dass Darstellungsprogramme mit entsprechenden Fähigkeiten title nur in Form einer Nutzungshilfe (tooltip; wenn mit der Maus, dem Zeigegerät über ein Element mit title gefahren wird, wird dessen Textinhalt an der aktuellen Position präsentiert) darstellen sollen, wenn role="tooltip" angegeben ist. Dies dient vor allem dazu, die Nutzung als Textalternative zu fördern, denn es mag Autoren geben, die eine solche Nutzerhilfe nicht angezeigt haben möchten und ansonsten dann vermutlich eher auf dieses Mittel des barrierefreien Zugangs zum Dokument verzichten, wenn Darstellungsprogramme immer eine solche Anzeige wählen.

SVG
1.1	1.7 (teilweise falsch im Sinne von tiny 1.2)	-	-	3.2 (mit weiterem plugin)	-	?	?	?

Nahezu jedes SVG-Element kann ein Element desc als Kindelement haben. Dies sollte dann, soweit vorhanden, nach dem Element title das zweite Kindelement sein. Der Inhalt des desc-Elementes ist zumeist einfacher Text, der eine Beschreibung dessen darstellt, was das Element oder die Gruppe repräsentiert oder welche Funktionalität diese im Gesamtdokument haben oder aufweisen. In SVG 1.1 sind als Inhalt auch explizit Elemente aus anderen Namensräumen vorgesehen. Etwa könnte man das Element p von XHTML verwenden, um die Beschreibung mit Absätzen zu strukturieren. Auch andere Elemente von XHTML oder anderen Formaten können helfen, die semantische Struktur des Inhaltes auszuzeichnen. Dies ist insofern hilfreich, als SVG selbst keine Elemente bereitstellt, um den Inhalt zu strukturieren oder Texte semantisch relevant auszuzeichnen.

SVG tiny 1.2 empfiehlt explizit, nur einfachen Text als Inhalt zu wählen. Ein Element sollte maximal ein desc-Element enthalten. In SVG tiny 1.2 ist also an sich keine weitere Strukturierung des Inhaltes von desc mit Elementen aus anderen Namensräumen wie XHTML vorgesehen. Ist eine strukturierte Beschreibung dennoch notwendig oder gewünscht, bleibt noch die Möglichkeit, innerhalb des Elementes metadata eine entsprechende strukturierte Beschreibung neben anderen Metainformationen unterzubringen. Die Hinweise bezüglich des Attributes role="tooltip" für title gelten entsprechend.

SVG
1.1	-	-	-	3.2 (mit weiterem plugin)	-	?	?	?

Nahezu jedes SVG-Element kann ein Element metadata als Kindelement haben. Dies sollte dann, soweit vorhanden, nach den Elementen title und desc das dritte Kindelement sein. Der Inhalt ist Metainformation, ausgezeichnet mit Elementen aus einem anderen Namensraum als SVG, zum Beispiel RDF. Sofern in der verwendeten Sprache vorgesehen, empfiehlt sich explizit anzugeben, ob sich die Metainformation auf das gesamte Dokument bezieht oder nur auf ein bestimmtes Fragment. RDF hat eine entsprechende Funktionalität mit dem Attribut about, dessen Wert dann der Fragmentidentifizierer (Wert des Attributes id mit vorangestellten #) des Elementes ist, auf welches sich die Metainformation beziehen soll. Mittels zum Beispiel RDF und Dublin Core lassen sich so (maschinenlesbar) Angaben zu Autor, Erstellungsdatum, Pubklikationsdatum, Nutzungsbedingungen und vielen weitere Metainformationen strukturiert unterbringen.

W3C Referenz

Einfaches Beispiel für SVG tiny 1.1, ohne Verwendung von Elementen aus anderen Namensräumen, so auch vom W3C-Validator erfolgreich testbar:

<?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"
  xml:lang="de">
<title>Nahezu leeres SVG-Beispiel</title> 
<desc>
In einem SVG-Dokument kann alternative oder zusätzliche
Textinformation vom Autor angeboten werden, wobei die
Elemente title und desc verwendet werden.

Das Element metadata kann verwendet werden, um strukturierte
Metadaten oder Metainformation über das Dokument anzugeben,
typisch mit Elementen aus einem anderen Namensraum.

Dies Dokument ist ein Beispiel für die Verwendung von
title, desc und metadata in einem ansonsten nahezu leeren
Dokument.
</desc> 

<metadata>
<!-- Einige Metainformationen, 
zum Beispiel mit RDF und Dublin-Core verwendend,
hier untypisch, aber für den W3C-Validator 
in Ordnung als Klartext angegeben.
Man kann allerdings nicht erwarten, 
dass solche Klartextangaben 
maschinenlesbar sind.  -->
Autor: 
Siggi Haase
Entstehungsdatum: 
2009-10-19
Kontext: 
http://de.wikibooks.org/wiki/SVG/_Barrierefreiheit
etc
</metadata>

<defs>
<!-- nicht direkt dargestellte Elemente, 
bereitgestellt zur späteren Verwendung,
auch Animationselemente kann man hier unterbringen, 
um Ordnung und Übersicht zu schaffen ...  -->
</defs>

<g>
<!--  Ein Element g repräsentiert 
      den restlichen, graphischen Inhalt.  -->
</g>

</svg>

Beispiel eines Dokumentes mit Elementen aus anderen Namensräumen:

<?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="100%" height="100%" viewBox="0 0 1000 1600"
  xmlns="http://www.w3.org/2000/svg"
  version="1.1" baseProfile="tiny"
  xml:lang="de">
<title>Gunillas geheimnisvolles Lächeln in Erwartung ihres Geliebten</title>

<desc>
<!-- Beschreibung mit Elementen aus dem Namensraum von XHTML -->
<div xmnls="http://www.w3.org/1999/xhtml">
<p>
<em>Gunilla</em> sitzt vor einem Spiegel und hat ihr gelocktes, 
rotes Haar gelöst, welches wallend über ihre nackten Schultern fällt. 
Verträumt fährt sie sich mit einem Kamm durch die glänzenden Locken, 
die sie so sehr <em>liebt</em>.
</p>
<p>
Ihre vollen Lippen hat Gunilla leicht lächelnd geöffnet 
und summt leise ein Lied von der Liebe zu ihrem 
<strong><em>Siggi</em></strong>, welchen sie bereits 
sehnsüchtig <strong>erwartet</strong>.
</p>
<p>
Herrlich ist das Licht- und Schattenspiel der Sonnenstrahlen 
auf der zarten Haut ihres Antlitzes mit den vielen prachtvollen 
Sommersprossen.<br />
Je nach Lichteinfall erscheinen ihre Augen grau, grün oder blau, 
<strong>eine spannende</strong> Mischung.
</p>
<p>
Eine erste kühle Brise fährt durch ihr Haar und kündet 
von der herannahenden <strong>Sommernacht</strong> und 
läßt Gunilla leicht erschauern ...
</p>
</div>
</desc>

<metadata>
<!-- Metainformationen mit RDF und Dublin-Core -->
<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>Gunillas geheimnisvolles Lächeln in Erwartung ihres Geliebten</dc:title>
   <dc:creator>Siggi Haase, Hannover (Linden), Deutschland</dc:creator>
   <dc:created>2009-10-01/10</dc:created>
   <dc:format>image/svg+xml</dc:format>
   <dc:language>de</dc:language>
   <dc:relation>http://de.wikibooks.org/wiki/SVG/_Barrierefreiheit</dc:relation>
   <dc:description>Gunilla Schneider; 
     Portrait vor einem Spiegel beim Haarekämmen.</dc:description>
   <dc:rights>Die Urheber- und Veröffentlichungsrechte liegen beim Autor 
     Siggi Haase aus Hannover.
     Die abgebildete Person Gunilla Schneider aus Hannover 
     hat einer Veröffentlichung zugestimmt und überläßt 
     Siggi Haase Entscheidungen über weitere Veröffentlichungen.
     Zum persönlichen Gebrauch und zur Verwendung für pädagogische Zwecke, 
     etwa in Schulen und Universitäten, 
     darf das Dokument ohne Nachfrage vervielfältigt werden.
   </dc:rights>
 </rdf:Description>
</rdf:RDF>
</metadata>

<defs>
<!-- nicht direkt dargestellte Elemente ...  -->
</defs>

<g>
<!--  Ein Element g repräsentiert den restlichen, graphischen Inhalt.  -->
</g>

</svg>

SVG
1.1	1.7 (teilweise)	8 (teilweise)	3 (teilweise)	-	4 (teilweise)	?	?	?

Mit dem Element switch und speziellen Attributen ist es möglich, die Verarbeitung oder Darstellung abhängig von bestimmten Bedingungen zu machen. Die in SVG 1.1 dazu verfügbaren Attribute sind requiredFeatures, requiredExtensions and systemLanguage. SVG tiny 1.2 bietet zwei weitere Attribute zur bedingten Verarbeitung an, requiredFormats und requiredFonts.

Diese können als Attribut bei einem Element angegeben werden, bei dem eine bedingte Verarbeitung durchgeführt werden soll. Nur wenn die durch das Attribut angegebene Bedingung wahr ist, wird das Element verarbeitet oder angezeigt.

Mit dem Attribut wird angegeben, für welche Sprachen des Nutzers der Inhalt des Elementes geeignet ist, bei dem das Attribut notiert ist. Der Wert von systemLanguage ist eine kommaseparierte Liste von Länderkennungen wie "de" oder "en" oder auch "en-gb", und der Wert ist wahr, wenn der Nutzer im Darstellungsprogramm angegeben hat, dass er Inhalte in wenigstens einer der angegebenen Sprachen verstehen kann.

Mit dem Attribut wird angegeben, welche Erweiterungen zur Anzeige des Elementes notwendig sind, bei dem das Attribut notiert ist. Der Wert von requiredExtensions ist eine leerraumseparierte Liste von URIs, die eine notwendige Erweiterung identifizieren. Alle angegebenen Erweiterungen müssen interpretiert werden, damit der Wert wahr ist.

Das Attribut dient vor allem als Hilfe für Darstellungsprogramme, welche SVG bislang nur unvollständig implementiert haben. Durch Angabe von notwendigen Funktionalitäten kann der Autor so die Darstellung von den bereits implementierten Fähigkeiten des Darstellungsprogrammes abhängig machen. Der Wert von requiredFeatures ist eine leerraumseparierte Liste von Zeichenketten, sogenannten 'feature strings', die in der jeweiligen SVG-Spezifikation genau angegeben sind und Teile oder Module der Spezifikation bezeichnen. Wenn alle angegeben Module vom Darstellungsprogramm interpretiert werden, ist der Wert wahr.

• 1.1 'feature strings'
• 1.2 'feature strings'

Mit dem Attribut wird angegeben, welche weiteren Formate zur Anzeige des Inhaltes eines Elementes notwendig sind, bei dem das Attribut notiert ist. Der Wert von requiredFormats ist eine leerzeichenseparierte Liste von internet-Medientypen (Inhaltstypen, ehemals MIME-Typen). Der Wert ist wahr, wenn alle angegebene Typen interpretiert werden.

Mit dem Attribut wird angegeben, welche weiteren Schriftarten oder Zeichensätze zur Anzeige des Inhaltes eines Elementes notwendig sind, bei dem das Attribut notiert ist. Entsprechend ist der Wert von requiredFonts eine Liste von Schriftarten im Sinne der Eigenschaft font-family. Der Wert ist wahr, wenn alle angegebenen Schrifttypen verfügbar sind.

Im Element switch können nun Kindelemente angegeben werden (besonders g bietet sich da an), von denen nur das erste dargestellt wird, bei dem die bedingte Verarbeitung wahr ist, die anderen werden nicht verarbeitet oder dargestellt. Das ermöglicht also, Alternativen anzubieten, wenn bestimmte Module nicht verfügbar sind oder wenn man mehrere Sprachen in einem Dokument angeben möchte. In der Regel ist es vorteilhaft, das letzte Kindelement von switch ohne ein Attribut zur bedingten Verarbeitung anzugeben, dann wird dieses in jedem Falle dargestellt, wenn alle vorherigen Kindelemente nicht verarbeitet werden.

Aufgrund der einfachen Syntax sind besonders bei der Sprachauswahl die Möglichkeiten des Autors begrenzt. Hat etwa ein hauptsächlich deutschsprachiger Nutzer die Länderkennungen "de" und "en" angegeben, möchte aber bevorzugt deutsch lesen, ein anderer mag hauptsächlich englischsprachig sein, täte aber auch notfalls deutsch verstehen, so hat er die gleichen Kennungen angegeben (mit anderen Gewichtungen). Dies ist vom Autor nicht berücksichtigbar, was auch immer zuerst im switch drinsteht, wird verarbeitet, deutsch oder englisch. Es kann also sinnvoll sein, dem Nutzer eine manuelle Auswahl zusätzlich oder alternativ anzubieten oder die Möglichkeiten der sogenannten 'content-negotiation' von Webservern zu nutzen, um zwischen Darstellungsprogramm und Webserver auszuhandeln, welche Sprachversion bevorzugt ist.

Eine nähere Beschreibung ist jeweils im Dokument als Textalternative vorhanden.

• Bedingte Ausführung und Erweiterungen (switch und requiredExtensions)
• Bedingte Ausführung und Sprachauswahl (systemLanguage, aber in diesem Beispiel einmal ohne switch)
• Bedingte Ausführung und notwendige Merkmale (switch und requiredFeatures)
• Bedingte Ausführung und notwendige Formate (switch und requiredFormats; SVG tiny 1.2)

SVG
1.1	-	9 (nur title)	3 (nur title)	-	4 (nur title)	?	?	?

Elemente, für die in SVG eine XLink-Funktionalität angegeben ist, können eine Reihe von Attributen aus dem Namensraum von XLink aufweisen, welche die eingebauten Zugänglichkeitshilfen von XLink bereitstellen. Es soll hier wie üblich für XLink-Attribute das Präfix xlink verwendet werden. Typische solche Elemente sind a, image, use oder Animationselemente wie animate, in SVG tiny 1.2 auch Elemente wie audio, video, animation oder foreignObject. Die XLink-Funktionalität ist kurz gesagt bei jenen Elementen gegeben, in denen das Attribut xlink:href von XLink zu verwenden ist, um auf andere Dokumente oder Dokumentfragmente zu verweisen oder solche einzubetten. Bei anderen Elementen, wo dies nicht explizit definiert ist, finden auch die anderen Attribute von XLink keine Anwendung. Neben diesem Kernattribut von XLink können weitere angegeben werden, um die Zugänglichkeit des Verweises zu verbessern.

xlink:title mit einer Zeichenkette als Attributwert kann analog zum title-Attribut von (X)HTML genutzt werden, um dem Verweis einen Titel zu geben oder auch einen Nutzungshinweis. Nachvollziehbar ist das zum Beispiel mit Gecko von Mozilla oder – sofern das nicht mit der Anzeige von anderen Nutzungshinweisen in Konflikt steht – auch mit Opera.

Mittels xlink:role kann auf eine URI verwiesen werden, wo die Rolle oder Funktion des Verweiszieles beschrieben wird. Der Attributwert ist daher also die URI eines Dokumentes oder Dokumentfragmentes, in dem die Rolle oder Funktion des Verweiszieles beschrieben wird.

Mittels xlink:arcrole kann auf eine URI verwiesen werden, wo die Rolle oder Funktion des Verweises selbst beschrieben wird. Der Attributwert ist daher also die URI eines Dokumentes oder Dokumentfragmentes, in dem die Rolle oder Funktion des Verweises beschrieben wird. Die Funktion des Verweises ist allerdings in der Regel bereits in SVG durch die Elementdefinition gegeben, die Verwendung ist also allenfalls sinnvoll, wenn darüber hinaus eine besonders bemerkenswerte Funktion vorliegt.

Ein Kreis wird verwendet, um mittels des Elementes a auf die deutsche wikipedia-Seite zu verweisen. Das Verweisziel wird gegebenenfalls in einem neuen Fenster geöffnet (weil xlink:show="new" angegeben ist, alternativ könnte auch target="_blank" analog zu (X)HTML transitional angegeben werden):

<a
xlink:href="http://de.wikipedia.org"
xlink:title="wikipedia in einem neuen Fenster aufrufen"
xlink:show="new">
<circle r="100" fill="#ccf" stroke="#00f" stroke-width="10" />
</a>

Wenn die Darstellung eines Bildes nicht das primäre Einsatzziel eines image-Elementes ist, sondern zum Beispiel in einer Anleitung zur Erstellung von SVG-Dokumenten nur als Beispiel dient, kann es durchaus sinnvoll sein, diese zusätzliche Funktion mittels xlink:arcrole anzugeben. Statt das Hauptmotiv des Bildes im Detail zu erläutern, kann es zum Beispiel für einen blinden Nutzer auch hilfreich sein, mittels xlink:role einen Verweis auf einen Fachartikel angeboten zu bekommen, wo im Detail nachgelesen werden kann, um was es sich genau handelt. Konkretes Beispiel:

<image width="300" height="200"
xlink:href="Zitronenfalter.jpg"
xlink:title="Zitronenfalter auf Sommerflieder"
xlink:role="http://de.wikipedia.org/wiki/Zitronenfalter"
xlink:arcrole="http://de.wikipedia.org/wiki/Beispiel">
<title>Zitronenfalter</title>
<desc>
Ein Zitronenfalter sitzt mit ausgebreiteten Flügeln
auf einem Sommerflieder und saugt Nektar.
Der Hintergrund des Bildes löst sich in diffusem Grün auf.

Beispiel für die Verwendung eines image-Elementes in SVG.
</desc>
</image>

Entsprechend bietet sich manchmal eine ähnliche Vorgehensweise beim Element use an:

<g stroke-width="10" stroke="#00f">
<use id="Start" x="100" y="100" fill="#0a0"
xlink:href="#Knopf"
xlink:title="Stoppuhr starten"
xlink:role="http://www.w3.org/TR/wai-aria/#button" />

<use id="Stop" x="100" y="200" fill="#c00"
xlink:href="#Knopf"
xlink:title="Stoppuhr stoppen"
xlink:role="http://www.w3.org/TR/wai-aria/#button" />
</g>

Um die Rolle oder Funktion eines jeden Elementes, nicht nur aber auch mit Bezug auf WAI-ARIA angeben zu können, bietet indes SVG-tiny 1.2 auch noch das Attribut role.

In SVG tiny 1.1 sind weder Stilvorlagen noch Skripte zu interpretieren, in SVG tiny 1.2 ist die Interpretation von Stilvorlagen und von Skripten optional - und die Spezifikation legt nicht fest, welche Skriptsprache zu verwenden ist, wenn eine verwendet wird. Dies ist auch in SVG 1.1 nicht vorgeschrieben, anders etwa als die Interpretation der Bildformate PNG und JFIF/JPEG, die nicht optional sind, ebenso wenig wie die Interpretation von CSS, so weit es für SVG spezifiziert ist.

Verwendet ein Betrachter nun ein Darstellungsprogramm, welches auf SVG tiny 1.1 ausgelegt ist, kann der Autor eine Interpretation von Stilvorlagen und Skripten nicht erwarten, auch bei SVG tiny 1.2 ist das fraglich, allerdings nicht mehr explizit ausgeschlossen. Bei SVG 1.1 und SVG tiny 1.2 ist immerhin unsicher, ob und welche Skriptsprache vom Darstellungsprogramm interpretiert wird. Zudem kann bei den allermeisten Programmen der Nutzer die Skriptinterpretation deaktivieren - aus Gründen der Sicherheit oder der Weltanschauung, warum auch immer.

Bei SVG tiny 1.2 kann immerhin mittels requiredFormats abgefragt werden, ob die Interpretation einer bestimmten Skriptsprache gegeben ist. Allgemeiner kann auch mit requiredFeatures abgefragt werden, ob generell eine Interpretation von Skriptsprachen möglich ist (die Antwort zum Beispiel von Opera ist falsch, das Programm behauptet (Stand Mitte 2011, getestet bis Version 11.10) immer, es könne Skripte, insbesondere ecmaScript und JavaScript interpretieren, selbst wenn der Nutzer dies explizit deaktiviert hat und somit auch keine Interpretation in SVG erfolgt).

Zusammenfassend kann also festgehalten werden, dass Stilvorlagen und Skripte ein Zugänglichkeitsproblem für bestimmte Nutzergruppen darstellen können, andererseits für andere aber auch wiederum Hilfen, den Inhalt besser zu verstehen. An der Stelle ist der Autor eines Dokumentes gefragt, diese Methoden so einzusetzen, dass gerade auch ohne deren Interpretation dennoch der Inhalt, die Information des Dokumentes verfügbar und zugänglich ist.

Hinsichtlich der Dekoration mit Stilvorlagen ist die Lösung gleich in SVG eingebaut. Bis auf sehr wenige Ausnahmen (von Eigenschaften, die mehrere verschiedene Eigenschaften zusammenfassen), gibt es für in SVG verfügbare CSS-Eigenschaften Präsentationsattribute, die dann auch verwendet werden sollten, sofern die Eigenschaft zum Informationsgehalt des Bildes beiträgt. Ist es zum Beispiel für das inhaltliche Verständnis relevant, dass ein Rechteck nicht schwarz, sondern rot ist, so wird die Farbe mit einem Präsentationsattribut angegeben. Zudem kann es sinnvoll sein zu prüfen, ob noch eine sinnvolle Anzeige zustande kommt, wenn eine Konversion der Farben in Grauwerte vorgenommen wird, was oft beim Drucken passiert, aber auch bei Grauwert-Monitoren oder anderen Hilfen für Menschen, die spezifische Probleme in der Farbwahrnehmung haben.

Präsentationsattribute sind in (X)HTML weitgehend verpönt, weil sie dort praktisch nur dekorativen Zwecken dienen, nicht inhaltlichen. Das ist bei Graphik ganz anders. Wenn dort alle Elemente schwarz gefüllt sind, ist keine Information mehr erkennbar, also haben Farben und Teiltransparenzen etc meist eine wichtige inhaltliche Funktion, die durch Einsatz von Präsentationsattributen zu gewährleisten ist. Eine andere, alternative Darstellung kann allerdings problemlos mit der Angabe von CSS-Eigenschaften ergänzt werden. Die CSS-Angaben haben eine höhere Spezifität als die Angaben in Präsentationsattributen, überschreiben diese also gegebenenfalls.

Verwendet man bestimmte Hilfsprogramme (wie zum Beispiel inkscape), so ist es nicht unwahrscheinlich, dass inhaltlich wichtige Angaben nicht in Präsentationsattributen abgelegt werden, sondern als Eigenschaften im Attribut style. Um den Zugang zum relevanten Inhalt zu optimieren, sind dann gegebenenfalls manuell Präsentationsattribute zu ergänzen oder die Angaben in style in Präsentationsattribute zu konvertieren, um besser zugängliche Information anzubieten.

Bei Skripten ist die Lösung meist weniger einfach. Generell sollte der Autor immer im Kopf behalten, dass das, was ohne Skriptinterpretation als Inhalt zugänglich ist, der Inhalt, die Aussage seines Dokumentes ist. Die Anwendung von Skripten fügt an sich keine weitere Information hinzu, bietet allenfalls einen alternativen Zugang zum ohnehin vorhandenen Inhalt. Wenn es für den Autor so aussieht, dass dieses Kriterium nicht erfüllt ist, kann er ohne Zweifel davon ausgehen, dass sein Dokument nicht barrierefrei und für alle Nutzer zugänglich ist. Solange nur ein definierter Nutzerkreis mit bekannten Möglichkeiten vorliegt, muss das kein Problem darstellen. Wenn sichergestellt ist, dass jedem, dem das Dokument zugänglich ist, auch der Inhalt wie geplant zugänglich ist, tritt kein Barriereproblem auf. Sobald das Dokument aber allgemein verfügbar veröffentlicht ist, tritt spätestens das Problem der mangelnden Zugänglichkeit auf. Es obliegt dann dem an Zugänglichkeit und Barrierefreiheit interessierten Autor (kann bei einigen gesetzlich vorgeschrieben sein, dass sie interessiert sein müssen), das Dokument so aufzubereiten, dass es zugänglich ist. Oder er muss notfalls Alternativen bereitstellen, die die Information zugänglich werden lassen.

SVG
1.2 tiny	-	-	-	-	-	?	?	?

SVG tiny 1.2 bietet einige Attribute, die von XHTML und RDFa übernommen wurden, um die Zugänglichkeit und semantische Aussagekraft und die Maschinenlesbarkeit und -verstehbarkeit zu verbessern.

Ein Problem nicht nur von SVG ist etwa, dass die Funktion für den Benutzer von komplizierteren Konstruktionen für die darstellenden Programme nicht erkennbar ist. Ist der Nutzer etwa selbst oder durch Mängel des Programmes in der Rezeption eines Dokumentes wie vom Autor gedacht beeinträchtigt, so kann mit WAI-ARIA oder mit anderen Spezifikationen die Funktionalität einheitlich beschrieben werden, so dass Programmierer für die Funktionalitäten im Darstellungsprogramm generische Konstrukte bereitstellen können, welche bei solchen Beeinträchtigungen die Konstrukte des Autors ersetzen können und damit auch die generelle Funktionalität bereitstellen können. Zu diesem Zwecke gibt es das Attribut role, mit dem eine solche Funktionalität wie ein Knopf (button) oder Nutzungshinweis (tooltip) angegeben werden können, Die Basiswerte sind in WAI-ARIA definiert, aber Interessierte können darüber hinaus auch eigene Funktionalitäten spezifizieren, wobei der Attributwert dann eine CURIE ist, eine spezielle Methode, um URIs abzukürzen, die auf die Definition der Funktionalität verweisen. Da sowohl WAI-ARIA als auch die Spezifikation einer CURIE noch Arbeitsentwürfe waren, als SVG tiny 1.2 als Empfehlung veröffentlich wurde, ist der Attributwert noch nicht normativ auf die genannte Syntax einschränkt. Für die Funktionalität und Sinnhaftigkeit der Verwendung ist aber davon abzuraten, eigene Wege zu gehen. Sofern die verwendete Sprache selbst über generische Konstrukte verfügt, ist es natürlich besser, diese zu verwenden, statt etwa über teils unzugängliches Skripte ein an sich nicht dafür gedachtes Element mit der Funktionalität zu dekorieren und dann die Funktionalität nur mittels role kenntlich zu machen.

Nun ist es auch zwangsläufig so, dass nicht für alles, was mit SVG darstellbar ist, auch ein spezifisches Element vorhanden ist, es ist etwa nicht zu erwarten, dass für eine schlafende Katze oder einen afrikanischen Elefanten in einer Stampede ein passendes Element definiert wird.

RDFa bietet die Möglichkeit, zumindest für häufig auftretende Anwendungen andere Spezifikationen zu referenzieren, um die Bedeutung von eher generischen Elementen zu präzisieren. Insbesondere bei Textinhalten können sogar maschinenlesbare und -verstehbare Notationen von Textstrukturen angegeben werden, wofür es bereits zahlreiche spezielle Vokabularien gibt. SVG hingegen spezifiziert bei Textelementen nur, wie diese graphisch darzustellen sind, nicht was sie bedeuten (Überschrift, Abschnitt, Absatz, Liste etc). Zum Beispiel können dafür Elemente von (X)HTML referenziert werden oder auch Elemente aus anderen Sprachen mit besserer Semantik wie LML.

RDFa ist die Attributversion von RDF, benutzt also das gleiche Prinzip von Tripeln - Subjekt, Prädikat, Objekt. RDFa ist so konstruiert, dass in der Regel das Tripel automatisch aus der Dokumentstruktur und den verwendeten Attributen folgt. Wie bei role werden auch hier CURIEs verwendet, um die exakte Bedeutung aus anderen Spezifikationen zu referenzieren. Somit sind auch diese Attributwerte in SVG tiny 1.2 noch nicht normativ eingeschränkt, eine Abweichung von den RDFa-Vorgaben führt aber zu keinem semantisch sinnvollen und eindeutigen Ergebnis. Die Attribute sind im Detail in der Spezifikation von XHTML+RDFa definiert.

Details zur Interpretation sind dem entsprechenden Kapitel im XHTML-Buch zu entnehmen: RDFa in XHTML.

Mittels role wird die Funktion eines Elementes gekennzeichnet. Der Wert ist eine mit Leerzeichen speparierte Liste von Funktionen. Die Funktionen werden entweder durch eine Zeichenkette repräsentiert, die eine von WAI-ARIA vordefinierte Funktion beschreibt, oder durch CURIE, einen (abgekürzten) Verweis auf eine Definition der Funktion.

about gibt das Subjekt einer Aussage an, also worum es geht. Der Wert ist im Wesentlichen eine URI zu einem Dokument oder Dokumentfragment, auf welches sich die Aussage bezieht. Sofern nicht angegeben, wird das aktuelle Subjekt vom Elternelement übernommen. Ist das aktuelle Element das Wurzelelement, ist das Dokument selbst das Subjekt oder - sofern angegeben - das per xml:base referenzierte Dokument.

property gibt das Prädikat einer Aussage an, also in welcher Relation das Subjekt zum Objekt steht. Sofern nicht anders angegeben, ist der Elementinhalt das Objekt, um welches es geht.

resource ist eine Möglichkeit, das Objekt einer Aussage anzugeben, sofern es nicht der Elementinhalt selbst ist. Der Wert ist im Wesentlichen eine URI zu einem Dokument oder Dokumentfragment.

datatype gibt den Datentyp an, in dem eine Information angegeben ist. Der Wert ist eine CURIE zur Definition des Datentyps.

typeof gibt an, mit welchen Datentypen das Subjekt assoziiert ist. Der Wert ist eine mit Leerzeichen separierte Liste von CURIEs zu den Definitionen der Datentypen.

content ist ein Ersatz für den Inhalt des Elementes (oder bei einem inhaltsleeren Element offenbar der Inhalt selbst). Die als Wert notierte Zeichenkette ist ein Textäquivalent für den Inhalt. Sofern datatype ebenfalls angegeben ist, entspricht die Zeichenkette der maschinenlesbaren Variante, während der Elementinhalt eine freiere Variante darstellt. Für eine formale Auswertung wird daher der Wert des Attributes verwendet statt der freien, schwerer zu interpretierenden Variante.

rel und rev sind von (X)HTML übernommen und enthalten eine mit Leerzeichen separierte Liste von CURIEs, um Beziehungen oder Prädikate zwischen zwei Ressourcen anzugeben.

Ein Knopf mit Nutzungshinweis:

<circle id="Start" cx="100" cy="100" r="100"
fill="#0a0"stroke-width="10" stroke="#00f"
role="button">
<title>
Knopf zum Beginn der Jonglage
</title>
<desc>
Ein Clown fährt auf seinem Einrad 
durch die Manege und jongliert dabei mit 
sechs rosafarbenen Pudelmützen mit grünen Bommeln, 
wenn dieser Knopf aktiviert oder angeklickert wird.
</desc>
<metadata xmnlns:wai="http://www.w3.org/TR/wai-aria/#" 
 role="tooltip" 
 property="wai:tooltip"
 content="Anklickern oder Aktivieren
zum Start der Animation" />
<animateMotion xlink:href="#Clown" 
  dur="600s" begin="Start.click; Start.activate">
<mpath xlink:href="#ClownPfad" />
</animateMotion>
</circle>

Im folgenden Beispiel werden Überschrift und Absatz aus HTML4 als property angegeben, weil SVG tiny 1.2 selbst über keine semantisch relevante Auszeichnung von Text verfügt. Etwas anwenderfreundlicher als HTML4 für diesen Zweck ist wohl zum Beispiel eine Sprache wie LML, die bereits unter anderem zur Verwendung als RDFa-Referenz ausgelegt ist.

Hier wird dann gleichzeitig auch eine neue Funktionalität von SVG tiny 1.2 genutzt, um Fließtext automatisch umzubrechen, was in SVG tiny 1.1 nicht umzusetzen war. Man beachte dabei auch den Unterschied zwischen der graphischen Formatierung mit dem Element tbreak und der semantischen Strukturierung durch Anwendung von property auf tspan innerhalb von textArea.

<g font-family="sans-serif" 
   xmnls:h="http://www.w3.org/TR/html4/struct/"

<text font-size="20"
x="100" y="100"
property="h:global.html#h-7.5.5">Hallo Welt!</text>

<textArea font-size="10"
x="100" y="150" width="500">
<tspan property="h:text.html#h-9.3.1">So 
grüßen wir die Stadt, 
das Land, die Erde, die Galaxis!<tbreak />
Und ganz besonders die
SVG-Arbeitsgruppe des W3C.</tspan>
<tbreak /><tbreak />

<tspan property="h:text.html#h-9.3.1">Der 
Gruß impliziert eine gewisse Weltoffenheit 
und eine positive Grundeinstellung 
und die philosophische Hypothese, 
daß es eine Trennung 
zwischen dem Ich und der Welt gibt, 
etwa im Gegensatz zum solipsistischen 
Ansatz, wo dieser Gruß 
nur ein Selbstgespräch wäre.</tspan>
<tbreak /><tbreak />

<tspan property="h:text.html#h-9.3.1">Die 
Nutzung des Imperativs 
zeigt wiederum eine gewissen Entschlossenheit, 
der Gruß selbst den Willen, 
offen auf die Welt zuzugehen, 
um eine Brücke 
zwischen dem Ich und der Welt
zu schlagen.</tspan>
</textArea>

</g>

Diverse Beispiele, allerdings mit Verwendungen in XHTML, sind in der XHTML+RDFa-Spezifikation angegeben. Spezielle Vokabularien sind derzeit (2011) für SVG noch nicht bekannt, aufgrund der gut durchdachten CURIE-Syntax kann aber eigentlich jede interessierte Gruppe eine Vokabelkollektion spezifizieren, damit diese von allen Autoren einheitlich genutzt werden kann.

Ein Hinweis zur Barrierefreiheit von SVG ist von der SVG-Arbeitsgruppe des W3C veröffentlicht worden und liefert Hilfen für eine bessere Zugänglichkeit von Dokumenten.

Text aus SVG extrahieren, nützlich, um ein Gefühl zu bekommen wie sich ein SVG ohne G anfühlt.

XLink, XML-Sprache zur Beschreibung von Verweisen, in SVG verwendet.

RDF, Rahmenwerk zur Beschreibung von Quellen (Meta-Informationen zu Werken).

Semantic Web Activity, Semantik im internet.

DCMI Dublin Core Metadata Initiative - Sprache zur Angabe von Meta-Informationen über Werke.

Text in SVG, Vorschläge zur Verwendung und Interpretation von Text in SVG.

IANA Medientypen, Liste registrierter internet-Medientypen (MIME).

RDFa in XHTML, Verwendung von RDFa-Attributen

WAI-ARIA, Anwendungen und Funktionalitäten angeben und zugänglicher machen

role, XHTML: role-Attribut

CURIE-Syntax, URIs abkürzen

LML, Auszeichnungssprache für Literatur, geeignet für RDFa in SVG tiny 1.2, um Text semantisch relevant zu kennzeichnen