SVG Linearization and Accessibility

$Date: 2002/01/21 15:53:46 $

Code and documentation download:
Available for download as a gzipped tarball)
Ivan Herman <ivan@w3.org> and Daniel Dardailler <danield@w3.org>

Table of contents

  1. Introduction
  2. What happens in the linearizer?
  3. Predicates
    1. Structural Predicates
    2. Layout and Positional Predicates
    3. Chart Predicates
    4. Animation Predicates
    5. Miscallenous Predicates
  4. Some Discussion Points, To-Do-s
  5. Availability
  6. Example Files
  7. References


Two notes have been published in W3C on the accessibility issues of SVG: the accessibility note on SVG of Charles McCathieNevile and Marja-Riitta Koivunen[SVG-access] and the internship report of Guillaume Lovet and Daniel Dardailler on the SVG linearizer tool[SVG-linear] (the latter is the report of the summer training work of Guillaume Lovet at W3C/INRIA). The two works are obviously related. Whereas the accessibility note describes a general methodology on how to use various SVG elements (grouping, description, styling, etc) to increase accessibility, the linearizer tool describes a more systematic approach and a tool, which could be regarded as the basis for a non-graphic reader of an SVG image. The linearizer tool relies on the author following certain rules, which can be be regarded as a practical usage of the methodology described in the accessibility note.

Unfortunately, there was no follow up on these reports since, which gives the false impression that the issue of SVG accessibility can be considered as solved. That is, however, not true. If one spends some time on generating, for example, SVG-based slides and presentation images, one is soon confronted to the issue of accessibility. The methodology described in the accessibility note[SVG-access] is only a first (though necessary!) step. Indeed, although it is certainly necessary to use the desc and title elements of SVG, for example, to give a textual description of the graphics content, it is far from obvious what and how should one describe in those. Unless some kind of common vocabulary is used, the various descriptions will be very different from one another, depending on the author's style, mood, and time; this would make it very difficult to use any kind of hypothetical textual reader, for example, to work properly.

This is where the linearizer tool comes into the picture. Indeed, the obvious answer to the problems is to define a common vocabulary to describe the image content. By describing this vocabulary in RDF[RDF], a more systematic description can be included into the SVG, thanks to the metadata element. The linearizer report includes a first shoot at such a vocabulary, accompanied by a Java tool which can read and display the RDF content in a human readable form. (The accessibility note refers to the usage of RDF, too, but it does not make an attempt to develop such vocabulary.)

This report picks it up where Lovet & Dardailler left it. It starts with the vocabulary defined in the linearizer report, and tries to use it systematically on a few presentation slides. By doing so, the vocabulary had been extended. The Java tool has also been reproduced in XSLT; it became easier to maintain and extend it rather than doing it in Java.

What happens in the linealizer?

Here is what happens with the linealizer:

  1. The author adds a set of description, using the RDF vocabulary described below, to the SVG image (a reminder: the metadata element of SVG allows the inclusion of RDF statements directly into the SVG file).
  2. Furthermore, the author adds textual description using the desc to (at least!) all elements which are referred to as primary RDF resources.
  3. The linealizer tool (the original Java tool of Guillaume, or the XSLT version thereof) reads the RDF portion of the SVG file and produces a readable version of it, making also use of the desc attached to the resources. For the time being, the XSLT tool produces HTML.

In some cases, the tool can also extract content from the SVG elements directly, depending on the context. For example, if an SVG element (ie, RDF resource) is identified as a label, or a pure textual information, the tool can extract the text proper; similarly, the geometric transformation can be extracted from the transform attribute. Making as much "sense" as possible is useful; the author is not forced to repeat things.


This section gives a list of the RDF predicates together with some examples. By default, the linealizer tool (here, and it what follows, I refer exclusively to the XSLT version) displays a textual version of the predicate (the parsing process would automatically yield some decent structure in the form of bulleted lists). In some cases the tool tries to do a bit more, which is then described together with the predicate itself.

RDF resources (unless they are other statements) usually refer to resources within the SVG file, unless stated otherwise. In general, this could be a general URI but the current tool is restricted to local references only (ie, the metadata must be part of the SVG file).

The object must be a literal, namely one of Chart, Conceptual, Clip-art, Decorative, Special.

The possible diversity of the graphics content is high and some other predicates make a real sense only if the content's general category is clear to the user. The current categories are only a first shoot, and come from a first categorization of Web images made by Daniel Dardailler[Categories].

