SVG Checker


Table of Contents

Introduction
SVG validation
Existing tools
Tools we have developed
Accessibility of an SVG document:
Why make accessible SVG?
A tool to add text descriptions to an SVG document
A tool to extract the styles included in an SVG document
Conclusion
Webography

A major obstacle to the large scale use of SVG to display graphics in HTML pages is the difference in rendering depending on the terminal and the player. Who has not been surprised to discover an SVG file that has been displayed many times on his screen no longer displays properly with a different browser?

In this work, our objective is to assist the SVG developers to facilitate his work and determine precisely the levels of accessibility to a file. By levels of accessibility, we mean:

  • Compliance with a specific version of the standard

  • Compliance with a specific player or a browser

  • Accessibility for persons with visual impairments

To do this, we have developed a Java toolkit usable in various contexts. We offer tools to test compliance with a standard version or a player and to diagnose which elements or attributes are not compliant. The software provides guidance on how to write these elements or attributes to meet the standard, when the problem is a syntax problem, or indicates that this element or attribute is not supported in the selected version. It offers a solution or gives tips on how to display a version close to what the creator intended.

In the case of accessibility for people with visual impairments, one of our tools allows the developers to select each graphic element or group of graphic elements in order to associate a textual description in the <desc> tag of the element. This textual description can be used by a blind person to access the graphic as he does usualy with a standard html page. The same tool can also extract the styles of an SVG document, even if it does not already have a stylesheet in order to modify the styles according to the visual problem of the user.

In the rest of this article, we present these tools, compared to other existing tools and show how they can be used.

All of us have encountered an SVG file which doesn't play in our favorite player. And then, we are faced with the problem of finding what is wrong in the file: a syntax error, player lack of support for a specified feature, the SVG version...

Many of us will soon want to be able to convert an SVG 1.1 Full file to an SVG 1.2 Tiny file.

And we do not want to know every detail of each specification version of SVG.

We propose an environment to help to do all of that:

  • to analyze the characteristics of an SVG file

  • to find the characteristics to be changed to meet defined constraints

  • to indicate how to perform these modifications while making only a few changes to the original.

This project began with a state-of-the-art study which is still underway. To offer information on this study, we have opened a Wiki to group the data we collect on this subject: http://shadok.enst.fr/svghelper/. Contributions and comments are welcome. We have examined documents and tools that can help to achieve the above goals. There are three categories of tools:

  • Specifications and associated documents

  • Status of various implementations

  • Other tools and documents that help to produce SVGs

First of all, we have the DTDs (1.0, 1.1 Full, 1.1 Basic, 1.1 Tiny) and RelaxNG schemas (1.2 Tiny) from the W3C site.

W3C proposes the W3C XML Validator which is a general purpose tool which gives a good diagnosis of XML files, but it only takes SVG 1.1 into account.

Various sources give access to tools for validating an XML file against a schema, like one which is presented at http://tools.decisionsoft.com/schemaValidate. There are many other tools that are available at the XML level but we will not list them all.

From a developer's point of view, several libraries have tools to use DTSs and schemas (SAXON commercial version)

In our project, we have used Matra –a DTD parser utility available on SourceForge– and Jing, a RelaxNG validator in Java.

Next, there are web pages which give the status of various SVG implementations. Such pages must always be used with caution because they can't be up-to-date. The implementations are a work in progress.

[SVGTINT12IMP] provides a table summarizing the confomity of SVG Tiny 1.2 implementations with the SVG Test Suite.

[MOZSVGSTATUS] is useful about the implementation in Firefox. We can see here that the main limitations concer the text module, font and animation modules.

[GPACELMT] gives a commented list of supported elements in GPAC [GPAC] and [GPACTINY] gives a commented list about the results with the SVG Test Suite for Tiny 1.2. For GPAC, these documents are better references, more accurate and up-to-date, than [SVGTINT12IMP].

[OPERAELMT] gives a list of supported elements by Opera 9 while [OPERASVGSUPPORT] is an entry point to understand the SVG support by Opera 9.

[WEBKITELMT] gives a list of supported elements by Webkit, but a lot of important elements have the comment 'Partial'.This gives too little information to know if you can use it for a particular purpose.

Jonathan Watt gives a list of really useful authoring guidelines in [WATT]. We have included some of these guidelines in the warnings produced by our tools.

[OPDEBUG] is a contribution by Erik DahlStrom about debugging SVG with Opera.

SvgTidy's intention is to improve SVG files –like HTMLTidy on HTML– to provide better access to SVG content [SVGTIDY].

Scour is an open-source Python script that cleans SVG files, removing all unused IDs, extensions... The goal of Scour is to provide a rendered image identical to the original [SCOUR].

Firebug and the Error console in Firefox can also help in producing SVG. The Tools/Advanced... in Opera are also veryuseful.

