I’ve been dipping my toes into Scalable Vector Graphics (SVG) lately and wondering how this can be made accessible and usable for all. It seems like a very under used technology which is a pity given it’s potential to be more readable by assitive technologies such as screen readers, braille displays and screen magnification than other graphicy type solutions.

The W3C describes SVG is a relatively simple way to generate graphics on a web page using markup:

SVG is a platform for two-dimensional graphics. It has two parts: an XML-based file format and a programming API for graphical applications. Key features include shapes, text and embedded raster graphics, with many different painting styles. It supports scripting through languages such as ECMAScript and has comprehensive support for animation.

SVG is supported in all modern browsers – with the exception of Internet Explorer – including most mobile browsers making it an excellent cross platform bit of bling. Even the lack of support in IE could be addressed soon not by Microsoft itself but by Google who are billed to give a keynote at the SVG Open in October on their SVG for IE drop-in library. This could boost the popularity of SVG given that to date IE has been one of the biggest things holding it back.

Update 22 August 2009: Announcement about Google’s 60K library to bring SVG, SMIL, video, audio to IE.

The real bonus of SVG however is it’s scalability, integration with web standards, re-usability and ability to manipulate objects all of which lend SVG to being a robust – and crucially – accessible alternative to other image based formats such as GIF, PNG or JPEG.

SVG graphics can be scaled and resized without any of the blurring or pixellation that you see on traditional images. Scaling is important to users with low vision who enlarge text in the browser or rely on assistive technologies such as tactile graphic devices (which typically have a very low resolution) and screen magnifiers. So if you want to have images of text as headings and not worry about these becoming blurred and unreadable you can. As the image below shows, the enlarged PNG is pixellated whereas the SVG equivalent is smooth and crisp.

Comparison of PNG and SVG enlargements taken from Accessibility Features of SVG by Charles McCathieNevile and Marja-Riitta Koivunen

Comparison of PNG and SVG enlargements taken from Accessibility Features of SVG by Charles McCathieNevile and Marja-Riitta Koivunen

XML, being a text based language, also lends SVG to better accessibility than current headline grabbers such as HTML5 canvas which lacks an accessibility API or hooks for screen readers. While the WHAT-WG currently recommend a fallback – a draconian circa 1999 HTML alternative that confines screen reader users to a disability ghetto – they are working on a “built in” rather than “bolt on” approach asking for input from the accessibility community for viable solutions to make canvas accessible. Bruce Lawson has the lowdown on SVG versus canvas in his post  Canvas, accessibility and SVG.

SVG and screen readers

While SVG supports many of the accessibility guidelines that we see in WCAG 2.0 and is supported by all modern browsers except IE, there is one drawback: screen readers do not handle SVG well.

It’s hard to say why. As Bruce Lawson pointed out it may be because “big screen readers have traditionally sat on top of Internet Explorer”. I think it may also be because screen reader vendors have an awful lot to keep abreast of out there with regards to browser compatibility, emerging technologies such as ARIA, developments in HTML5 as well as compatibility with software such as MS Office, Open Office, Flash, PDF etc. Google’s promise of fixing SVG in IE should have some positive knock on effects – or at least let’s hope.

Screen readers not being able to handle SVG well is no reason to not make your SVG screen reader ready however. As always you want to be thinking about future proofing so as to avoid any pesky and costly retrofits at a later date.

Title and descriptions

The title and desc elements can be added to any graphic to provide a fallback for screen readers. These can be added to parts of the graphic – hierarchically – or the graphic as a whole. Both title and desc can be used together with the former acting as the title of the graphic and the latter as as expanded explanation (from what I’ve understood anyway). If the image above of the tigers was created in SVG you’d code it as follows:

<?xml version="1.0"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000802//EN" "http://www.w3.org/TR/2000/CR-SVG-20000802/DTD/svg-20000802.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450"
xmlns="http://www.w3.org/2000/svg"  xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Tiger's head</title> <desc>A slinky SVG tiger</desc>

According to the spec however the title element in SVG may behave a little differently to how the title attribute behaves in HTML:

Each container element or graphics element in an SVG drawing can supply a ‘desc’ and/or a ‘title’ description string where the description is text-only. When the current SVG document fragment is rendered as SVG on visual media, ‘desc’ and ‘title’ elements are not rendered as part of the graphics. User agents may, however, for example, display the ‘title’ element as a tooltip, as the pointing device moves over particular elements. Alternate presentations are possible, both visual and aural, which display the ‘desc’ and ‘title’ elements but do not display ‘path’ elements or other graphics elements. This is readily achieved by using a different (perhaps user) style sheet. For deep hierarchies, and for following ‘use’ element references, it is sometimes desirable to allow the user to control how deep they drill down into descriptive text.

While desc is not displayed (in accordance to the spec) it is up to the browser to decide how to render the  title element in SVG. In other words it can either be displayed as a ‘tooltip’ or not. Using Opera 10 Beta 2  title is shown as a ‘tooltip’, but neither Safari 4.01 Firefox 3 display the ‘tooltip’.

The closet match to the behavior of the title attribute in HTML in SVG is <a href="http://www.w3.org/TR/2008/WD-SVGMobile12-20080915/linking.html#XLinkTitleAttribute">xlink:title</a>.

