This blog entry has an [inline SVG] image with a text alternative. Who does it benefit?
Short answer: no one, but you have to do it anyway.
Long answer: As far as I know, none of the commercially available screenreaders support SVG in any way, much less reading the title of an SVG image included inline in an XHTML page (as opposed to, say, linked from the src attribute of an <img> element, or embedded in an <object> element). Nonetheless, you have provided a text alternative for the image, and theoretically, that could be presented to a user in place of (or in addition to) the image. You have therefore fulfilled your moral duty, even though no one actually benefits from it. Welcome to the wacky world of access enablement.
The concept of access enablement is not complicated. In the physical world, it works like this: I build the ramp, you bring the wheelchair. I don’t have to provide you with a wheelchair; it’s up to you to procure one. Nor do I have to teach you how to use your wheelchair to get up my ramp. Nor do I have to push you up the ramp when you arrive. If your wheelchair happens to break at the bottom of my ramp, you can’t sue me for being inaccessible. I did my part: I built the ramp; everything else is Somebody Else’s Problem.
For better or for worse, this concept got translated directly into the virtual world of software. Just as there are standards that define the minimum width and maximum slope of wheelchair-accessible ramps, so too there are standards for building accessible software and authoring accessible content. In the desktop software world, priority #1 is to keep track of the focus. In the web authoring world, it’s to provide text alternatives for any non-text content. The exact techniques vary by medium. For the HTML <img> element, the guidelines say you must provide an alt attribute and (potentially) a longdesc attribute. For SVG, they mandate a <title> child element and (potentially) a <desc> element.
The interesting part is not what the guidelines say, but what they do not say.
So here’s the crux of the problem: nowhere in the process of defining an accessibility feature is there any consideration for how often it would be used, how often it would be used correctly, what would happen if it were used incorrectly, how much it would cost to implement it, or how users would learn about the feature. In short, there is no cost-benefit analysis.
Now, some features are simple and easy and popular, so these questions never come up. If enough authors use them and tool vendors implement them and end users learn about them, then everything works. But not every feature is simple or easy or popular; a lot of them are waaaaay down the “long tail” of usage + implementation + education. So far down that, in any other field, you would start talking about the law of diminishing returns. But in accessibility, there is no such limit.
Some concrete examples: most browsers don’t expose information about the access keys available on a page, and most authors don’t define access keys in their pages, and those that do often conflict with other browser, AT, or OS-level shortcuts. Most images aren’t complex enough warrant a long description, and most authors who try to offer a long description get it wrong. But it is just assumed that users who would benefit from them will somehow learn of their existence and be motivated to find software that supports them (assuming they can ever find a page that uses them).
The accessibility orthodoxy does not permit people to question the value of features that are rarely useful and rarely used.
When this orthodoxy collides with reality, the results are both humorous and sad. When I was an accessibility architect at IBM, I assisted in the final stages of ensuring that Eclipse’s Graphical Editing Framework was fully accessible to blind people. This involved ensuring that all possible objects were focusable, all possible actions were keyboard-accessible (including drag-and-drop), and all possible information about nodes and connectors was exposed to third-party assistive technologies via MSAA. It was mind-numbing work, full of strange edge cases and bizarre hypothetical situations, not unlike the one Sam is struggling to understand. During one particularly difficult teleconference, an Eclipse developer muttered something like, “You realize no one is ever actually going to do any of this, right?” There was an awkward silence as the people who had spent their lives in the trenches of access enablement contemplated the very real possibility that no one would ever benefit from their work.
Back to Sam’s question. Few authors publish in true XHTML mode, fewer still include inline SVG images in their XHTML, and fewer still include titles or descriptions in those images. But in theory, you can imagine a situation where a web author publishes in true XHTML mode, and the author includes an inline SVG image within an XHTML page, and an end user is using a browser that supports true XHTML, and that user is using a hypothetical screenreader-of-the-future that implements support for the <title> and <desc> elements within inline SVG images within XHTML pages, and that user stumbles across that page. It’s theoretically possible, therefore you have to do it. Period. End of discussion.
Now go retrofit text alternatives into every SVG image you’ve ever published, or an accessibility advocacy group who has never visited your site will sue you on behalf of all the users you’ve been disenfranchising. All zero of them.
§
I am no longer accepting public comments on this post, but you can use this form to contact me privately. (Your message will not be published.)
§
© 2001–9 Mark Pilgrim