Dependency statement for SVG (Scalable Vector Graphics)

danield@w3.org, last updated Feb 2000.

Intro

This document attemps to state the dependencies and issues between the SVG (Scalable Vector Graphics) format developed by the SVG Working Group and the WAI (Web Accessibility Initiative) PF (Protocols and Formats) Working Group.

Summary

• SVG is for primitive graphics, visual oriented by nature: 2D coordinates based.
• SVG is by nature good for accessibility and with the right amount of semantics, it has really high potential, but
• sometimes, the real accessible bits are elsewhere (XML, RDF, Excel, DB, etc)

Given that, we need to consider whether pushing to have all SVG graphic equally understandable in textual/linear format and using a keyboard only for output for instance is our best route

In a sense, SVG is 2D that we want to shrink to 1D, whereas the data used to build the SVG might already be 1D. So we should strive to get access to the real data in some cases (like for histogram chart).

Two cases worth mentioning.

Future assistive devices like haptic mice and 2D embossing/braille tablet will benefit from SVG in any case, provided structure/semantics is present (meaning a set of guidelines is present in addition to SVG); but image representation without sight is a still a research topic though (see prototypes at the Science Access Project - http://dots.physics.orst.edu - at Oregon State). One of the central issues here arises from the recognition that it is often necessary to simplify a visual image significantly before it can be displayed meaningfully as a tactile graphic. Whether this process can be automated is an interesting question, as is likewise the issue of whether a graphic file format should include a means of indicating which parts of an image should be preserved when presenting it tactually.

Also, in the context of structured figures with a properly constructed auditory UA, a listener should be able to move around the components of a drawing and hear the associated meta information. A user might even be able to move through the components of the figure based on their geometric relationships. Where such navigation and controlled presentation is available, the end result in terms of how much information is conveyed to the end user is far superior to any single flat textual description of the drawing. See T. V. Raman work on AsTeR - http://cs.cornell.edu/home/raman/phd-thesis/abstract.txt.

Usage scenario for SVG

• Numeric: graph as output of db data: pie chart, histogram, curves, etc
  • better get the numeric data to the specialized UA which can then construct a view adapted to the media it supports (voice, braille, etc)
  • the graphics representation can be made accessible if well designed (link from legend to sized object for instance)
  • exception: when graphic represent synthetic work from large set, or when it's not obvious there is any real numeric data to back it up, the graphics and its description are best
  • examples page
• Conceptual: graph to illustrate abstract concept, organization, structure, hierarchical relation, layering, component architecture, flow/communication,
  • the graph helps illustrate concept described in running text
  • the text is usually the accessible piece
  • individual objects should be grouped and identified, connected, etc. so that the graphics can be used in a serial medium as well.
  • high potential for SVG if connecting point are available
  • there might be more accessible original data, in RDF or some other semantics language (representing the relations expressed in the graphic, like a hierarchy), but that's unlikely in today's web
  • examples page
• Special: application specific graphics, mostly scientific: electrical sketch, math graph, molecule drawing, font, etc
  • also map (geography, floor, anatomical, mechanical cut thru)
  • need to access the specialized language (MathML, ChemicalML, etc)
  • examples page
• Clip-art: represent reality, graph for art work, modelisation, object representation, space stuttle, people, computer drawing, shapes, etc.
  • often a 2D projection of a 3D object
  • highly graphical in nature
  • hardly accessible serially: best is to describe and declare for reuse
  • examples page
• Decorative graphics
  • geometrical background pattern
  • shadowed frame
  • can be ignored
  • examples page

Blue Sky scenario

Access is given to the rich semantics, not just to the graphical output.
or
Everybody has 2d access (braille matrix, screen, etc)
and
For graphics with no predefined semantics, proper authoring guidelines are followed that permits to reconstruct some of the semantics (2d or otherwise) in a serial medium.

First steps

Make sure SVG has enough associative and structural features to allow the definition of content guidelines that UAs can exploit to present the graphical data in a serial medium.

In particular, we started discussing what features set is important for access wrt SVG:

• Labeling (using real XML content is a plus)
• Grouping (structure is always good)
• Template (reuse promote serialization,learning,consistency)
  how is this related to XML Fragment ?
• Connection (more structure/semantics)
  appear not to be in the charter, what can we do to help ?
• Event model (provided it's device independent)

• Public spec
• Scaling
• DOM

Note on connection/grouping