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.

Accessibility

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

• Scalable Vector Graphics [Wikipedia]
• Scalable Vector Graphics 1.1 Specification [w3.org]
• Accessibility Support – SVG 1.1 [w3.org]
• Accessibility Features of SVG [w3.org]
• SVG – HTML5 [whatwg.org]
• Just how accessible is SVG [iheni.com]
• Table of SVG Support by Implementation [codedread.com]