WebAIM - Web Accessibility In Mind

Future Web Accessibility: SVG

This is the fifth in a multipost series about the immediate and likely future of web accessibility. Each week or so I’ll discuss a different upcoming technology, tag, platform, or system from an accessibility perspective. Additions, corrections, or further thoughts are welcome in the comments.

Previous posts: HTML5 <video>, HTML5 Semantic Elements, New <input> Types in HTML5, HTML5 <input> Extensions.

Scalable Vector Graphics

SVG—the W3C’s specification for XML-based vector graphics—has been completed since 2001, but never achieved widespread usage, largely because of incomplete browser support and complexities with using it in HTML (as opposed to XHTML) documents. With the advent of HTML5 (through which SVG graphics can finally be included directly in HTML) and the forthcoming release of Internet Explorer 9 (for which Microsoft has promised SVG support), both of the above mentioned problems could soon be resolved, and as a result interest in SVG has increased significantly as of late.

Browser Support

All major web browsers but Internet Explorer have had some level of SVG support for several years now. However, each implements a different subset of the spec—no browser (that I know of) has complete support for the full SVG syntax. Internet Explorer does not currently have any native SVG support at all, but should in their next major release. Thus, assuming a significant percent of current Internet Explorer users upgrade to the new version quickly (which isn’t likely, but we can always dream), SVG (or at least the main parts of it) should be widely supported on the open web within a few years.


Unlike many of the newer HTML5 technologies, SVG actually has a fairly large and well thought out accessibility component. The W3C has a short list of accessibility points for SVG, and a much longer document explaining the concepts in more detail.

Text Alternatives

The alternative text model of SVG is similar to that of normal web images: simple graphics can contain a short title (which may be rendered by web browsers as a tooltip—the distinction between alt text and the title doesn’t exist in SVG) and a longer description (which normally won’t be displayed by a browser, but should be made available to assistive technologies). More complex graphics can be written in a hierarchical way (that is, with nested tags corresponding to the logical or visual components and subcomponents of the graphic) where each important piece or component of the item being represented can have its own title and description. In addition to this, the SVG spec allows linking to some other type of content (such as RDF data) that contains important information from the SVG image in a more accessible format. With the possible exception of some really complex stuff that maybe shouldn’t be a single image anyway, this should be sufficient to make most SVG graphics as accessible as could be expected given the circumstances.

That’s the good news. The bad news is that all the alternative text capability in SVG isn’t any of use if there isn’t support for it in common assistive technologies, and at the present time that support doesn’t really exist. We can expect that, if SVG finally sees widespread use on the open web, the AT vendors will eventually add support for accessible SVG, but in the mean time web authors would be best advised to provide any necessary alternative text in a parallel, SVG-independent way.

“Extreme” SVG

One of the reasons no browser vendor has yet to implement all of SVG is that “all of SVG” is a lot of stuff, including its own components for links and scripting (each of which is similar, but not identical to, the equivalent in (X)HTML. This creates the ability to do things in SVG that have nothing to do with vector graphics at all, such as building faux form widgets, or even writing an entire website as one massive SVG document. While these “creative” uses of the new technology might be fun or convenient, websites that use them risk losing out on some of the default native accessibility support available in the “real” (i.e., HTML) components being emulated with graphics. ARIA roles and states could (if used) solve some of these problems, but other issues may be more subtle, and could depend on the user agent being used.

For example, current versions of Firefox support the ability to embed links in SVG graphics, and even make them keyboard navigable. However, those links (unlike actual HTML links) do not by default have any sort of focus indicator displayed, making it nearly impossible for sighted users to actually use the keyboard to navigate between links inside of an SVG graphic. This is arguably a bug in Firefox, and might be fixed at some point, but highlights the problems that can be encountered when “pushing the limits” of a particular technology in one direction or another, with SVG particularly vulnerable because of how big and complex the language is. (Those complexities are also what makes SVG so darn exciting; I’m not saying that those other features shouldn’t be there, only that when using newer technologies or existing technologies in new ways, web authors need to be extra careful to make sure that what they’re doing will be accessible to everyone).

The Bottom Line

SVG support coming soon to all major browsers. Usable directly in HTML via HTML5. Syntax contains accessibility features. Poorly supported by current versions of screen readers and other assistive technologies.

Further Reading


  1. Aaron Cannon

    One additional area in which SVG graphics can potentially offer a boon to accessibility is that SVG supports both raster images as well as vector images. Raster images are what we have now with JPG, PNG and GIF. Native vector images (images that were born vector images and not converted from a raster image) are great for folks with visual impairments, because they can usually be infinitely magnified without any loss in quality. The reason is that vector images are defined by formulae that describe line segments, curves, polygons, and circles that make up the image.

    Thanks for a great article.

    Aaron Cannon
    Accessibility Consultant

  2. Christophe Strobbe

    This is the first time I read that keyboard navigation in SVG actually works (at least in Firefox). When I checked this two years ago, there was no keyboard access to speak of: http://bit.ly/bJyg7I

    With regard to “extreme SVG”: at the SVG Open conference in 2008 I even saw an SVG authoring tool implemented in SVG…

  3. Doug Schepers

    Thanks for the thoughtful article, Aaron. I do have a clarification… you say that each browser “implements a different subset of the spec”, but actually, there is a core interoperable subset. The major differences lie with declarative animation, SVG Fonts, and filters; also, Firefox needs to improve its text support in some areas, though it has gotten much better recently. The large majority of SVG features *are* interoperably implemented across browsers, and this is the subset that IE9 is targeting as well.

    Your readers may be interested to know that we are planning significant and pragmatic accessibility improvements in SVG 2. I have contacted AT vendors n the past about supporting SVG better, but at that time, they were not interested in doing so… hopefully now that every major browser is unanimous that SVG support is important, AT vendors will also come to the table.

  4. Christophe Strobbe

    Do you know to what extent the limitations of SVG accessibility are the result of browser support rather than AT support? In other words, do browsers expose SVG accessibility features through the accessibility API? I am asking this because it does not seem reasonable to demand that AT re-implement every specification that is already implemented by a browser; ideally, there should be a sufficiently rich API through which AT can access all the necessary information.

  5. chaals

    Hi Aaron,

    when I wrote the SVG Accessibility Features Note with Marja (a decade ago) RDF looked like a good bet for doing a lot of things. Times changed, and instead of raw RDF it is possible to use ARIA markup attributes directly in SVG. While this isn’t as powerful as RDF, it can still be modelled in RDF and therefore extended. I think it will be a while before we figure out how to do serious grahpics stuff with ARIA, ubt at least the interaction bits that are like what people do in HTML can work.

    I don’t think it is the case that people are doing different subsets of SVG. When Opera released support for SVG Tiny profiles without scripting, and Firefox didn’t have animation, that could be said to be the case, but that was about 5 years ago. Now there is pretty much just more and less complete implementations of the same stuff, as you can see in the codedread table you referenced.