On long term one can envisage to have completely different vocabularies depending on what the type of the graphics. By choosing different namespaces for the different vocabularies this predicate might become obsolete.

The statement whether the object is, or is part of a hyperlink anchor (ie, an SVG a element). If the object of the predicate is the literal true, the tool will locate the closest a ancestor and display the value of the xlink:href attribute. Possible desc element belonging to the element, as well as the xlink:title and xlink:role attribute, will also be displayed, as a characterization of the link. If a resource is explicitly given, this is considered to be the URI for the anchor and will be displayed literally.
The statement whether the object contains hyperlink anchors (ie, an SVG a element). If the object of the predicate is the literal true, the tool will locate the descandant a elements and display the values of the xlink:href attributes. Possible desc elements belonging to the elements, as well as the xlink:title and xlink:role attributes, will also be displayed, as a characterization of the links.

Structural Predicates

Lists the other objects (ie, SVG content) which is contained by the (graphics) subject. This conveys the basic structure of the graphics content. The immediate object of this predicate is usually a rdf:Bag
This is the "counterpart" of Contains.

One might be tempted to extract the content automatically using the group structure of SVG. Although this works in simple cases, it can be misleading. Indeed, the SVG content might include elements which are present for "fanciness" (ie, background color filters, etc) but do not convey meaningful information to a, possibly, textual agent.

The following example (extracted from cgmarch.svg) states that the slide contains four resources, identified as MetafileStructure, PictureDetails, PictureBody, and SymbolLibraries.

<rdf:Description about="#SlideContent">
      <rdf:li resource="#MetafileStructure"/>
      <rdf:li resource="#PictureDetails"/>
      <rdf:li resource="#PictureBody"/>
      <rdf:li resource="#SymbolLibraries"/>
All these predicates describe connections between the subject and the object resources, often used in presentation diagrams. The objects of these predicates are often bags.

The following example (again extracted from cgmarch.svg) states that the resource Picture1 (which is part of the MetafileStructure) "expands" to PictureDetails, ie, the latter give the details for the former.

<rdf:Description about="#Picture1">
  <axsvg:ExpandsTo rdf:resource="#PictureDetails"/>
This predicate is used when the subject is the "link" (ie, line, curve, etc) itself, and one wants to describe which other objects are connected by the subject. The immediate resource used by the predicate is usually an rdf:Seq.

The following example (from network.svg) states that the resource CableA, referring to a cable, connects the computer to a socket.

<rdf:Description about="#CableA">
      <rdf:li rdf:resource="ComputerA"/>
      <rdf:li rdf:resource="sock1"/>
The predicate states that the subject is a graphical template defined either through the symbol element or within a defs. The object of the predicate is the literal true or false.
The predicate states that the subject is an instance of a graphical template. The object of the predicate is either an SVG resource (which is also identified as the subject of an IsDef predicate), or a reified RDF statement making use of the Symbol and the Transformation predicates (see example below).
Identifies a template resource
Describes the transformation applied on the symbol when instantiating it. The object is either a textual literal, describing the transformation, or a reference to an SVG element. In the latter case the tool will extract the transform attribute of the target and display it in the output.

The following example (extracted from svgtransformations.svg) contains three statements:

  1. The resource duck is a graphical template
  2. The resource Original is an instantiation of duck, without specifying any transformation
  3. The resource simpleTranslate is also an instantiation of duck, but translated to the (200,190) position.
<rdf:Description about="#duck">
<rdf:Description about="#Original">
  <axsvg:InstanceOf rdf:resource="#duck"/>
<rdf:Description about="#simpleTranslate">
      <rdf:type rdf:resource="http://www.w3.org/2001/svgRdf/axsvg-resource.rdf#UseDescription"/>
      <axsvg:Symbol rdf:resource="#duck"/>
The predicate states that the subject is a textual node, ie, that the text content can be displayed directly. The object of the predicate is the literal true or false. The tool extracts the text from the SVG element and displays it verbatim.
The predicate refers to an SVG resource or a bag of resources which label the subject. The tool extracts the text from the SVG element(s) and displays the content verbatim. If the elements has a literal value, this will be displayed instead.
The predicate has the possible literal value of true or false. In the former case the tool extracts the text from the subject SVG element(s) and displays the content verbatim.