Shortly before the deadline for this paper, we discovered The SVG Quality Assurance Project which has a goal similar to ours also provides some useful resources [SVGQA].

This paper presents a work in progress.

At a very elementary level, we check a file against the available DTD or schema and produce an initial diagnosis. That check is mainly about what is expressed by these formal specifications.

A variant is to check the file against several formal specifications and that diagnosis determines what is the best suited specification for the file.

Our tool is written in Java. It is a command line tool and simply requires an SVG file and some parameters. By default, it checks the file against all the schemas or DTDs found in a directory defined in the configuration file of the tool. A DTD or schema can be specified with a command line parameter; then, the check only uses this DTD or schema.

The results can be a simple text or a XML formated text either in the standard output, in a file, or both.

The XML formated output can easily be used as the input for other tools. It is possible to use it to generate web pages presenting the results. It is possible to use it as a guide to modify a file.

A single diagnosis in the XML output looks like the <error> element in the following code:

                
                <diagnosis>
    <specification name="full 1.0">
    <errors>
    …
    <error>
    <description>element unknown or not allowed in this context:listener</description>
    <element name="listener"></element>
    <line>944</line>
    <column>74</column>
    <extract><![CDATA[ <ev:listener target='g1c21' event='endEvent'
    handler='#versChambre' />\]\]></extract>
    </error>
    ...
                
            

As we can see in these lines, the diagnosis gives the line and column number of the error, an extract of the source near the error, the element, attribute or value which generated the error. With this data, we can easily find a lot of errors which are otherwise difficult to find in a file which doesn't display as we expect. For example, if an element has the attribute display="iniine" instead of display="inline", and is contained in a group with display="none", the element will not be displayed. Distinguishing between 'iniine, 'in1ine' (with a 'one' character instead of 'L') and 'inline' is very difficult without a tool to do it.

When a check is made with several specifications, we can see what the best suited specification is for that file, regardless of the declared version in the file. Also, we can see if a SVG 1.1 file conforms to SVG Tiny 1.2, and, if not, what are the necessary changes.

For example, if we want be in conformity with a specification, the XML output enable us to know what elements and what attributes and values don't comply and then to apply some rules to make them valid: developing a style attribute in the corresponding SVG attribute, choosing a value from the list of acceptable values, etc. We are working on these rules.

Some rules can be automatic, as the one about the style. Some rules can be configurable or interactive. For example, if a file uses a gradiant not supported by SVG Tiny 1.2, the tool proposes solutions like using a simple color or replacing the gradiant with a bitmap image.

Becoming compliant with a player is more difficult because they are constantly evolving. So we need to find another means other than a definition of a schema for the supported elements and attributes of a player. This is a possible solution, but is a really difficule task.

The first level of verifications is against the published table of elements supported by a list of players (cf. para. 'Status of various implementations'). There appears no easy solutions to stay up-to-date with the evolutions of the different players. We are searching for the best tools to modelize problems and present some solutions (ex: the problem with text size in Firefox). Subsequently the tools will work as they did previously (First, we need to identify the problem, second to propose solutions, finally to apply a chosen solution).


Finally, we have integrated the tool in a web application –tested with Tomcat– to be able to check a file with an online tool (see Figure 1, “The interface to check a SVG file”). We are not able to support security and CPU issues linked to afully online tool. So, we have decided to make the tool available on SourceForge (search for SVGHELPER).

This question can be answered with another question: "Why make the Web Accessible?" Multiple responses can be found in [HenryEOWG1]. They mainly concern the fact that more and more people with disabilities use the web in a variety of contexts (education, employment, commerce, health care, recreation...). They interact with the web and it is important that this interaction depends less and less on their disability. For SVG files, we will say that it is essentially not to exclude people with disabilities and thereby improve the readability of SVG images for the largest number of users.

We are faced with the fact that accessibility is virtually nonexistent for JPEG and PNG images and that the SVG format has a special role to play because of its specificities:

  • Structural definition of the document related to the structure of XML

  • Ability to enlarge an image without distortion.

We have relied on the recommendations of the W3C [CMCNEVILE] to guide our development work.

In this context, we have concentrated our efforts on those people who cannot easily access the content of web pages due to visual impairment. In general, they use specific devices to obtain the information contained in the document. Most often, these devices allow them to access textual information which is then transcribed into a format appropriate to their disability.

Our goal is to enable these people to use the same tools to access the SVG image, which is generally not the case. At best, there is additional textual information with an attribute "alt" or "desc" which is associated with the image and is the only readable information available to them.

