Scalable Vector Graphics

Scalable Vector Graphics (SVG) is an XML-based vector image format for two-dimensional graphics with support for interactivity and animation. The SVG specification is an open standard developed by the World Wide Web Consortium (W3C) since 1999.

SVG images and their behaviors are defined in XML text files. This means that they can be searched, indexed, scripted, and compressed. As XML files, SVG images can be created and edited with any text editor, but are more often created with drawing software.

SVG files have a number of advantages over the common run of raster graphics formats. They are compact, human-readable, and massively scalable. They can also encode arbitrary amounts of metadata (e.g., object labels and type information). However, some issues need to be addressed before they can play a strong role in making graphical content accessible to the blind and visually impaired.

Adoption

Although SVG has been around since 1999, industry support has been slow to develop. Fortunately, most modern browsers and image generation tools now support it pretty well. There are also some SVG-specific generation tools (e.g., D3, Inkscape) So, over the long haul, prospects for general adoption are very good.

In addition, the W3C's Web Accessibility Initiative (WAI) is working on adding WAI-ARIA attributes to version 2 of the standard (SVG 2). When these attributes have been specified and implemented, client software (e.g., for image navigation) will have far more information to work with.

Issues

A fundamental semantic gap exists between (say) a graph-based diagram and its SVG representation. The diagram specification (as used by an editor or generation tool) encodes visible characteristics and relationships for a collection of objects. SVG, in contrast, tells the client how to render (i.e., "paint") a visual image.

Useful information (e.g., object style and connectivity attributes) can be lost if the program exporting the SVG does not opt to include it. Although the discussion below "picks on" OmniGraffle (OG), that's mostly because Rich uses it to create most of his diagrams. Similar issues are almost certain to be present in other tools.

OmniGraffle

OmniGraffle is a popular GUI-based diagram editor for the Mac. It is comfortable, flexible, and well supported by its vendor, The Omni Group. OG 6 exports perfectly functional (albeit minimalist) SVG which does a fine job of capturing the visual attributes of a diagram. More generally, however, the exported files could use some love.

Improving the code formatting would be a good first step. Each file contains only three lines (!) and the final ("svg") line may be several thousand characters in length. This is essentially impossible for a human to read without resorting to a prettyprinter. So, add some whitespace (e.g., line breaks, indentation):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" ... >
<svg xmlns="http://www.w3.org/2000/svg" ... ... ... >

With that out of the way, add a "g" (group) level for each object or link. Aside from making the code easier to read, this would clarify the diagram's semantic structure and provide a place to store semantic metadata. The resulting SVG for two nodes and a link might look something like this:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" ... >

<svg xmlns="http://www.w3.org/2000/svg" ... >

 <g class="node" id="N_0001" label="foo"
    shape="Squashed Rectangle" >
  <path ... >
  <text ... >
 </g>

 <g class="node" id="N_0002" label="bar"
    shape="Rectangle" >
  <rect ...>
  <rect ...>
  <text ...>
 </g>

 <g class="link" id="L_0001" label="foo_bar"
    tail_id="N_0001" tail_sym="none"
    head_id="N_0002" head_sym="filled arrowhead" >
  <line ... >
  <text ... >
 </g>
 ...

Although OG 7 is already in Beta, the support folks at The Omni Group have listened politely to our comments, criticisms, and suggestions. Also, this version is slated to add some related features, such as SVG import. So, there is some hope that OmniGraffle's exported SVG will move in this direction.

Microsoft Visio

As a follow-on experiment, we asked OmniGraffle to export a version of the diagram in their version of Microsoft Visio format. A PC-using friend was then able to open the file and export a second SVG version. The results were actually quite interesting.

Visio 2013 was unable to recover connectivity information from OmniGraffle's exported "Visio" file. That is, if a node was moved, the "attached" ends of the connecting edges did not move along. Had Visio been reading OmniGraffle's SVG file, this would not have been surprising. However, the purpose of exporting a diagram to Visio would seem to include being able to edit it. Finally, the label for a "Cloud" wasn't properly placed.

The SVG file that Visio exported was nicely formatted and contained a great deal of metadata. It isn't clear how much of this will be useful to us, but some items seem promising. Using a CDATA block, Visio defined several Cascading Style Sheet (CSS) entries which were used in the following SVG entries.

The SVG file uses the "g" tag quite a bit, adding an id attribute to each one. So, determining which "path" and "text" tags correspond to a given object is easy. Unfortunately, the "id" values were not used to provide connectivity information, even when we edited the file to "connect" the edges to the appropriate nodes.

To be continued...

D3.js

D3 is very good at taking in data, scaling and transforming it, and passing it along to SVG as a tidy numerical representation of a desired image. At least for static images, this is couched as a declarative specification for a silk-screen model of composition.

However, in the process of doing all this, D3 hides most of the incoming data values. So, for example, if it's generating a pie chart, each slice's percentage will be missing from the SVG file. This is a shame, because it means that this data is not available for use by screen readers or other follow-on processing. However, the situation is not as bad as it might appear:

SVG2 supports data-* attributes. Perhaps stringify the JSON to data-data? Double quotes need escaping...

  group
    .append("circle")
    .attr("r", function(d) { return radius(d.r);  })
    .attr("data-data", function(d) {
      return JSON.stringify(d);
    })

-- Kai Chang, on the d3-js Google Group

The bound data is stored as element.__data__ in the DOM and thus is available to JavaScript. This means you could write a browser extension to expose the data to a screen reader and it would work automatically on most D3 visualizations. Take a look at D3 Deconstructor for inspiration.

-- Mike Bostock, on the d3-js Google Group

Both of these approaches should be available to AxAp, possibly by means of an embedded JavaScript processor.

Other Software

As detailed below, SVG can be generated by many programs, for a large and growing number of use cases. For example, it can be created by means of diagramming software, a text or vector graphics editor, client or server code in a web application, etc. Each use case will have its own semantic idioms: data flow diagrams use nodes and lines, histograms use sets of parallel rectangles, etc.

Supporting every idiom for every use case is a substantial challenge, but the approaches used above are quite general. SVG entities can be grouped, as needed, to represent domain objects. Attributes can be used to encode semantic and/or visible characteristics. If and when they start to be widely supported, appropriate WAI-ARIA attributes can be added to SVG code.

To be continued...

SVG Sources

The list below is certainly not comprehensive, but it contains some interesting sources of SVG files. For more information, see the "Comparison of vector graphics editors" on Wikipedia. Unless otherwise noted, all tools are GUI-based and interactive.


This wiki page is maintained by Rich Morin, an independent consultant specializing in software design, development, and documentation. Please feel free to email comments, inquiries, suggestions, etc!

Topic revision: r12 - 02 Sep 2016, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email