The resources identified by these predicates are not (necessarily) text nodes in the SVG sense. They can be, for example, texts enclosed in groups or even more complicated graphical objects, where only the textual parts are meaningful for a non-visual environment.

The following example (extracted from svgtransformations.svg) identifies three textual elements which are used as labels for scaleSkewXTranslate. The tool will display the textual content of translate4, ske4, and scale4 elements.

<rdf:Description about="#scaleSkewXTranslate">
      <rdf:li resource="#translate4"/>
      <rdf:li resource="#skew4"/>
      <rdf:li resource="#scale4"/>

Layout and Positional Predicates

These predicate give an abstract description on the placement of the various SVG objects relative to one another or relative to the full canvas

The predicate gives a rough absolute position of the subject on the full canvas. The object of the predicate is a literal with the possible value of N,S,W, E,NE,NW,SE, SW,NNE,NNW, ENE,WNW,SSW, SSE,ESE,WSW, or M, denoting 16 possible directions (north, south, west, east, north-east, etc) and the term "middle".
Similar to InPosition, except that the position of the subject is described relative to another object. The object of the predicate is a reified statement using RelativeTo and Direction.
Identifies an object used for InDirection
Refers to a direction value, used for InDirection. The possible objects are identical to InPosition.

The following example (extracted from svgtransformations.svg) states that Original is placed in the middle of the full SVG viewport, and that simpleTranslate is in south-east direction of Original.

<rdf:Description about="#Original">
<rdf:Description about="#simpleTranslate">
      <rdf:type rdf:resource="http://www.w3.org/2001/svgRdf/axsvg-resource.rdf#DirectionDescription"/>
      <axsvg:RelativeTo rdf:resource="#Original"/>
All these predicates can be used to provide additional information of the object's position relative to the subject. Their role is quite clear.

Chart Predicates

These predicates are specific to chart-like figures.

The predicate describes the type of the chart. Possible (literal) object values are: Bar, Line, Pie, Scatter, Area, Doughnut, Radar, Bubble, Stock, Surface.

I took the terms used by Microsoft Excel for the generation of charts. I guess this is representative enough.

This predicate describes the important data about charts. The object of a predicate is a reified statement using DataCategory and DataValues.
The object of this predicate is either a resource which is then treated as a textual node, or a literal. It gives a user-dependent characterization of the dataset
The object of this predicate gives the real data values. The object is either a literal (which contains the real data) or another SVG object (in which case the tool will attempt to extract a desc object as a textual description of the values).

The following example (extracted from membership.svg) describes the three data lines which is central to the chart; each has a category and a reference to a resource. To make the example clear, the SVG content for totalMemberLine is also shown; the tool will display the content of the desc element.

<rdf:Description about="#DataLines">
          <rdf:type rdf:resource="http://www.w3.org/2001/svgRdf/axsvg-resource.rdf#ChartDescription"/>
          <axsvg:DataCategory>Total Members</axsvg:DataCategory>
          <axsvg:DataValues rdf:resource="#totalMemberLine"/>
          <rdf:type rdf:resource="http://www.w3.org/2001/svgRdf/axsvg-resource.rdf#ChartDescription"/>
          <axsvg:DataCategory>Full Members</axsvg:DataCategory>
          <axsvg:DataValues rdf:resource="#fullMemberLine"/>
          <rdf:type rdf:resource="http://www.w3.org/2001/svgRdf/axsvg-resource.rdf#ChartDescription"/>
          <axsvg:DataCategory>Affiliate Members</axsvg:DataCategory>
          <axsvg:DataValues rdf:resource="#affMemberLine"/>
<path id="totalMemberLine" class="totalMembers" d="M0 50
                                                   L50,108  L100,117 L150,152 
                                                   L200,158 L250,179 L300,231 
                                                   L350,264 L400,293 L450,329
                                                   L500,363 L550,419 L600,478

This mechanism forces the author to write the data twice: once for the coordinate in path and once in the description. One could envisage an automatic mechanism extracting the coordinate values from the path directly, but the interpretation of a a path d attribute is not obvious. Besides, other shape elements could also be used.

Referring to the legend of the various chart axes. If the object of the predicate is a SVG resource, it will be interpreted like a textual node.

Animation Predicates

These predicates describe the effects of animation objects on other objects in SVG. Note that, in what follows, the term "animation", 'animate" will be used in the sense used in the SVG document[SVG]. However, "animation resource" might also mean a group of animation objects, or even an RDF resource defined directly in the metadata section to describe an animation effect.