Note: we did not try to solve all the problems of accessibility due to disability, but we concentrated on three main categories:

  1. people with significant visual impairment, without further deformation. In most cases this does not require special development since the magnification of the SVG document is usually sufficient to make the SVG image visible. The use of a tool to export Jpeg or Png format to SVG may be required (eg. Inkscape).

    If the loss is too great and the magnification does not give an acceptable representation view of the image, we will be in the same case as for the blind where a textual description is appropriate.

  2. blind people. They use two types of tools :

    • A Braille tablet which transcribes the text elements of the document into Braille.

    • An audio transcriber which transcribes the same textual elements into audio.

    The introduction of textual attributes associated with relevant tags will allow Braille tablets or audio transcribers to treat the SVG document adequately.

  3. persons with disabilities in both acuity and visual distortion. In these cases, besides the traditional magnification, tools currently used are to have style sheets appropriate to the disability of the person to adapt the document to this disability (tools for editing style sheets with Web Developer, Firebug...). Our tool creates CSS style sheets which are the referenced in an SVG in two ways:

    • Styles of the SVG graphic description

    • Styles of the textual descriptions provided for blind people.

The tools we have developed are dedicated to developers to provide them with the possibility of making SVG documents accessible. In the chain of developement of a web site, described in [HenryEOWG2] (see Figure 2, “The Development chain of a web site ([HenryEOWG2]) ”), our tools are located in the "Authoring Tools" component.


These are Java applications and they use the Batik library to analyse and display SVG documents.

This tool concerns blind people. These people often use a keyboa tablet to transcribe text into Braille to access the content of webpages.

To allow the keyboard tablet to effectively treat an SVG file, we have developed a tool that lets the designer add textual informations (<title> and <desc> tags) to SVG elements. The image below illustrates how it works (see Figure 3, “The interface to add description attributes”). It shows the graphical interface used to add description attributes.


This interface displays the file and allows some operations on it:

  • The XML tree is displayed in panel 1, while its graphical representation is drawn in panel 2.

  • The user can navigate in the XML tree with the buttons which are at the bottom of the interface (number 5 in the Figure).

  • Simultaneously the node selected by the user is highlighted in the XML tree (number 4). Its SVG description is displayed entirely (including any sub-nodes) in panel 3 while the drawing to which it corresponds is filled in red in the graphic display (number 7).

  • Finally, there are input fields for <title> and <desc> tags of the selected highlighted node (number 6) to allow the developer to give textual descriptions to this node (if they are relevant).

For example, suppose that we have the text below (Figure 4, “Extract of the original SVG source ”) which describes the teeth of the tiger.

              <g id="teeth">
                   <g id="upperteeth">
                       <g style="fill: rgb(255, 255, 204); stroke: rgb(0, 0, 0); stroke-width: 0.5;">
                           <path d="M -11.8,172.001 C -11.8, ..... z" id="path226"/>
                       </g>
                       <g style="fill: rgb(255, 255, 244); stroke: rgb(10, 10, 10); stroke-width: 0.5;">
                           <path d="M -88.9,169.301 C -88.9,169.301 -80, ..... z" id="path230"/>
                       </g>
                       .....
                    </g>
                   <g id="lowerteeth" >
                         <g style="fill: rgb(255, 235, 204); stroke: rgb(10, 0, 0); stroke-width: 1.5;">
                          <path d="M -8.2,249.201 C -8.2,249.201 -9,247.201 -13.4, ..... z" id="path166"/>
                       </g>
                       <g style="fill: rgb(155, 255, 204); stroke: rgb(0, 10, 0); stroke-width: 1.0;">
                           <path d="M -19.4,260.001 C -19.4,260.001 -23.8,247.201 -15, ..... z" id="path178"/>
                       </g>
                       .....
                   </g>
               </g>


Using the appropriate areas of the interface, the user can change the text describing the upper teeth and the lower teeth with the <desc> and <title> tags (see Figure 5, “ <desc> and <title> tags have been added to the original SVG source ”). The appropriate tags are then added in the SVG descriptions of these parts.

              <g id="teeth">
=====>>>>>>        <desc>all the teeth of the Tiger</desc>
=====>>>>>>        <title>entire part of the teeth</title>
                   <g id="upperteeth">
=====>>>>>>            <desc>upper teeth of the Tiger</desc>
=====>>>>>>            <title>first part of the teeth</title>
                       <g style="fill: rgb(255, 255, 204); stroke: rgb(0, 0, 0); stroke-width: 0.5;">
                           <path d="M -11.8,172.001 C -11.8, ..... z" id="path226"/>
                       </g>
                       <g style="fill: rgb(255, 255, 244); stroke: rgb(10, 10, 10); stroke-width: 0.5;">
                           <path d="M -88.9,169.301 C -88.9,169.301 -80, ..... z" id="path230"/>
                       </g>
                       .....
                    </g>
                   <g id="lowerteeth" >
