Accessibility

Invisible Visualization

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.

Continue reading “Invisible Visualization” →

Current State of Authoring Accessible SVG

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.

Continue reading “Current State of Authoring Accessible SVG” →

Retain Accessibility Immediately

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.

Continue reading “Retain Accessibility Immediately” →

Translation Services at a Loss for Words

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.

So, SVG is translatable, right?
Continue reading “Translation Services at a Loss for Words” →

Underscoring Accessibility

Dramatis Personae

  • Doug Schepers (a Montague)
  • Anne van Kestern (a Capulet)
  • Simon Pieters (a Capulet)
  • Henri Sivonen (a Capulet)
  • Rich Schwerdtfeger (a Franciscan)
  • Aaron Leventhal (an Apothecary)

The Prologue

Over the past few weeks, there has been a long, drawn-out discussion about how to integrate ARIA (an accessibility specification) into both SVG and HTML in a uniform way. There have been two main camps, as there usually are in these matters: the XML advocates, and the HTML5 (WHATWG) advocates. Both sides want to make sure that all content works the same across all browsers, authoring tools, etc. (collectively called User Agents), but they differed in how they thought it should be done.

The XML True Believers have held that the way forward for the Web is to enforce a strict, well-defined syntax for Web languages, and that to extend or combine languages, a differentiating mechanism called “namespaces” would be used. Namespaces in XML are specified to take the form “schepers:doug”. They declared a do-over on HTML, recasting it in the new XML mold (XHTML), and planned for browsers to be stricter on new content, and for authors to have learned their lessons.

The HTML Young Turks came forward with the observation that no matter how well you define a syntax, people will make mistakes (or not know the right way to do things), and that the way to recover from those mistakes is to define error-handling behavior for each kind of mistake; they also believed that since they could now reconcile older “broken” content with new browser behavior, that they were constrained to define behavior that would work in all past browsers, as much as possible, and to degrade gracefully in those that didn’t. But this required a more rigid parsing mechanism that doesn’t work well with extensibility, a problem exacerbated by Internet Explorer’s idiosyncratic and variable (one might even say spasmotic) behavior regarding the colon (“:”), meaning XML Namespaces didn’t work right. Also, the colon has a special meaning in CSS, yet another wrinkle.

So, XHTML and SVG are based on the XML model, and the new HTML5 is based on the new-old model. This difference wasn’t really much of a problem for SVG, though, because SVG and HTML are two different languages…

But of course people want to use them together. (More on that in some other post.)

The obvious way around that is to have two different parsers (a parser is a program that reads a formal syntax and makes a model of it for the browser to act on), and when you encountered SVG inside HTML, you would switch to the stricter parser. HTML would have its model for naming attributes (with no colon), and SVG would have its attributes (with a colon).

But there’s a hitch. ARIA is an accessibility technology meant to work in HTML and XHTML and SVG (and other presentation languages). The functionality for ARIA is defined in its own specification, but it’s not intended to be used on its own… it has to be integrated into a host language. It would be confusing for authors to have to use two different syntaces for the same functionality in different languages.

For example, in SVG you might have:

<svg version="1.1"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
xmlns:aaa="http://www.w3.org/2005/07/aaa">

<g xhtml:role="checkbox" aaa:checked="true">
<rect x="5" y="5" width="20" height="20" rx="5" ry="5"
fill="none" stroke="crimson" stroke-width="2"/>

<text x="30" y="22" font-size="18" fill="crimson">
Enable Accessibility</text>
</g>

</svg>

While in HTML, you would have something like:

<html>
<ul role="checkbox" aria-checked="true">
<li>Enable Accessibility
</ul>
</html>

Let the drama unfold…

Continue reading “Underscoring Accessibility” →

SVG Text, Semantics, and Accessibility

In addition to geometric shapes, SVG has advanced graphical text capabilities. In SVG 1.1, there are several elements specifically designed for the presentation of text. At the most basic level, there is the <text> element, which can have child <tspan> elements that can be positioned and styled independently of the other text content, like this:

Then there are more advanced options, like rotated text
or the <textPath> element

The future of SVG text support holds still more. In the next version of the SVG specification, SVG Tiny 1.2, there are even more useful text features, like the <textArea> element that automatically wraps text to a shape (rectangles on for mobile devices, but any shape at all in future versions of the specification). There is also the new ability to make any text editable by simply including an attribute to the text element. And there are great features from SVG 1.1 (the current version) that are not yet widely implemented, such as SVG Fonts, which let you embed a font into an SVG file so the reader sees the page the way the author intended it, and the <tref> element that lets you directly quote text without duplicating it. All these features will give more control to authors and give a better experience to users.

But is that enough?

Continue reading “SVG Text, Semantics, and Accessibility” →