Animation objects in SVG have a relatively low "granularity", meaning that to perform a specific animation effect one may have to use several SVG animation objects whose combined effects are perceived by the user as one animation. On a metadata level one should usually hide this granularity.

Refers to the fact that the subject is animated (moved, deformed, etc) by an animation object, whose reference is the object of the predicate.
This predicate should be used with a resource describing an animation; it refers to either an SVG resource or a bag of resources which are affected by the animation.
Beginning and duration of an animation. The object may refer to a literal or a "real" SVG animation object; in the latter case the tool will extract the begin (resp. dur) attribute of the SVG element (if it exists). If a literal is used, one can add a general description or refer to the formalism used in SVG for the begin (resp. dur) attribute.
Although it is possible to describe the full time line of the animations with the begin and duration attributes, in a number of cases this is way to detailed. AnimationSeq (resp. AnimationPar) lists a number of animation resources which are executed in a sequence (resp. in parallel). These are simplified versions of the SMIL constructs[SMIL].

The following example (extracted from PathAnimation.svg) the animation on a simple path. Note the usage of:

<rdf:Description rdf:about="#AnimatedDuck">
  <axsvg:AnimatedBy rdf:resource="#Animation"/>
<rdf:Description rdf:ID="#Animation">
  <desc>Deforms the duck into a potato and back</desc>
  <rdf:type rdf:resource="http://www.w3.org/2001/svgRdf/axsvg-resource.rdf#AnimationDescription"/>
  <axsvg:AnimationSubjects rdf:resource="#AnimatedDuck"/>
  <axsvg:AnimationBegins>user clicks on duck</axsvg:AnimationBegins>

The following example (extracted from animw3c.svg) is more complex, and describes the animation on the spinning W3C logo and the disappearing domain logos. Note that, instead of describing the detailed timing, the AnimationSeq is used. (Although this is not exact, because the fading out of the activity logos begin one second before the end of the W3C logo spin, this is not really important if the RDF is used to display the content of the image textually.)

<rdf:Description rdf:about="#opaciteimg2">
  <axsvg:AnimationSubjects rdf:resource="#domainLogos"/>
<rdf:Description rdf:ID="#logoAnimate">
  <desc>Spins around the logo by also reducing its size to almost invisible</desc>
  <axsvg:AnimationSubjects rdf:resource="#W3CLogo"/>
<rdf:Description rdf:ID="#logoAnimate2">
  <desc>Scales the logo up to a reasonable size</desc>
  <axsvg:AnimationSubjects rdf:resource="#W3CLogo"/>
<rdf:Description rdf:ID="#animationTiming">
  <rdf:type rdf:resource="http://www.w3.org/2001/svgRdf/axsvg-resource.rdf#AnimationDescription"/>
  <desc>Describes the relative timing of the animations</desc>
      <rdf:li rdf:resource="#logoAnimate"/>
      <rdf:li rdf:resource="#logoAnimate2"/>
      <rdf:li rdf:resource="#opaciteimg2"/>
  <axsvg:AnimationBegins>at load time</axsvg:AnimationBegins>

Miscallenous Predicates

Refers to special filters, color gradient fills, pattern fills, etc, which produce complex visual effects. Most of these effects may be simply ignored in the metadata description if the goal is to produce information for visually impaired; if there is a necessity to refer to the existence of these effects, the textual description should suffice. This predicate simply binds an object to a subject controlling the visual effects.
Refers to the geometric shape of the subject; the literal value can be rectangle, circle, etc, ie, the shapes defined by SVG. Note that the tool could extract, for example, the shapes coordinates from the corresponding SVG element, but it is not clear that this information would really be meaningful.

The impression I have is that, in most of the cases, the shape does not convey any important information on the content of the slide, so the usage of that predicate might be less useful than one might think at firts.

Example Files

Here is a list of some example SVG files which I used as examples, as well as the HTML files generated by XSLT.

SVG File (with embedded RDF) Generated HTML file
Architecture of a WebCGM file cgmarch.svg cgmarch.html
A small SVG example with accompanying explanation and code duckWithCode1.svg duckWithCode1.html
Examples for various type of SVG paths pathexamples.svg pathexamples.html
SVG transformation examples svgtransformations.svg svgtransformations.html
The network example used in the accessibility note [SVG-access] network.svg network.html
W3C membership evolution chart membership.svg membership.html
Overview of W3C recommendations recOverview.svg recOverview.html
Simple deformation of a curve PathAnimation.svg PathAnimation.html
Spinning W3C Logo animw3c.svg animw3c.html
Dataflow network of filter effects dataflowWithDucks.svg dataflowWithDucks.html