The title attribute shall be used to describe the meaning of a link or resource in a human-readable fashion, along the same lines as the role or arcrole attribute. A value is optional; if a value is supplied, it shall contain a string that describes the resource. In general it is preferable to use a ‘title’ child element rather than a ‘title’ attribute. The use of this information is highly dependent on the type of processing being done. It may be used, for example, to make titles available to applications used by visually impaired users, or to create a table of links, or to present help text that appears when a user lets a mouse pointer hover over a starting resource.

A link with a title attribute in HTML would look like this:

<a href="http://www.mysite.com" >visit my site</a>

Where as a link in SVG would look like this:

<a xlink:href="http://www.mysite.com" xlink:><text x="20" y="20">visit my site</text></a>

In the above the x and y value are the co-ordinates where the text is placed on the canvas. To ensure this works you have to declare the XLink namespace in the document, most commonly in the SVG root element.

One important thing to note is that the ‘a’ element can be wrapped around elements in SVG, a little like block level linking in HTML5. This is a great feature as it allows for a larger clickable area for those that need it and you can wrap as many components in the link – let’s say a graphic with accompanying text – as you like.


Just as you would give an HTML page a hierarchical order the same is true of SVG. This allows a non-sighted user to build a mental map of the graphic and is founded on WCAG 1.3.2 Meaningful sequence.

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

Expanding on the tiger image above and adding in all four images into one would mean the code looked as follows:

<?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20000802//EN" "http://www.w3.org/TR/2000/CR-SVG-20000802/DTD/svg-20000802.dtd">
<svg width="6in" height="4.5in" viewBox="0 0 600 450"
xmlns="http://www.w3.org/2000/svg"  xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Tigers</title> <desc>Drab PNG tigers and slinky SVG tigers</desc>
<!-- add graphic content here, and so on for the other components-->
<g id="Tigera"> <title>Tiger A</title> <desc>A small tiger  using PNG</desc> </g>
<g id="Tigerb"> <title>Tiger B</title> <desc>A small tiger using PNG</desc> </g>
<g id="Tigerc"> <title>Tiger C</title> <desc>A large tiger using PNG</desc> </g>
<g id="Tigerd"> <title>Tiger D</title> <desc>A large tiger using SVG</desc> </g>

You’ll notice in the above that the ‘g’ element is used to structure the document.  This is basically a container element that is used to group related graphics. ‘g’ elements can also appear within ‘g’ elements.

Grouping constructs, when used in conjunction with the ‘desc’ and ‘title’ elements, provide information about document structure and semantics. Documents that are rich in structure may be rendered graphically, as speech, or as braille, and thus promote accessibility.


The basic rule of accessible colour apply to SVG just as they would any other image. In other words don’t rely on colour alone to convey meaning or use colour that lacks contrast. This falls in line with WCAG 2.0:

1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)


1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

Mark up and CSS

Again familiar rules that apply to HTML and CSS also apply to SVG:

  • Ensure your SVG validates to SVG RelaxNG grammar however some discussions suggest to do so without the doctype.
  • Separate structure from presentation.
  • Use text for text and not graphics.
  • Provide as much structure and alternatives as possible using the g, title and desc.
  • Style text using fonts not images.
  • Use ‘xml:lang‘ to identify the natural language of content and changes in natural language. This ensures that textual content can be spell-checked, or converted to speech.


ARIA describes how to add semantics and other metadata to HTML content in order to make user interface controls and dynamic content more accessible. In principle this is also applicable SVG and as such SVG 1.2 recommends ARIA for adding in accessibility hooks for screen readers via the ‘role’ attribute.

The ‘role’ attribute assigns one or more role values to an element which in turn can get fed back to a screen reader. ARIA 1.0 is currently in Last Call (the stage before it becomes a W3C Recommendation) and is expected to be published soon. While the SVG 1.2 specification recommends using roles, ARIA 1.0 itself is not massively focused on SVG. According to the Protocols and Formats Working Group however SVG will feature more in ARIA 2.0 (along with extensibility, live regions and HTML5 support).  Erik Dahlstrom, co-chair of the SVG Working Group, has provided feedback around SVG and ARIA including comments on managing focus, accessible name calculation,  navigation and more.

While it is clear there is a lot of work to be done the fact that ARIA roles can be used is a positive step forward as it acts as a bridge where screen reader support falls short.  Jaws, WindowEyes, NVDA, FireVox and Orca are all adding support for ARIA as is IE, FireVox, Opera and Safari (Codetalks has a list of who supports ARIA) so if thinking about adding ARIA to your SVG now is clearly a wise move.

So just how accessible is SVG?

Clearly a lot of work needs to be done to get SVG accessibility ready for screen readers. Some hooks are there however the real work is yet to come both from screen reader vendors as well as the specification writers. What’s reassuring is that both the ARIA and SVG camps recognise this and there is talk of SVG having a bigger focus in ARIA 2.0.

Putting screen readers aside there are clear benefits to SVG for screen magnification users with it being scalable, standards compliant and able to provide block level linking. The standards aspect of this is important as it means that you can use XSLT to transform SVG into HTML – readable by all assistive technology.

Accessible SVG has a potential – despite it being early days – as a useful alternative for canvas and other image formats. Who knows, with possible IE support on the horizon and more of a focus in Aria 2.0 perhaps screen reader vendors will step up efforts to support SVG. If they do as have a really robust technology out there to add to the developers toolbox.

For more check out:

Resources published after this blog post

Below are some more recent articles and work relating to accessible SVG: