$Date: 2002/01/21 15:53:46 $
Copyright © 1999-2000 W3C® (MIT, INRIA, Keio), All Rights
Reserved. W3C liability, trademark, document use and
software
licensing rules apply.
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.
Here is what happens with the linealizer:
metadata element of SVG allows the
inclusion of RDF statements directly into the SVG file).desc to (at
least!) all elements which are referred to as primary RDF resources.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 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.
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.
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.
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">
<axsvg:Contains>
<rdf:Bag>
<rdf:li resource="#MetafileStructure"/>
<rdf:li resource="#PictureDetails"/>
<rdf:li resource="#PictureBody"/>
<rdf:li resource="#SymbolLibraries"/>
</rdf:Bag>
</axsvg:Contains>
</rdf:Description>
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"/> </rdf:Description>
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">
<axsvg:Connects>
<rdf:Seq>
<rdf:li rdf:resource="ComputerA"/>
<rdf:li rdf:resource="sock1"/>
</rdf:Seq>
</axsvg:Connects>
</rdf:Description>
symbol element or within a defs. The object of the predicate is the
literal true or false.transform attribute of the target and
display it in the output.The following example (extracted from svgtransformations.svg) contains three
statements:
<rdf:Description about="#duck">
<axsvg:IsDef>true</axsvg:IsDef>
</rdf:Description>
<rdf:Description about="#Original">
<axsvg:InstanceOf rdf:resource="#duck"/>
</rdf:Description>
<rdf:Description about="#simpleTranslate">
<axsvg:InstanceOf>
<rdf:Description>
<rdf:type rdf:resource="http://www.w3.org/2001/svgRdf/axsvg-resource.rdf#UseDescription"/>
<axsvg:Symbol rdf:resource="#duck"/>
<axsvg:Transformation>translate(200,190)</axsvg:Transformation>
</rdf:Description>
</axsvg:InstanceOf>
</rdf:Description>
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">
<axsvg:LabelledBy>
<rdf:Bag>
<rdf:li resource="#translate4"/>
<rdf:li resource="#skew4"/>
<rdf:li resource="#scale4"/>
</rdf:Bag>
</axsvg:LabelledBy>
</rdf:Description>
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 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">
<axsvg:InPosition>M</axsvg:InPosition>
</rdf:Description>
<rdf:Description about="#simpleTranslate">
<axsvg:InDirection>
<rdf:Description>
<rdf:type rdf:resource="http://www.w3.org/2001/svgRdf/axsvg-resource.rdf#DirectionDescription"/>
<axsvg:RelativeTo rdf:resource="#Original"/>
<axsvg:Direction>SE</axsvg:Direction>
</rdf:Description>
</axsvg:InDirection>
</rdf:Description>
These predicates are specific to chart-like figures.
I took the terms used by Microsoft Excel for the generation of charts. I guess this is representative enough.
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">
<axsvg:Chart>
<rdf:Bag>
<rdf:li>
<rdf:Description>
<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:Description>
</rdf:li>
<rdf:li>
<rdf:Description>
<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:Description>
</rdf:li>
<rdf:li>
<rdf:Description>
<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"/>
</rdf:Description>
</rdf:li>
</rdf:Bag>
</axsvg:Chart>
</rdf:Description>
...
<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
L650,509">
<desc>50,108,117,152,158,179,231,264,293,329,363,419,478,509</desc>
</path>
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.
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.
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.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: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> <axsvg:AnimationDuration>2s</axsvg:AnimationDuration> </rdf:Description>
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"/>
<axsvg:AnimationDuration>2s</axsvg:AnimationDuration>
</rdf:Description>
<rdf:Description rdf:ID="#logoAnimate">
<desc>Spins around the logo by also reducing its size to almost invisible</desc>
<axsvg:AnimationSubjects rdf:resource="#W3CLogo"/>
<axsvg:AnimationDuration>5s</axsvg:AnimationDuration>
</rdf:Description>
<rdf:Description rdf:ID="#logoAnimate2">
<desc>Scales the logo up to a reasonable size</desc>
<axsvg:AnimationSubjects rdf:resource="#W3CLogo"/>
<axsvg:AnimationDuration>4s</axsvg:AnimationDuration>
</rdf:Description>
<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>
<axsvg:AnimationSeq>
<rdf:Seq>
<rdf:li rdf:resource="#logoAnimate"/>
<rdf:li rdf:resource="#logoAnimate2"/>
<rdf:li rdf:resource="#opaciteimg2"/>
</rdf:Seq>
</axsvg:AnimationSeq>
<axsvg:AnimationBegins>at load time</axsvg:AnimationBegins>
</rdf:Description>
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.
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.
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"/> <axsvg:Labelled>true</axsvg:Labelled> <axsvg:Shape>rectangle</axsvg:Shape> <axsvg:ContainsAnchors>true</axsvg:ContainsAnchors> </rdf:Description> ... <rdf:Description rdf:about="#Box"> <rdf:type rdf:resource="#LabelBox"/> </rdf:Description>
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].