You can look at the complete RDF description of each of these by looking at the SVG source.

A separate slide set (prepared for a conference in Manchester, UK, in September 2001) has been prepared in SVG, and the content of each of the slides has also been annotated with the metadata described in this note.

Some Discussion Points, To-Do-s

One of the important features of the system is that the RDF vocabulary does not try to cover everything, but it relies on the human description provided with the resources, too. Indeed, it is probably not possible to develop an all-encompassing vocabulary, making the human annotation superfluous!

There are some communities, which might have developed sets of vocabularies and which we might want to tap on at some point. For example, there has been research done on the automatic generation of multimedia presentation, on constraint based graphics, on the annotation of images for multimedia databases, etc. We should be careful, however, not to be carried away by those: in a sense, the task outlined in this note is easier than, say, an automatic presentation generation, because our goal is to convey a meaningful information about the content which already exists!

An early version of using RDF Schema[RDF Schemas] has also been developed, see axsvg-schema.rdf. One of the problems is that the range of some of the predicates are either SVG elements (which can be expressed in a special class, as done already in the original linearizer tool[SVG-linear]) or a rdf:Bag, for example. Because RDF schemas are expressed in RDF, and RDF predicates can have only one object (RDF describes a graph, not a hypergraph), there is no multiple superclass, nor there are multiple ranges. This constraint can be expressed by defining our own Bags and Sequences, with our own li elements. The future development of web ontology might offer further tools to refine the vocabulary and the tools.

The current tool is restricted in its management of resources; it can manage only simple '#id' type of fragment identifiers, and only for elements in the same file. A more elaborate version of the tool should include a full URI management (which could lead to metadata files 'outside' the SVG source) as well as a full xpath management to identify an elements.

Some of the metadata can be quite verbose. This is also a shortcoming of the tool. The alternative RDF syntax might be more succing than the basic syntax (and this is the only one the tool understands). Also, it should be possible to include RDF schema calls directly into the code. For example the following code excerpt

<rdf:Description rdf:ID="#LabelBox">
  <rdfs:subClassOf rdf:resource="#http://www.w3.org/2000/01/rdf-schema#Resource"/>
<rdf:Description rdf:about="#Box">
  <rdf:type rdf:resource="#LabelBox"/>

could be a shorter alternative to the listing of elements which have all the same internal structure (ie, a labelled box with links). On the other hand, such repeated elements occur quite often, see, eg, the metadata added to recOverview.svg.


To test this, you need only two XSL files: rdfp.xsl and Properties.xsl. The former is almost identical to Dan's original parser, but it includes the second style file. The latter contains all SVG specific code. I tested these with saxon only. Caveat: for some reasons, saxon goes mad if the SVG DTD is in the SVG file (anybody knows why?) and an explicit nameset declaration to xlink should also be part of the file (saxon does not read the SVG DTD, which does include this...).

I am sure the XSLT file can be improved to produce a more "user-friendly" output, but this is not the real issue. Instead, the vocabulary has to be worked on. Also, I am almost sure that I made some mistakes in RDF and my usage of it may be clumsy; bear with me, this is the first time I use that stuff!

Note also that, at present, the RDF parser can only handle the basic serialization syntax of RDF[RDF].


"Resource Description Framework (RDF) Model and Syntax", O. Lassila and R. Swick, eds., 22 February 1999. W3C Recommendation.
[RDF Schemas]
"Resource Description Framework (RDF) Schema Specification 1.0", D. Brickley and R.V. Guha, eds., 27 March 2000. W3C Candidate Recommendation.
"Synchronized Multimedia Integration Language (SMIL 2.0) Specification", J. Ayars, et al. ed., 5 June 2000. W3C Proposed Recommendation.
"Scalable Vector Graphics 1.0 Specification", J. Ferraiolo, et al. ed., 2 November 2000. W3C Candidate Recommendation.
"Accessibility Features of SVG", C. McCathieNevile and M.-R. Koivunen, eds., 7 August 2000.
"SVG Linearizer tools", G. Lovet and D. Dardailler, 25 September 2000.
"WebCGM Profile", T. Bartosh et al., ed., 21 January 1999. W3C Recommendation.