Last year, I put together a talk called “Invisible Visualization†on making accessible data visualizations. Several people have asked me about it, so I thought I’d write a post about it.
By “accessibleâ€, I mean able to be consumed and understood by people with a variety of sensory needs, including people with visual limitations, cognitive impairments, mobility challenges, and other considerations. I provided a few simple ways to expose the data in SVG images, but mostly I described different constraints and suggested ways of thinking about the problems.
I didn’t want to lecture people about the need for making their content accessible; I wanted to excite them about the possibilities of doing so. It’s great that there are legal regulations addressing the needs of people with disabilities (like the “Section 508†laws here in the US), but that’s not going to empower and motivate developers and designers to want to meet these kinds of design constraints and solve these kinds of technical challenges. I sought to avoid the “threat and guilt†trap that I’ve seen too many accessibility talks fall into.
SVG has a few metadata features intended specifically for accessibility, and also provides the ability to use real text instead of images for textual content, just like HTML. This combination of text and metadata serves as one of the cornerstones of SVG’s accessibility; there are other features, such as scalability and navigation features, but this post will focus on the descriptive capabilities of SVG.
I was recently looped into a discussion on the @longdesc attribute in HTML which dealt in part with SVG accessibility, a subject I’m fascinated by. The specific debate is whether a @longdesc value should be applied for SVG, or whether SVG’s native accessibility features should be used, or both.
Let me explain @longdesc. For short descriptions of a picture, a few words to a few sentences, you can simply include the text in the <img> element’s @alt attribute. The @longdesc attribute of an <img> element allows a content author to add a URL that leads to a longer text description of the image. You can read more in this excellent article on @longdesc by WebAIM.
SVG provides a different way to provide text descriptions: the <title> and <desc> elements, which can be a child of any graphic or container element in SVG, and which contain text descriptions of the element. The <title> is meant for shortish names, while the <desc> can provide arbitrarily long descriptions; nothing in the SVG spec limits the length of these elements, but choosing the appropriate text is a best practice (as for any prose). These metadata elements can be read out via screenreaders (accessibility technology that speaks the available text aloud), along with the content of the <text>, <tspan>, and <textPath> elements.
Because each SVG shape (or group of shapes) can have its own <title> and <desc>, a certain amount of structure and sequential flow is available to these screen readers. Each text or metadata element is read out in document order. Together, the series of text passages can comprise a complete description of the SVG graphic. Which is kinda cool… self-describing images!
Well, that’s the idea, anyway. Now let’s look at it in practice, and specifically, at authoring SVG accessible content, and support in browsers and screenreaders.
Note:Â though I offer some specific guidance here, this is not really a tutorial; it’s more a background article on the topic, partly from a standardization point of view. I’ll be writing a tutorial aimed at developers and designers soon on WebPlatform.org.
I’ve long been an advocate of wrapping (or “flowing†or “multi-lineâ€) text in SVG. This is basic functionality, and people have been asking for it since SVG started.
I’m also an advocate for moving features out of SVG and into CSS, like gradients, animation, compositing, filters, and so on; the benefits of a single code base for HTML and SVG applications, and ease of learning and maintenance, are obvious.
So, I was excited when the CSS WG took up work to allow wrapping text to arbitrary shapes, like circles or stars, not just boxes. This will enable a whole new magazine-style layout that will benefit web sites and ebooks alike. But I was disappointed when I found out that this work had some recent setbacks and delays.
So, I’m calling for a simple solution now, while we wait for the more complete solution later. And the nice thing is, my solution also relies on CSS!
Several times recently, people have asked on IRC how they can use nice fonts with SVG. My answer in the long-ago past, when Adobe’s excellent SVG Viewer plugin roamed the Earth, was to use SVG Fonts directly embedded in the SVG file… but that’s no longer practical with the current varied browser support.
By far the easiest way to do this today is to use webfonts, such as WOFF.
Authoring tools, like Inkscape and Adobe Illustrator, should simply manage this for authors, but until that happens, I thought I’d share a relatively simple workflow that has helped others. (Warning: I will use the words font and typeface with careless abandon to semantics in this article, though I know the difference. I’m afraid the more sensitive souls among you may suffer apoplectic righteous indignation.)
I will walk you through this workflow step-by-step, but if you get lost, just look at the source code… it’s pretty self-explanatory.
Find a font you like. For this example, I chose Riesling, an Art Deco typeface by “Bright Ideasâ€. I made sure the font was free and didn’t have any restrictions for online or commercial use.
Upload the font to FontSquirrel’s @font-face generator, and download the resulting package. This contains the webfonts, as well as some sample files (though not an example of how to use the files in SVG).
Copy the resulting webfont files (*.eot, *.ttf, *.woff, *.svg) into the same directory as the SVG file that will reference them. (Note: do not confuse the SVG file in the FontSquirrel package for a content file; it is an SVG font, with no rendering content.)
Copy the CSS @font-face style rule from the FontSquirrel package file (“stylesheet.css”), and put it in your SVG’s <style> element.
Optionally, for local testing, install the original TTF file as a system font, and add the local value to the @font-face style rule
Add a style rule for text elements, using the resulting font-family. In my example, I also created a style rule for textPath elements.
In practical usage, SVG Fonts were once the only way to use webfonts on iOS devices (e.g. the iPhone and iPad), which is why FontSquirrel includes them in their font-face package; but this is no longer the case, and iOS 4.2 added support for TTF fonts, which reportedly perform better. I expect this use of SVG Fonts to dwindle away… people will naturally want to use as few font formats as possible.
But for all of you out there who, like me, love the cool things you can do with SVG Fonts that aren’t possible in traditional outline font formats, don’t despair! Even as I write this, a proposal is being prepared by the SVG glyphs for OpenType Community Group to add a subset of SVG to OpenType, for more interesting typeface capabilities.
There has been a heated argument recently on the W3C Canvas API mailing list between accessibility advocates and browser vendors over a pretty tricky topic: should the Canvas API have graphical “objects” to make it more accessible, or should authors use SVG for that? I think it’s a false dichotomy, and I offer a proposal to suggests a way to improve the accessibility potential of the Canvas 2D API by defining how SVG and the Canvas 2D API can be used together.
This brings together some ideas I’ve had for a while, but with some new aspects. This is still a rough overview, but the technical details don’t seem too daunting to me.
Text in SVG is text. Visually, you can use webfonts like WOFF or SVG Fonts (where they are supported, like in Opera or the iPhone) to make it look cool, and you can style both the stroke and fill to make it all fancy, or apply filters to pop it out or make it glow or give it a dropshadow, but it’s not just a raster image like many text headers… it’s human- and machine-readable text, as nature intended.
Mozilla is holding an Open Web Games competition. I expect that many of the games will be use the Canvas API, since many programmers are more familiar with the imperative programming mode, and there are some games libraries that have been developed for Canvas or adapted from existing drawing or gaming libraries.
But I’m calling for SVG developers and designers to step up to the plate, as well. SVG has a lot of features that make it easier out of the box to build interfaces, animations, and even games. There is a scene graph, and the DOM event model that gives you free hit detection for pointer events, for example. And I’d love to see someone make an open-web game that’s both accessible and fun…
To help developers along, I thought I’d share a few free, open-source SVG resources that could be useful in building games: Continue reading “SVG Game Resources”→
With SVG being integrated more and more into HTML5, both included via <object> and <img> elements, and inline in the same document, some natural questions about SVG and CSS are receiving more focus. This includes box model questions like background and border, and pointer events.
I’m interested in comments from the community on what direction SVG should take.
Korzybski remarked that “the map is not the territory”, reminding us that we shouldn’t confuse our mental models for reality. But maps, and data visualizations of all kinds, are really powerful, conveying complex ideas easily, and even shaping (or misshaping) perceptions about facts. This is one reason why decentralization of mapping resources and services is good; no one organization should control our common maps.
SVG is a natural fit for mapping. There’s even a detailed proposal by KDDI’s Satoru Takagi-sensei for tiling, layering, and coordinate resolution that fits on top of SVG, which I’d like to see standardized.
I’ve had an idea for a small open-source project for a while, which I’ve discussed with the brilliant Andreas Neumann of Carto.net; he’s been too busy planning SVG Open every year to help out with it thus far, and I don’t have the skills to do it without a great investment in time. Continue reading “The Map is not Proprietary”→