=====>>>>>>           <desc>lower teeth of the Tiger</desc>
=====>>>>>>           <title>second part of the teeth</title>
                      <g style="fill: rgb(255, 235, 204); stroke: rgb(10, 0, 0); stroke-width: 1.5;">
                           <path d="M -8.2,249.201 C -8.2,249.201 -9,247.201 -13.4, ..... z" id="path166"/>
                       </g>
                       <g style="fill: rgb(155, 255, 204); stroke: rgb(0, 10, 0); stroke-width: 1.0;">
                           <path d="M -19.4,260.001 C -19.4,260.001 -23.8,247.201 -15, ..... z" id="path178"/>
                       </g>
                       .....
                  </g>
               </g>


The user chooses the SVG tags he wants to describe. Note that this tool can be useful as a tool for browsing the document and support the development in other contexts besides the implementation of document accessibility.

This tool concerns people whose sight, in addition to being insufficient, distorts the object viewed: multiple cases of visual impairments, sensitivity to contrasts...

To make SVG documents accessible, we exploit the fact that these people use development tools which allow them to use style sheets appropriate to their disability. For example, the colors used are chosen so that the appearance of text is consistent with their visual distortion. For this, there are plugins / extensions that are used to adjust the style sheets of a html document and change "in real time" the appearance of a document.

We have developed a tool which has the interface shown below (see Figure 6, “Interface for extracting styles”).


The interface presents 3 panels in which 3 kinds of information are displayed:

The first aims of this tool are to extract the styles which are expressed in the original SVG file and to perform the two following actions:

The result of this process is shown in Figure 7, “Attributes of CSS id and level class have been added ” which presents the original SVG file in which the attribute id replaces the styles definitions. It also adds a class definition to each tag which will be explained below.

               <g class="Level-Access-SVG-2" id="teeth">
                  <desc>all the teeth of the Tiger</desc>
                  <title>entire part of the teeth</title>
                  <g class="Level-Access-SVG-3" id="upperteeth">
                      <desc>upper teeth of the Tiger</desc>
                      <title>first part of the teeth</title>
                      <g class="Level-Access-SVG-4" id="g223" >
                           <path d="M -11.8,172.001 C -11.8, ..... z" id="path226"/>
                       </g>
                       <g class="Level-Access-SVG-4" id="g224">
                           <path d="M -88.9,169.301 C -88.9,169.301 -80, ..... z" id="path230"/>
                       </g>
                       .....
                    </g>
                   <g class="Level-Access-SVG-3" id="lowerteeth" >
                       <desc>lower teeth of the Tiger</desc>
                       <title>second part of the teeth</title>
                       <g class="Level-Access-SVG-4" id="g225">
                           <path d="M -8.2,249.201 C -8.2,249.201 -9,247.201 -13.4, ..... z" id="path166"/>
                       </g>
                       <g class="Level-Access-SVG-4" id="g226">
                           <path d="M -19.4,260.001 C -19.4,260.001 -23.8,247.201 -15, ..... z" id="path178"/>
                       </g>
                       .....
                  </g>
               </g>


The processus of extracting styles is ended in producing a file which contains all the styles that have been detected in the SVG file (see
Figure 8, “The extracted styles are collected and saved in a single file ”). In this way, the user can change of CSS file to make the SVG document adapted to his visual impairment. At this stage of our work, equivalent styles are not identified. They will be referenced as if they were different. Further work will be to combine the same styles according to the will of the developer.

                   #g223   {
                   fill: rgb(255, 255, 204); 
                   stroke: rgb(0, 0, 0); 
                   stroke-width: 0.5;
                   }
                   #g224   {
                   fill: rgb(255, 255, 204); 
                   stroke: rgb(0, 0, 0); 
                   stroke-width: 0.5;
                   }
                   #g225  {
                   fill: rgb(255, 255, 204); 
                   stroke: rgb(0, 0, 0); 
                   stroke-width: 0.5;
                   #g226  {
                   fill: rgb(255, 255, 204); 
                   stroke: rgb(0, 0, 0); 
                   stroke-width: 0.5;


The second part of the result consists in an independant class definition of the levels. To do this, our tool analyzes the document structure and introduces a class attribute to each node of the XML tree. The value of this attribute depends on the depth level of the node in the SVG document. For example, it gives the value "Level-Access-SVG-2" for the class attribute if the node is of depth 2 (see Figure 7, “Attributes of CSS id and level class have been added ”). All the class definitions have to be collected in a CSS file either by the developer who can produce one and attach it to the SVG file, or by the user who can use her or his own file. This is a style sheet which will be used when displaying the content of the <desc> and <title> tags of the document. The constraint building such a file is to use the predefined names of classes (Level-Access-SVG-1, Level-Access-SVG-2, Level-Access-SVG-3...)

The SVG document will then refer to the two CSS files with xlink tags. Note that after running the two processes, the user can then choose the descriptive representation depending on her or his disability.