Marja-Riitta Koivunen <marja@w3.org>
Copyright © 1999-2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability,
trademark,
document
use and software
licensing rules apply.
Scalable Vector Graphics (SVG) offers a number of features which can make graphics on the Web more accessible than is currently possible, to a wider group of users. This includes users with varying disabilities, such as low vision, color blind or blind users, and users of assistive technologies. A number of these features can also increase usability of content for many users without disabilties, such as users of personal digital assistants, mobile phones or other non-traditional Web access devices.
Accessibility requires that the features offered by SVG are correctly used and supported. This Note aims to describe the possibilities offered, and illustrate their use with some concrete examples.
This document represents a nearly complete draft of a W3C Note and is made for review by the WAI Protocols and Formats Group, the WAI Education and Outreach Group and the SVG Working Group before publication as a Note. This document will be based on the Candidate Recommendation version of the SVG Specification which is the last stage before it can be proposed as a W3C Recommendation. The authors hope to publish an updated version of this Note in any of the following circumstances:
Publication of a W3C Note does not imply endorsement by the W3C Membership. A list of current W3C technical reports and publications, including working drafts and notes, can be found at http://www.w3.org/TR.
Please send comments to Charles McCathieNevile, Marja-Riitta Koivunen
Images, sound, text and interaction all play a role in conveying information on the Web. In many cases, images have an important role in conveying or clarifying and simplifying information. In this way the use of multimedia is itself a benefit to accessibility. However the information presented in images needs to be accessible to all users, including users with non-visual devices. Furthermore, in order to have full access to the web, it is important that authors with disabilities can create Web content, including images as part of that content.
The working context of people with (or without) disabilities can vary enormously. Many users or authors
Increasing the accessibility of images can benefit a wide variety of users and authors including many people who do not have a disability but who have similar needs. For example, someone may be working in an eyes-busy environment and thus require an audio equivalent to information they cannot view. Users of small mobile devices (with small screens, no keyboard, and no mouse) have similar functional needs to some users with disabilities. For further information on how people with different disabilities use the Web, please consult the Working Draft "How People with Disabilities Use the Web" [USENOTE].
Scalable Vector Graphics [SVG] is a new markup language for producing Web graphics that is written in XML. SVG provides many accessibility benefits for disabled users, some originating from its use of the vector-graphics model, some inherited because SVG is built on top of XML, and the rest spring from the design of SVG itself, for example, SVG-specific elements for alternative equivalent@@ information.
The accessibility benefits of SVG are listed and briefly explained in the following. The benefits that are common to all XML languages are marked with "XML -" in the title. These benefits are part of this Note too, as we want to show how they can be utilized with the context of SVG images.
SVG images are scalable - they can be zoomed and resized by the reader as needed. Scaling can help users with low vision, or users with assistive technologies, such as tactile graphic devices, which typically have a very low resolution.
The following example illustrates the scalability of a vector graphics image. The first row shows a small PNG and a corresponding SVG image, which look the same. The second row shows an enlargement of both. The enlarged PNG version of the image has suffered a significant loss of quality, while the enlarged SVG version looks smooth and shows more details than before. Providing smooth zooming can make it easier for users with low vision to make sense of the image at an appropriate size for them.
| Small PNG image:
|
Small SVG image:
|
| Enlarged PNG image:
|
Enlarged SVG image:
|
The raster-based image formats commonly used on the Web, such as PNG or GIF, are typically made accessible for users with visual disabilities by associating a text equivalent which can be rendered as well as or instead of the visual image. This text equivalent is virtually the only possibility as the images are stored as matrices of colored dots, generally with no structural information. Structural information can be added to any image as metadata but managing it separately from the visible image is tedious, making it less likely that authors will create and use it with careful attention. SVG's vector-graphics based format stores structural information of graphical shapes as an integral part of the image. As we discuss below, this information can be used by alternative rendering tools to increase accessibility, especially when combined with corresponding alternative equivalents and metadata.
As well as having some of an image's structure encoded in the image, SVG allows for alternative equivalents - content that users can access to help them understand the image. In particular, SVG provides a natural way to include descriptions of each logical part of an image, and a title for each part can be provided to explain its role in the image.
One major accessibility benefit that comes from being XML is that an SVG image is encoded as plain text. For authors, this means it can be created, edited and rendered by a text-processing or XML authoring application (as we shall see, there are other properties of SVG that make this easier than it might seem at first). A number of popular Web design tools are in fact enhanced text-editing applications, and for users with certain types of disabilities these are much easier to use. Naturally, it is also possible to create graphic SVG authoring tools that require very little reading and writing, benefitting people with other types of disabilities.
It also means that it is relatively simple to use text-based XML user agents to render SVG as text, braille, or audio. This can help users with visual impairments, and can be used to supplement graphical rendering.
The separation of presentation from the rest of the content is highly important for accessibility. Presentations of SVG images can be controlled by attaching stylesheets to them, which is a feature common to all markup languages written in XML. Users who might otherwise be unable to access content can define stylesheets to control rendering of the SVG images, meeting their needs without losing additional author-supplied style unnecessarily.
SVG adds a number of stylistic features to CSS to fit its specific graphics needs for controlling of the presentation of images. The styling possibilities can help users with low vision, color deficiencies, or users with alternative interaction devices. Features such as masking, filters, and the ability to define highly complex fonts are all available in SVG.
Another benefit of using XML is that interaction can be made accessible through the Document Object Model (DOM). The DOM interface can enable the use of many assistive technologies @@add link to a definition@@ with SVG images. SVG provides access both to stylesheet and XML content as it uses DOM version 2 [DOM2] .
SVG can also be easily used with other XML languages, which increases accessibility as it is possible to use the most suitable markup language for each part of a document (refer to [WCAG], Guideline 3 in general). SVG definitions can be embedded into other XML languages. For instance, a MathML document could use SVG both for presenting equations and graphs of the equations. Similarly an SVG document can include other XML languages. In examples below we show how to include RDF metadata and SMIL presentations to provide further information about the graphical components and their relationships.
This document highlights the features in SVG which support accessibility. In Sections 2, 3, 4, 5 and 6 we discuss the accessibility features of SVG (including the use of stylesheets). Section 7 explains the accessibility benefits that originate from XML. To illustrate how to create accessible SVG graphics with various SVG features the document uses an example of a network diagram which is successively built up. A reader who has a basic knowledge of HTML or XML should be able to fairly easily compherend enough of the markup to make sense of the examples.
Providing equivalent alternative information for inaccessible content is one of the primary ways authors can make their documents accessible to people with disabilities. The equivalent content fulfills essentially the same function or purpose to disabled users as the primary content does for the person without any disability.
Since text content can be presented to the user as synthesized speech, braille, and visually rendered text, text equivalents are always required for graphic information. In SVG the text equivalents can also convey the hierarchical structure of the graphic components.
One of the key requirements for accessibility of graphics is to make alternative information available to people who cannot see the graphics (refer to [WCAG], Checkpoint 1.1, and Guideline 1 in general). This Note presents a number of ways to include and use alternative content. The simplest of them is to specify equivalent alternatives by including the following elements in any SVG container or a graphics element:
titledescMost often the title and desc elements contain
text. However, if necessary they may also contain text markup from other XML
languages and style definitions can be attached to them. This is possible,
because they are included in SVG as elements and not as attributes. Figure 5.1
has an example of including text markup in equivalent alternatives.
The following example is a simple SVG document that includes a title and a description for an image of a computer network. The graphic components that can actually be drawn will be added to the image in later sections.
Example 2.1: A simple SVG
document with title and desc elements (download structure in 2.1).
<?xml version="1.0"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN" "http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd"> <svg width="6in" height="4.5in" viewBox="0 0 600 450"> <title>Network</title> <desc>An example of a computer network based on a hub</desc> </svg>
An SVG image can consist of several hierarchical components each of which can have a title and a description. By using the hierarchy and the equivalents it is often possible to create a rough mental model of the image without being able to see the graphics of the image. Therefore it is important that where possible SVG authors carefully build the hierarchical component structure so that it reflects the components of the object illustrated by the image. Some guidance for using structure can be found in WCAG (refer to [WCAG], Guidelines 3 and 12).
The following example extends the network image component introduced in the previous example by introducing six subcomponents:
Each subcomponent is included as a container element with an
id attribute and equivalent information. Although this image
still does not contain any graphics elements we already know quite a lot about
it. (Note: To easily identify changes from the previous version of the example
new content is strongly emphasized).
Example 2.2: A structured SVG document with alternative equivalents (download structure in 2.2).
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN"
"http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450">
<title>Network</title>
<desc>An example of a computer network based on a hub</desc>
<g id="hub">
<title>Hub</title>
<desc>A typical 10BaseT/100BaseTX network hub</desc>
<!-- add graphic content here -->
</g>
<g id="ComputerA">
<title>Computer A</title>
<desc>A common desktop PC</desc>
<!-- add graphic content here -->
</g>
<g id="ComputerB">
<title>Computer B</title>
<desc>A common desktop PC</desc>
<!-- add graphic content here -->
</g>
<g id="CableA">
<title>Cable A</title>
<desc>10BaseT twisted pair cable</desc>
<!-- add graphic content here -->
</g>
<g id="CableB">
<title>Cable B</title>
<desc>10BaseT twisted pair cable</desc>
<!-- add graphic content here -->
</g>
<g id="CableN">
<title>Cable N</title>
<desc>10BaseT twisted pair cable</desc>
<!-- add graphic content here -->
</g>
</svg>The component hierarchy with alternative equivalents can be used in different ways by different renderers. For instance, a simple non-visual renderer can provide access to the component hierarchy and allow the user to navigate her way up and down or at a certain level of the structure, giving her the equivalent description of each encountered component (see also User Agent Guidelines [WD-UAAG] Checkpoints 7.6 and 7.7 and Guidelines 7 and 8 in general). A standard XML browser, which does not render SVG as graphics, may also do this. A multimedia-capable renderer might name each component that has focus through speech output - much like tooltips are used in some Web browsers to render alternative text for images.
A simple way to render the image in Example 2.2 is to show the alternative
equivalents as text, such in Figure 2.3. This can be done by attaching CSS [CSS] style information to the title and
desc elements of the image. An example stylesheet to do this
kind of rendering is presented and explained in Figure 4.2
in Section 4. (Normally without a style definition
nothing would be presented to the user.)
Figure 2.3: Textual representation of Example 2.2 when it is rendered with the stylesheet in Figure 4.2.
Network An example of a computer network based on a hub
Hub A typical 10baseT/100BaseTX network hub
Computer A A common desktop PC
Computer B A common desktop PC
Cable A 10BaseT twisted pair cable
Cable B 10BaseT twisted pair cable
Cable N 10BaseT twisted pair cable
Users examining images visually automatically try to divide them into components and connections between these components. The author guides the division by using visual means, such as the adjacency, colors, patterns, sizes and shapes of the components. When the image cannot be seen other available information can be used. For instance, the users can examine the basic graphical components, such as rectangles, circles, and ellipses, that are included in the image. These offer a compact way of transfering information. With certain kinds of graphic images the author can also provide a well-constructed component structure. From that users can easily discover which graphical elements are included in each component, and what components are re-used in the image.
With some images the rendering order may make it impossible to follow a
logical component structure. In this case the structure needs to be clearly
explained in the desc element. The structural information does
not remove the need for author-provided equivalent information. However, when
it is possible to offer, it helps to gain deeper understanding of the image
when the user or a special device needs it (and is capable of using it).
Authoring tools can support the authors to provide a good structure that is
easy to understand by providing ways to visualize the component hierarchy
(refer to Authoring Tool Accessiblity Guidelines [ATAG]
checkpoint 3.2).
The re-use of components saves time as users only need to examine the same component once. The ability to re-use structured components also helps authors, including authors with disabilities, because the changing of the images becomes easier to manage. The structure of an image can also help the author when it is used for editing purposes. This is a requirement of the Authoring Tool Accessibility Guidelines (refer to to [ATAG], Checkpoint 7.5). Because the image components can include alternative equivalents, it is also possible to build up libraries of annotated multimedia (refer to to [ATAG], Checkpoint 3.5).
SVG allows authors to create familiar basic shapes such as rectangles, circles, ellipses and polygons. As we show in section 4.x@@ the use of stylesheets can make it easy to at least list the basic shape or shapes used to represent an object. In the following example (which will be the hub for the network image) we have two rectangles, one inside the other, and a small circle inside the larger rectangle.
Example 3.1: Adding some shapes to form an image of a Hub (download hub image in 3.1).
<?xml version="1.0"?>
<?xml-stylesheet href="http://www.w3.org/1999/09/SVG-access/svg-basic-style" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN"
"http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450">
<g transform="translate(10 10)">
<title>Hub</title>
<desc>A typical 10BaseT/100BaseTX network hub</desc>
<rect width="253" height="84"/>
<rect width="230" height="44" x="12" y="10"/>
<circle cx="227" cy="71" r="7"/>
</g>
</svg>Figure 3.2: Visual rendering of Example 3.1.
Images often include text that explains or names the elements presented in
the image. With SVG the text is contained in text elements that
keep the textual form available for various assistive or other technologies.
Furthermore, the text from other elements, such as text equivalents, can be
reused. This helps in managing text as it only needs to be changed at one
place.This can help authors for whom entering content is difficult, and helps
by ensuring that when one piece of text changes other text that depends on it
will automatically be updated..
In the following, we add a text element to the image of the
Hub that was described in Section 3.1. This text element re-uses
the title text of the Hub image by referring to it with a
tref element and rendering it as part of the text
element. An id attribute is added to the title
element so that it can be referenced.
Example 3.3: Reusing the title
as text in the Hub image (download hub image in
3.3).
<?xml version="1.0"?>
<?xml-stylesheet href="http://www.w3.org/1999/09/SVG-access/svg-basic-style" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN"
"http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450">
<g transform="translate(10 30)">
<title id="hub">Hub</title>
<desc>A typical 10BaseT/100BaseTX network hub</desc>
<!-- Re-use the text in the title element -->
<text x="0" y="-10">
<tref xlink:href="#hub"/>
</text>
<rect width="253" height="84"/>
<rect width="230" height="44" x="12" y="10"/>
<circle cx="227" cy="71" r="7"/>
</g>
</svg>Figure 3.4: Visual rendering of Example 3.3.
SVG allows the construction and re-use of graphic components. This makes it easier to understand the structure of complex images as the re-usable components are defined only once and therefore need to be studied and understood only once. This helps especially if the alternative means of examining the image are more time consuming. Serial means of inspecting information, such as using a speech rendering, have often been compared to reading through a soda straw. It can take a lot longer to be able to understand context and relationships than it does by visual inspection since it is a slower means of receiving the information, and the relationships must be assmebled as a mental model without the benefit of a visual representation of the structure.
An authoring tool may also utilize this feature to help to create and modify graphics with standard components. This can also help users having difficulties in fine motor control as there is less drawing and writing required.
In the following example we have defined a socket, and added five of them to the hub defined earlier:
Example 3.5: Adding 5 sockets to the Hub in Example 3.3 (download hub image in 3.5).
<?xml version="1.0"?>
<?xml-stylesheet href="http://www.w3.org/1999/09/SVG-access/svg-basic-style" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN"
"http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450">
<g transform="translate(10 30)">
<!-- Define a socket -->
<defs>
<symbol id="hubPlug">
<desc>A 10BaseT/100baseTX socket</desc>
<path d="M0,5 h5 v-9 h12 v9 h5 v16 h-22 z"/>
</symbol>
</defs>
<title id="hub">Hub</title>
<desc>A typical 10BaseT/100BaseTX network hub</desc>
<text x="0" y="-10">
<tref xlink:href="#hub"/>
</text>
<rect width="253" height="84"/>
<rect width="229" height="44" x="12" y="10"/>
<circle cx="227" cy="71" r="7"/>
<!-- five groups each using the defined socket -->
<g transform="translate(25 25)" id="sock1">
<title>Socket 1</title>
<use xlink:href="#hubPlug"/>
</g>
<g transform="translate(70 25)" id="sock2">
<title>Socket 2</title>
<use xlink:href="#hubPlug"/>
</g>
<!-- (and three more) -->
</g>
</svg>Figure 3.6: A visual rendering of Example 3.5.
SVG images can also include components or complete images from other documents using XML Linking Language [XLINK]. Xlink enables easy construction and re-use of libraries of known images which can be available locally or on the Web. For authors, this means being able to use a known graphic component even when it cannot be seen. For users who cannot see, a library of described images or image components can be used to help identify standard graphic components.
The following example uses images and symbols defined elsewhere with the
rest of the graphics. These are emphasized in the example. In addition, it
adds a text element to the Network image and some graphics
elements to the Cable images. These are marked with comments.
Example 3.7: Adding graphics to the Network components presented in Example 2.2 (download network image in 3.7). @@image and download need URI's, hub w+h updated + checked.@@
<?xml version="1.0"?>
<?xml-stylesheet href="http://www.w3.org/1999/09/SVG-access/svg-style" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN"
"http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450">
<title id="mainTitle">Network</title>
<desc>An example of a computer network based on a hub</desc>
<!-- Draw text. -->
<text x="0" y="-10">
<tref xlink:href="#mainTitle"/>
</text>
<!-- Use the hub image and its title and description information. -->
<g id="hub" transform="translate(180 200)">
<image width="600" height="450"
link:href="hub.svg"/>
</g>
<!-- Use an external computer symbol. Scale to fit. -->
<g id="ComputerA" transform="translate(20 170)">
<title>Computer A</title>
<use xlink:href="computer.svg#terminal"
transform="scale(0.5)"/>
</g>
<!-- Use the same computer symbol. -->
<g id="ComputerB" transform="translate(300 170)">
<title>Computer B</title>
<use xlink:href="computer.svg#terminal"
transform="scale(0.5)"/>
</g>
<g id="CableA" transform="translate(107 88)">
<title>Cable A</title>
<desc>10BaseT twisted pair cable</desc>
<!-- Draw Cable A. -->
<path d="M0,0c100,140 50,140 -8,160"/>
</g>
<!-- (and the other two cables) -->
</svg>Note that we did not add title or desc elements
for the hub component, since it refers to an SVG image that
already contains those elements with general descriptions. These equivalents
should be made available to the user by a user agent. Similarly each computer
image already has a desc element defined as part of the
symbol element so it does not need to be repeated. But each
computer needs an individual title to describe the role it plays
in the network image.
Figure 3.8: A visual rendering of Example 3.7.
One of the main themes in the Web Content Accessibility Guidelines is the separation of presentation from the other content (refer to [WCAG], Checkpoint 3.3 and Guideline 3 in general). When presentation is clearly separated the user has more control to adjust the style, such as the color of the elements or font size, to meet specific needs. Furthermore, the author can more easily experiment with different styles or adjust the presentation to different output devices (the latter is required by Authoring Tool Accessibility Guidelines[ATAG] Checkpoint 7.2).
As the position of the graphics elements is so essential when drawing images that is not part of the SVG style definitions but rather is generally included in the SVG elements themselves. Stylesheets can be used for all other style definitions.
In the following sections we look at different aspects of separating style and content. We start with adding simple style definitions to SVG elements, then using classes to add more semantics and grouping to the elements, and binding the style definitions to different media. Finally, we illustrate how SVG allows authors to define their own style effects to be used for fonts, masks, filters, fills, etc. In this way it is often possible to prevent the loss of important information that otherwise would be mixed with style definitions. This also supports the use of non-visual devices.
SVG uses CSS syntax and properties or XSL to specify formatting effects with stylesheets. Stylesheets give the author a means to specify rich presentations, while ensuring that the different presentation-related needs of users can be met (refer to [WCAG], Checkpoint 3.3 and Guideline 3 in general and to Accessibility Features of CSS2[CSS-access]).
Although it is possible to specify styles as attributes of particular elements, or as part of a style element, we have chosen to demonstrate mostly external linked stylesheets. The User Agent Guidelines [WD-UAAG@@] require that a user can select among stylesheets, including user-supplied stylesheets, and with external stylesheets authors and users can more easily try out several different styles as they can supply a set of alternative stylesheets. An external stylesheet or a separate style element helps the author to make style changes to selected elements in one place.
Style rules using element or class selectors are preferred
over the styles based on id attribute selectors which are more
difficult to override by users. The use of classes can be valuable, for
instance if the graphical elements or their combinations have different
semantic meanings (see examples in Section 4.2).
An inline style attribute may not be a very good choice because each
element's style needs to be changed separately. Although this may be managed
for authors by their authoring tools, inline styles are also more difficult to
override by users with disabilities or with restrictions in their environment
or the devices that they are using. This is especially true if the inline
style definitions try to illustrate an implicit semantic grouping of the
elements with no class definitions to support it. (A good clue is
that if a particular set of inline styles is used consistently, that it is
being used to identify a class of objects, and a stylesheet should be used to
provide a single rule for all the objects, selected by a class
attribute.)
In SVG, the default rendering of a graphic elements is a black fill, so without a stylesheet all the presented shapes would be solid black. To avoid that, the previous examples provide a link to the simple stylesheet presented in Example 4.1. It contains simple style definitions for changing the rendering style of graphic elements for rectangles, circles and paths.
Example 4.1: A simple stylesheet for presenting rectangle, circle, and path elements (download stylesheet in 4.1).
rect { fill: white; stroke: black;
stroke-width: 1
}
circle { fill: red; stroke: black;
stroke-width: 1
}
path { fill: white; stroke: black;
stroke-width: 1
}It is also possible to use stylesheets to provide a text or audio rendering
of an SVG image. The content of title and desc
elements may not be rendered at all without a stylesheet definition but when
the following simple CSS stylesheet is used with Figure 2.2, the content
will be presented as text. The style information in Example 4.2 simply defines
that no elements are visible except the title and
desc elements. The g element containing both
title and desc elements is not visible as such.
However, when it contains visible elements it is rendered as a block while the
title and desc elements inside it are by default
inline elements. Furthermore, the title element directly inside
the svg element will be bigger and bolder than the other titles.
The !important is used after each definition to make sure that
other stylesheets will not interfere with this stylesheet. The result can be
seen in figure 2.4.@@ The text may also be rendered as audio by a user
agent.
Example 4.2: A simple
stylesheet to present title and desc elements as
text (download stylesheet in 4.2).
svg { visibility: hidden !important }
title { visibility: visible !important }
desc { visibility: visible !important }
g { display: block !important }
svg > title {
font-size: 120% !important;
font-weight: bolder !important
}To give the user a rough idea of the graphics shapes used in an image we
can use the following stylesheet. It will render the types of common graphics
elements as text in between the title and desc
renderings. We can use the stylesheet, for instance, to give some information
of the graphical shapes of the Hub in Examples 3.1 and 3.2.
With CSS alone we cannot explain where the shapes are located, but it is possible to create specialized players since the necessary information is readily available from the SVG, style and positioning.
Example 4.3: A simple stylesheet with text for graphical shapes (download stylesheet in 4.3).
svg { visibility: hidden !important }
title { visibility: visible !important }
desc { visibility: visible !important }
g { display: block !important }
svg > title {
font-size: 120% !important;
font-weight: bolder !important;
}
rect:before {
visibility: visible;
display: block !important;
content: "rectangle " !important
}
ellipse:before {
visibility: visible;
display: block !important;
content: "ellipse " !important
}
circle:before {
visibility: visible;
display: block !important;
content: "circle " !important
}
path[d ~= z]:before,
polygon:before {
visibility: visible;
display: block !important;
content: "closed shape " !important
}As discussed earlier, with graphic images it is often necessary to use
classes to add semantics that can be used with style definitions. In the next
example we define an image of a computer to be used in the network we have
been building. The image uses a stylesheet which gives styles for the
components of the computer by using their class attributes. In
particular the class outline defines part of the image of each
component as an outline with minimal graphical details. We also define a
component with a class of outline-only (which is not rendered by
the default stylesheet). These classes can be used in stylesheets for
low-resolution devices, including tactile graphic displays and small-screen
devices. It is a good idea to provide a variety of ready-made stylesheets to
cover different user needs (for examle audio rendering). We discuss creating
stylesheets for different devices further in the next section (4.3)
Example 4.4: A computer image (download computer image in 4.4).
<?xml version="1.0"?>
<?xml-stylesheet href="svg-style.css" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN"
"http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450">
<defs>
<symbol id="terminal">
<desc>A common desktop PC</desc>
<g id="monitorStand" transform="translate(35 101)">
<title>Monitor stand</title>
<desc>One of those cool swivelling monitor stands that sit under the monitor</desc>
<rect class="outline-only" width="80" height="20" x="5" y="0" />
<path d="m5 0 S 15 10 45 12"/>
<path d="m85 0 S 75 10 45 12"/>
<path d="m5 20 L 15 10 S 45 12 75 10 L 85 20z"/>
</g>
<g id="monitor" transform="translate(0 -20)">
<title>Monitor</title>
<desc>A very fancy monitor</desc>
<rect class="outline" width="160" height="120"/>
<rect class="screen" width="138" height="95" x="11" y="12" />
</g>
<g id="processor" transform="translate(0 122)">
<title>The computer</title>
<desc>A desktop computer - broad flat box style</desc>
<rect class="outline" width="160" height="60" />
<g id="discDrive" transform="translate(70 8)">
<title>disc drive</title>
<desc>A built-in disc drive</desc>
<rect class="disc" width="58" height="3" x="12" y="8" />
<rect class="light" width="8" height="2" x="12" y="15" />
</g>
<circle cx="135" cy="40" r="5"/>
</g>
</symbol>
</defs>
<g id="Computer" transform="translate(180 85)">
<title>Computer</title>
<use xlink:href="#terminal"/>
</g>
</svg>Figure 4.5: A visual rendering of the computer in Example 4.4
The following stylesheet defines some styles for the computer and its components.
Example 4.6: A stylesheet for the computer image in Example 4.4 (download stylesheet in 4.6).
/* Some style for the computer */
svg {
/* Default styles to be inherited */
fill: white;
stroke: black;
stroke-width: 0.3}
.outline-only {visibility:hidden}
#terminal .outline {
fill: beige}
.computer {
fill: beige}
.light {
fill:lightgreen}The rendering of SVG images can be defined to depend on the media used for presentation. This is beneficial for accessibility as people with disabilities often use assistive technologies. For instance some media, such as screens, are suited to high-resolution graphics, other media, such as braille, to lower resolution graphics, and some people use audio instead of graphics. CSS can be used to provide an appropriate default presentation for all these different devices.
In the following example we expand the stylesheet in the last example (4.6)
to provide a simplified version of the image for low-resolution media, such as
embossed, braille, handheld, or projection devices. The appropriate style
definitions for those devices are selected by using CSS @media
rules [CSS2@@]. Within the simplified version we define that only the text and
the outline of graphics components will be rendered. For this we utilize the
outline and outline-only class elements defined in
Example 4.4. The screen media definitions contain the default style
definitions presented earlier in Example 4.5.
Example 4.7: Extending stylesheet in Example 4.5 for different media (download full stylesheet in 4.7).
/* some style for low-resolution media */
@media embossed, braille, handheld {
svg { visibility: hidden }
.outline, .outline-only {
visibility: visible;
fill: none;
stroke: black;
stroke-width: 5
}
text { visibility: visible }
}
@media screen {
/* Some style for the computer */
} The following example uses a font named BaseTwelve to create the W3C logo.
Example 4.8: Using text and fonts to form an image of W3C logo (download W3C logo in 4.8). @@image and download differ - download works but has W3CC @@
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN"
"http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd">
<svg width="1.5in" height="1in" viewBox="0 0 150 100">
<defs>
<mask id="shadowMask">
<text class="masktext" transform="translate(-3,-4)">C</text>
</mask>
<style type="text/css">
svg { font:BaseTwelve; font-size:45; stroke-width:1 }
.w3crect { fill:white; stroke:none }
.w3cline { fill:black; stroke:black }
.bluetext { fill:blue; stroke:blue }
.masktext { fill:white; stroke:white }
.shadowtext { fill:black; stroke:black;
mask: url(#shadowMask)}
</style>
</defs>
<g id="w3clogo" transform="translate(10,10)scale(1.2)">
<title id="logotitle">W3C</title>
<rect class="w3crect" x="-2" y="0" width="80" height="59"/>
<g transform="translate(0,47)">
<desc>blue W and 3 and white C with a shadow</desc>
<text>
<tspan class="bluetext">W3</tspan>
<tspan class="shadowtext">C</tspan>
</text>
</g>
<g transform="translate(-2,0)">
<desc>line below and on top of W3C</desc>
<path class="w3cline" d="M0,0H80"/>
<path class="w3cline" d="M0,59H80"/>
</g>
</g>
</svg>| a) |
b) |
If the user does not have the BaseTwelve font then another (in this case system default) font will be used to render the text. Because the font is referenced from a CSS style declaration a user can also easily override it. Of course since this is an XML document a stylesheet can also be used to render the content (the letters "W 3 C") as a text-based presentation.
Often a particular font that users are not likely to have will be desired
for a logo. In SVG a new font can be defined by using the font
element. The following example defines a font named w3clogofont. It includes
the glyphs for the characters W, 3, and C. Each glyph element has a
human-readable title, and the letter C has a description of the special effect
provided for it.
Note that in the previous code example, the special shadow effect was defined with a mask, whereas in the following example the character is defined directly. Authoring tools may choose to use either method for SVG fonts, depending on performance considerations. However it is important that the text content is in fact the required text - it would be possible to get the mask effect by placing a white "C" over the black one, but the text content would then be W3CC which is wrong. Use of SVG fonts allows designers to create very sophisticated or individual fonts while keeping the content as text.
Example 4.10: Defining a special font for the W3C logo (download W3C logo in 4.10).
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN"
"http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd">
<svg width="1.5in" height="1in" viewBox="0 0 150 100">
<defs>
<style type="text/css">
svg { font:w3clogofont; font-size:45; stroke-width:1 }
.w3crect { fill:white; stroke:none }
.w3cline { fill:black; stroke:black }
.bluetext { fill: rgb(0,90,156); ;stroke:rgb(0,90,156); }
.whitetext { fill:white; stroke:white }
.shadowtext { fill:black; stroke:black}
glyph { fill: rgb(0,90,156) }
</style>
<font>
<font-face id="w3clogofont" units-per-em="55"
cap-height="39.604" x-height="25"
ascent="23" descent="12"
baseline="0" centerline="20"
topline="43" mathline="20" horiz-adv-x="2"
ideographic="5" hanging="0" />
<desc>w3clogofont</desc>
<missing-glyph>
<text>*</text>
</missing-glyph>
<glyph unicode="W" horiz-adv-x="39.1157">
<title>W</title>
<path d="M 19.8022,0 L 26.8921,24.105 33.9819,0 39.1157,0
L 27.3809,39.604 26.8921,39.604 19.5576,15.0596
L 12.2236,39.604 11.7349,39.604 0,0 5.13379,0
L 12.2236,24.105 17.0151,7.87262 14.6685,0z"/>
</glyph>
<glyph unicode="3" horiz-adv-x="19.9981">
<title>3</title>
<path d="M 19.9981,26.893
C 19.9981 30.479 19.0445 33.494 17.1377 35.938
C 15.2305 38.383 12.7613 39.604 9.73001 39.604
C 19.3457 21.466 19.9981 23.992 19.9981 26.893z"/>
<!-- (note that some path data has been removed from this example) -->
</glyph>
<glyph unicode="C" horiz-adv-x="20.416">
<title>C</title>
<desc>the shadow of a raised letter C</desc>
<path d="M 19.306,0
C 19.306 0 20.138 5.05597 20.138 5.05597
C 20.138 5.05597 17.194 10.688 17.194 10.688
C 19.953 33.412 20.416 32.513 20.416 32.513z"/>
<!-- some more path data ... -->
</glyph>
<hkern u1="W" u2="3" k="4.207"/>
</font>
</defs>
<g id="w3clogo" transform="translate(10,10) scale(1.2)">
<title id="logotitle">W3C</title>
<rect class="w3crect" x="-2" y="0" width="80" height="59"/>
<g transform="translate(0, 47)">
<desc>W3C logo</desc>
<text>
<tspan class="bluetext">W3</tspan>
<tspan class="shadowtext">C</tspan>
</text>
</g>
<g transform="translate(-2,0)">
<desc>line below and on top of W3C</desc>
<path class="w3cline" d="M0,0H80"/>
<path class="w3cline" d="M0,59H80"/>
</g>
</g>
</svg>In this way the possible style definitions can be easily extended. Although it is possible to mix graphic content with definitions of style effects in a single document, they can still be clearly separated in parsing and processing the information, as required by Web Content Accessibility Guidelines [WCAG] Checkpoint 3.3. In the following example we refine the image of a computer, adding more powerful stylistic effects that are written in SVG but used from a stylesheet in the rendering process. This means a user can override the effects with another stylesheet if required, as discussed above@@. In this example we have defined the gradient effects in a separate document, although it is also possible to define them within the image that they are first used in. In either case, they can then be re-used in many documents, in the same way as a stylesheet or a known graphic component, and known patterns can be used by an author who may have great difficulty in creating them visually
Example 4.11: Defining some style values (download style values in 4.11).
<?xml version="1.0"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN"
"http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450">
<defs>
<radialGradient id="screenGrad" cx="0" cy="0" r="200">
<stop class="s100" offset="100%"/>
<stop class="s0" offset="0%"/>
</radialGradient>
<linearGradient id="discGrad">
<stop class="s100" offset="100%"/>
<stop class="s0" offset="0%"/>
</linearGradient>
</defs>
</svg>The following stylesheet (an extended version of the one in Example 4.7) uses the gradients we have defined to provide additional style for the computer in Example 4.4.
Example 4.12: An alternative stylesheet for the computer image in Example 4.4 (download stylesheet in 4.12).
/* Some style for the computer */
#screenGrad .s100 {stop-color:#AAA9A9 }
#screenGrad .s0 {stop-color:black }
#discGrad .s100 {stop-color:beige }
#discGrad .s0 {stop-color:black }
svg {
/* Default styles to be inherited */
fill: white;
stroke: black;
stroke-width: 0.3}
.outline-only {visibility:none}
#terminal .outline {
fill: beige}
.computer {
fill: beige}
.screen {
fill: url(http://www.w3.org/1999/09/SVG-access/style-values#screenGrad)}
.disc {
fill: url(http://www.w3.org/1999/09/SVG-access/style-values#discGrad)}
.light {
fill:lightgreen}
Users must be able to use all the available functionality of a multimedia document regardless of the physical characteristics of the user agent or assistive technology used. In particular, the User Agent Accessiblity Guidelines [WD-UAAG] require that the user can activate all the active elements in a document. SVG supports the use of the Document Object Model (DOM) and device-independent events, and they are highly recommended.
SVG also supports declarative definition of animations. These offer users better means to understand what is being changed and how than the use of scripting languages, such as Javascript or ECMAscript. For instance, it is easier to ensure that a user can turn off animations while still being presented with appropriate content, which is important for accessibility.
Finally, the users should be able to interact with links and other navigation means embedded in the SVG images either serially, by using text equivalents, or spatially with more visual means.
SVG uses the new event set provided in DOM 2 [DOM],
which supports device-independent interactive content. This allows authors of
SVG to to ensure that interactive content does not rely on a user having a
particular type of device. Good authoring practice will normally use the
focusin, focusout and activate events
rather than the device specific events for gaining and losing the focus on an
element or activating the element. For instance, in the following example the
animation is triggered by an activate event, using different
parameters for different types of activations. Device-independent scripting is
required by Web Content Accessibility Guidelines [WCAG] checkpoints 9.3 and 6.4.
An accessible user agent will allow the triggering events to be generated from a mouse or other pointer device (where available) as well as from a keyboard. According to the User Agent Accessibility Guidelines [WD-UAAG], guideline 1 and especially checkpoint 1.1, user agents must provide device-independent ways of activating all application functions. A text-based system that renders the descriptions for the animations could provide a "context menu" listing available actions to the user. Another possibility is that a user agent could add links to the descriptions of animation effects in a textual rendering of an SVG image.
Animation can easily clarify some things in a presentation or add eye
catching movement to highlight some issues. But animation may also prevent
users from reading adjacent information in the page, and animations with a
certain refresh rate can trigger discomfort or seizures in users with
photosensitive epilepsy. Users may also have difficulties in making
selections fast enough if they are embedded in the animation. Therefore
animations need to be designed carefully so that they do not affect
accessibility or usability of the presentation. For instance, until user
agents allow the user to freeze or control the rate of an animation (refer to
[WCAG] , Checkpoints 3.5, 3.6 and 3.8, and guideline
3 in general), authors should ensure that users can pause or stop moving
content (refer to [WCAG], Checkpoint 7.3, and
guideline 7 in general). Note that it is a user agent responsibility to
provide this functionality, rather than primarily an authoring responsibility.
SVG also provides means, such as the switch element, to control
the rendering of images containing animation for static media such as
print-output devices. We discuss switch in section 7, below.
The animation model in SVG has been jointly developed by the SVG and the Synchronized Multimedia (SYMM) working groups, and is based on the SMIL-Boston animation specification [SMIL-animation]. The model offers a declarative approach for creating dynamic Web content. In many cases, this is simpler to understand and use than the programmatic model used in scripting languages such as ECMAscript or Javascript, when a non-graphic presentation is required. The animation model aims to allow user agents to provide information about what an animation is supposed to do even when the rendering device or environment does not have the media capabilities presumed by the author.
Because SVG is XML it provides user agents with Document Object Model
(DOM), as discussed in Section 7. The animate elements are
included in the DOM, and are therefore directly accessible to User Agents. As
the animation effects do not produce any changes in the DOM, the presentation
related to animations can be handled separately. A non-visual renderer can
interpret the declarative description of the animation and render it in the
most appropriate manner. The User Agent Accessibility guidelines require that
a user agent provide assistive technology with access to the DOM, so assistive
technologies can also provide an appropriate presentation of the animation
effect when used in conjunction with an SVG browser.
In the following example we use animation to highlight the path of messages
from Computer A to the outside world, or between computer A and computer B.
For some components we are animating style properties of the components. But
for some we want to also update the text equivalents, so we define two symbols
with different desc elements and class attributes,
and the animation effect swaps between them.
Figure 5.1: Animations when computer A is activated (download network animation in 5.1). @@changed the download, need to update here@@
<?xml version="1.0"?> <?xml-stylesheet href="http://www.w3.org/1999/09/SVG-access/svg-style" type="text/css"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN" "http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd"> <svg width="6in" height="4.5in" viewBox="0 0 600 450"> <title id="mainTitle">Network</title> <desc>An example of a computer network based on a hub</desc> <!-- define symbols with class and descriptions to be animated --> <defs> <symbol id="CableA"> <desc>A 10BaseT ethernet cable</desc> <!-- Draw Cable A. --> <path d="M107,88c100,140 50,140 -8,160"/> </symbol> <symbol id="activeCableA"> <desc>The 10BaseT ethernet cable is active</desc> <!-- Draw Cable A highlighted --> <path class="highlight" d="M107,88c100,140 50,140 -8,160"/> </symbol> <!-- (and similarly for the other cables) --> </defs> <!-- animation to illustrate messages travelling to the outside net--> <animate xlink:href="#ComputerA" attributeName="class" to="highlight" begin="id(ComputerA).(activate(2))" dur="2s" fill="remove"/> <animate xlink:href="#CableAref" attributeName="xlink:href" to="#activeCableA" begin="id(ComputerA).(activate(2))(+2s)" dur="2s" fill="remove"/> <animate xlink:href="#hub" attributeName="class" to="highlight" begin="id(ComputerA).(activate(2))(+4s)" dur="2s" fill="remove"/> <animate xlink:href="#CableNref" attributeName="xlink:href" to="#activeCableN" begin="id(ComputerA).(activate(2))(+6s)" dur="2s" fill="remove"/> <!-- illustrate messages travelling between computer A and B --> <animate xlink:href="#ComputerA" attributeName="class" to="highlight" begin="id(ComputerA).(activate)" dur="2s" fill="remove"/> <!-- and so on --> <!-- Draw text. --> <text x="0" y="-10"> <tref xlink:href="#mainTitle"/> </text> <!-- Use the hub image and its title and description information. --> <g id="hub" transform="translate(180 200)"> <image xlink:href="hub.svg"/> </g> <!-- Use an external computer symbol. Scale to fit. --> <g id="ComputerA" transform="translate(20 170)"> <title>Computer A</title> <use xlink:href="computer#terminal" transform="scale(0.5)"/> </g> <!-- (Use the same computer symbol again for computer B) --> <g> <title>Cable A</title> <use id="CableAref" xlink:href="#CableA" width="600" height="450"/> </g> <!-- (and similarly for the other cables) --></svg>
With SVG it is easy to add links to the various parts of the images. This
is done by including the graphics component inside an a element.
The a element should include an xlink:title
attribute that explains the target of the link and appropriate title
and a desc elements that describe the graphical object
that is being linked to the target. The textual explanations are very
important for the users with blindness or low vision as they often navigate
through the document by moving from link to link and reading the link text or
its text equivalent. It is therefore important that the link (and its text
equivalent) make sense on its own (refer to [WCAG],
Checkpoint 13.3). Unless SVG User Agents make this textual information
available, authors will need to include text-based links to content as well
(refer to [WCAG] checkpoint 1.5, although this
should not apply to newer user agents such as those designed for SVG).
Users relying heavily on visual information, such as some users with cognitive disabilities, may need also the graphical links to be easily identified by visual means. For graphical links there is no default highlighting convention as underline is for textual links. These may be highlighted by expanding the size or color of the linked component, or adding a graphic mark near the component. We may also highlight the component only when it gets focus or when the user asks to see the links. Authors and user agents should aim for consistency when offering default highlighting styles. It is also important that users can easily change the highlighting according to their needs. This can be provided in user agents by implementing the relevant stylesheet features, for example in CSS [CSS].
As many users who cannot use a pointing device navigate through links in serial order they need to be able to create a good mental model of the structures and shortcuts that make navigation more effective (refer to [WCAG], Checkpoints 13.4, 13.5, and Guideline 3 in general). Such users will benefit if the links can be traversed in an order that corresponds to the graphic structure, or if links related to a certain structure (for example all the buttons included in a cockpit radio panel) are grouped and can be easily skipped(refer to [WCAG], Checkpoint 13.6).
switch
element using requiredFeatures or systemLanguage
attributes. The following example tests whether a system supports animation,
and if not provides an alternative explanation of how the network passes
messages. The systemLanguage attribute could be used instead (or
as well) to provide multiple versions of text according to the language, or to
provide a sign-language version of descriptive text.
Figure 6.1: Providing alternative content
with switch element (download whole
network in 6.1). @@image and download NOT updated - does NOT work - check
also corrections made to animation example@@
<?xml version="1.0"?>
<?xml-stylesheet href="http://www.w3.org/1999/09/SVG-access/svg-style" type="text/css"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000629//EN"
"http://www.w3.org/TR/2000/WD-SVG-20000629/DTD/svg-20000629.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450">
<title id="mainTitle">Network</title>
<desc>An example of a computer network based on a hub</desc>
<!-- define symbols to be animated -->
<defs>
<symbol id="CableA">
<!-- (and the rest of the symbols) -->
</symbol>
</defs>
<switch>
<g requiredFeatures="org.w3c.svg.dynamic">
<!-- If this is a dynamic player provide an animation effect to highlight
messages travelling to the outside world-->
<animate xlink:href="#ComputerA" attributeName="class"
to="highlight" begin="id(ComputerA).(activate(2))"
dur="2s" fill="remove"/>
<!-- the rest of the animation is cut out -->
</g>
<g>
<!-- Otherwise provide a different form of the same content
that is suitable e.g. for a mobile client with
fixed software or hardware capability.
For instance, some explanatory text or links. -->
</g>
</switch>
<!-- Draw text. -->
<text x="0" y="-10">
<tref xlink:href="#mainTitle"/>
</text>
<!-- Use the hub image and its title and description information. -->
<g id="hub" transform="translate(180 200)">
<image xlink:href="hub.svg"/>
</g>
<!-- (and the rest of the network image) -->
</g>
</svg>All markup languages written in XML automatically have some accessibility benefits. This is true also with SVG. In this section we explain how these features of XML can be used to increase the accessibility of SVG documents.
The more information the author can provide of an SVG image and its components the better it is for accessibility. Adding metadata to a document can help the user in searching for information, for example documents with a suitable accessibility rating. In this case we have used it to describe the image further - although reading the XML structure shows that the network consists of a hub, some cables and some computers, it does not explain which are connected to which. We have included an automatically generated image of the relationships described by the metadata - the same information can be generated by an assistive technology. Combining the information with the equivalent alternatives included in the image can be used to provide a navigable, described network in text, audio, or even using substituted icons (refer to Web Content Accessibility Guidelines [WCAG] Checkpoint ?.?). The following example uses XML namespaces [NAMESPACE] and the Resource Description Framework [RDF] to add some metadata about the cables connecting the computers and the hub to the earlier network image.
Example 7.1: Additional metadata for the Network and its components (Download complete SVG from example 7.1).
<?xml version="1.0"?>
<?xml-stylesheet href="http://www.w3.org/1999/09/SVG-access/svg-style" type="text/css"?>
<svg width="6in" height="4.5in" viewBox="0 0 600 450"
xmlns="http://www.w3.org/2000/svg-20000629">
<metadata>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:connect="http://www.w3.org/1999/08/29-svg-connections-in-RDF">
<rdf:Description about="#CableN">
<connect:ends rdf:resource="#socket5"/>
<connect:ends>Everything</connect:ends>
</rdf:Description>
<rdf:Description about="#CableA">
<connect:ends rdf:resource="#socket1"/>
<connect:ends rdf:resource="#ComputerA"/>
</rdf:Description>
<rdf:Description about="#CableB">
<connect:ends rdf:resource="#socket2"/>
<connect:ends rdf:resource="#ComputerB"/>
</rdf:Description>
<rdf:Description about="#hub">
<connect:ends rdf:resource="#socket1"/>
<connect:ends rdf:resource="#socket2"/>
<connect:ends rdf:resource="#socket3"/>
<connect:ends rdf:resource="#socket4"/>
<connect:ends rdf:resource="#socket5"/>
</rdf:Description>
</rdf:RDF>
</metadata>
<title id="mainTitle">Network
<desc>An example of a computer network based on a hub
<!-- Draw text. -->
<text x="0" y="-10">
<tref xlink:href="#mainTitle"/>
</text>
<!-- Use the hub image and its title and description information. -->
<g id="hub" transform="translate(180 200)">
<image xlink:href="http://www.w3.org/1999/09/SVG-access/hub"/>
</g>
<!-- Use an external computer symbol. Scale to fit. -->
<g id="ComputerA" transform="translate(20 170)">
<title>Computer A</title>
<use xlink:href="http://www.w3.org/1999/09/SVG-access/computer#terminal" transform="scale(0.5)"/>
</g>
<!-- And so on to add the rest of the network... -->
</svg>Figure 7.2: A graphic representation of the metadata that has been added. It shows the connections between the various elements, so it is possible to trace the links from any one component to the others.
The SVG specification allows the use of XML namespaces [NAMESPACE] to introduce elements from other XML languages. In
particular, the text, title and desc
elements contain structured content, which can be marked up using
extension to the SVG DTD or using another namespace. In the following example
we include some SMIL to provide richer descriptions of the image in Figure 5.1
(the example assumes that a stylesheet provides positioning for the
textstream).
Figure 7.3: An example of mixing namespaces to provide rich multimedia alternative equivalents.
<?xml-stylesheet href="http://www.w3.org/1999/09/SVG-access/svg-style" type="text/css"?>
<svg width="6in" height="4.5in" viewBox="0 0 600 450"
xmlns="http://www.w3.org/2000/svg-20000629">
<!-- define descriptions to be animated -->
<title id="mainTitle">Network</title>
<desc>An example of a computer network based on a hub
<smil xmlns="http://www.w3.org/TR/REC-SMIL/">
<par>
<audio src="describe.au" title="The network described in audio"/>
<textstream src="describe.ts" title="how the network works"/>
</par>
</smil>
</desc>
<!-- Draw text. -->
<text x="0" y="-10">
<tref xlink:href="#mainTitle"/>
</text>
<!-- Use the hub image and its title and description information. -->
<g id="hub" transform="translate(180 200)">
<image xlink:href="hub.svg" width="600" height="450"/>
</g>
<!-- Rest of the example is cut out. -->
</svg> SVG supports a Document Object Model [SVG-DOM] which provides a standard interface (API) to examine and manipulate document structure. It can be used by various tools and technologies. DOM is particularly beneficial to assistive technologies as they are often used in conjunction with "standard" tools e.g. user agents utilizing DOM. For example, a screenreader which provides voice output from a variety of applications can be customized to take advantage of the DOM interface. This can provide better access than would be possible if it were relying entirely on the standard rendering engine (perhaps a graphics editor, or a browser plug-in) for getting the data. An assistive technology can also use the DOM interface to change an SVG image to suit the needs of a user. Note that the User Agent Accessibility Guidelines require that user agents implement the DOM and export interfaces to assistive technologies (refer to [WD-UAAG], Checkpoint 1.3, and Guidelines 1, and 5 in general ). See also section 5.2 on accessible events - these are inherited from the DOM 2 specification [DOM].
The SVG specification itself provides benefits to accessibility. It requires conformance to accessibility guidelines as part of conformance for tools. It also provides an appendix on accessibility [SVG-access].
The first source for information about SVG is the specification itself [SVG]. In addition, the public Web page of the W3C SVG working group [SVG-page] is a good source of information, including articles and papers about SVG, news of implementations, etc.
W3C's Web Accessibility Initiative (WAI) addresses accessibility of the Web through five complementary activities that:
WAI's International Program Office enables partnering of industry, disability organizations, accessibility research organizations, and governments interested in creating an accessible Web. WAI sponsors include the US National Science Foundation and Department of Education's National Institute on Disability and Rehabilitation Research; the European Commission's DG XIII Telematics Applications Programme for Disabled and Elderly; Government of Canada, Industry Canada; IBM, Lotus Development Corporation, Microsoft, and Verizon. Additional information on WAI is available at http://www.w3.org/WAI.
The W3C was created to lead the Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. It is an international industry consortium jointly run by the Laboratory for Computer Science (LCS) at Massachusetts Institute of Technology (MIT) in the USA, the National Institute for Research in Computer Science and Control (INRIA) in France and Keio University in Japan. Services provided by the Consortium include: a repository of information about the World Wide Web for developers and users; reference code implementations to embody and promote standards; and various prototype and sample applications to demonstrate use of new technology. In July 2000, 433 organizations are Members of the Consortium. For more information about the World Wide Web Consortium, see http://www.w3.org/.
Examples of assistive technologies that are important in the context of this document include the following:
Beyond this document, assistive technologies consist of software or hardware that has been specifically designed to assist people with disabilities in carrying out daily activities, e.g., wheelchairs, reading machines, devices for grasping, text telephones, vibrating pagers, etc.
The following people have contributed directly to the content of this document:
Judy Brewer, Dan Brickley, Daniel Dardailler, Jon Ferraiolo, Ian Jacobs, Chris Lilley, Eric Prud'hommeaux, Ralph Swick, Dave Woolley. We have also drawn on the work and feedback of the SVG Working Group and the WAI Protocols and Formats Working Group