Canvas, accessibility and SVG

Since watching Steve Faulkners’s standards.next presentation about HTML 5 accessibility, I’ve become more interested in the accessibility of the canvas element. canvas is a method of producing dynamic graphics with JavaScript:

The canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly.

As a nice illustration, here’s an example of Super Mario in 14K of JavaScript.

No matter how sexy they are, however, they’re just graphics, with the accessibility complexities that can entail. In the specification, there is a very basic way of providing "fallback content":

When authors use the canvas element, they must also provide content that, when presented to the user, conveys essentially the same function or purpose as the bitmap canvas. This content may be placed as content of the canvas element. The contents of the canvas element, if any, are the element’s fallback content.

This is as basic as

<canvas>
You're too damn blind to use this bit
</canvas>

Now, this is all well and good if you’re just drawing a simple image whose contents you know and can describe in advance, or using jQuery to dynamically draw graphs of data from a data table, but what happens if you’re using it as a text editor like Bespin, or even making UI controls like tools.mozilla.com? Note the latter has a simple link at the bottom "plain HTML version". In 2009, parallel "screenreader pages" are unnacceptable.

(I’m not really blaming the developers of these pages; the lack of accessiblity fallback is inherent in the specification, although the second example could be done with SVG, an image map, or with good old fashioned HTML, CSS transforms/ transitions and JavaScript).

Indeed, the spec does warn against misusing the canvas element:

Authors should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading: if the desired presentation of the heading is graphically intense, it should be marked up using appropriate elements (typically h1) and then styled using CSS and supporting technologies.

I’m pleased to see that the HTML 5 cabal are discussing this and the HTML 5 editor, Ian Hickson, is seeking advice from the W3C‘s Web Accessibility Initiative. The Mighty Steve Faulkner has been giving it some deep thought. Here’s a very thorough investigation of accessibility issues problems in canvas.

canvas or SVG?

There is another, longer-established standard for drawing graphics on the screen, Scalable Vector Graphics (SVG). This is supported on the same browsers that support canvas (that is, all except Internet Explorer) but is a much more mature technology. As it’s an XML-based language, it is text-based and thus is inherently accessible. Screenreaders don’t support it yet, probably because the big screenreaders have traditionally sat on top of Internet Explorer, and also because they are the Netscape 4 of assistive technologies—last I heard screenreaders don’t support strong or em.

I expect in the coming months we’ll see lots of unnecessary uses of canvas over SVG, in the erroneous belief that “Canvas is cooler than SVG" and it’ll be like Flash was in 1999. Ah well. At least we can hope that the Working Group can make this new "skip intro" accessible.

Update Monday 20 July:

The [W3C‘s] Protocols and formats working group discussed the issues of canvas accessibility in their HTML caucus meeting last friday (17/07/09). It has been decided to form a task force to work on specifying additions to the CANVAS API, that will result in canvas content being natively accessible.

http://lists.w3.org/Archives/Public/public-html/2009Jul/0562.html

22 Responses to “ Canvas, accessibility and SVG ”

Comment by Olly Hodgson

If I remember correctly, the developers of both Cufon and Bespin mentioned performance as a major reason why they chose Canvas over SVG (SVG was significantly slower).

I’m also not convinced that SVG is inherently more accessible than canvas. It’s like almost any other tool: Your SVG creations can be accessible if you use it properly, but have the capability to be a complete disaster if you don’t.

As a simple example, create some text using SVG fonts and you’ve got something that’s perfectly readable to assistive tech. Draw it manually and it’s just a bunch of curves unless you can see it.

Comment by Bruce

True, Olly. But as the spec stands at the moment, there’s no real way to make canvas accessible; there is with SVG.

Performance is one reason why people may favour canvas over SVG. I suspect another is that a lot of developers are familiar with JavaScript, whereas SVG feels like another language to learn.

Comment by Henny

Olly I have to agree with Bruce.

While screen reader support for SVG is yet to mature ARIA could change all that. With the accessibility hooks provided by ARIA SVG could become massively more accessible. We don’t really have anything quite like that for canvas yet.

That said as you’ve pointed out there is a time and a place for using SVG, canvas or anything else for that matter and it’s down to a developer to know when that time is.

Comment by Fredo

I really don’t understand that hype about canvas. It is like people started building a flash player into the browser.

If they think SVG is slow, then I don’t know what tools.mozilla.com is meant to be. Maybe the Mozilla guys could finally implement declarative animation, and maybe one could do some research in order to improve performance of SVG implementations.

SVG has a DOM, SVG is scalable, so I really don’t know why it isn’t the first choice for modern web graphics. And if you want a JavaScript API, take RaphaëlJS or something like that.

Comment by Ian Hickson

So far nobody has come up with any solutions (except for the comparatively easy keyboard focus case, but that’s for low-dexterity users, not low-vision users). If you have any suggestions, please do take part in the discussions.

Comment by Henri Sivonen

“As it’s an XML-based language, it is text-based and thus is inherently accessible.”

Is the quoted statement lampooning XML advocacy or an instance of it?

How is a path element with a bunch of coordinates inherently accessible? If you read the bézier data of the famous SVG tiger, how can you tell it represents a tiger?

Comment by steve faulkner

Ian wrote:
“So far nobody has come up with any solutions”

If we can’t work out solutions over the next few months it may unfortunately lead to objections being lodged when the spec goes to last call, so I hope very much that it can be resolved. One possibility to avoid holding up the progress of HTML 5 would be to move the canvas section out into its own spec, thereby giving it the chance to be developed into a more mature state without blocking HTML 5

Comment by Lachlan Hunt

The problem is that the use cases for canvas have evolved greatly over the past few years. Using ordinary fallback content was and still is mostly fine for the major use cases of a few years ago, where any and all UI controls were either done with other elements in the page (as in, e.g., CanvasPaint), or keyboard control (as in the case of many games).

But now that people are starting to push the boundaries by creating complete, custom UI entirely within the canvas itself, the accessibility issues need to be re-evaluated.

Comment by steve faulkner

lachlan wrote:
“Using ordinary fallback content was and still is mostly fine for the major use cases of a few years ago”

I agree that this is the case, but think providing inbuilt methods in the canvas API to include fallback would make it much more likely that it is provided.

Comment by David Storey

Henri: The SVG tiger is just a image drawn using SVG. You can tell it is a tiger by the same way you would tell a jpeg is a tiger; use the alt attribute in HTML if you are using the image in HTML using the img attribute, or you could add a title or desc element to the SVG.

Where it becomes more important is when there is text in the document. In SVG it is just regular text, so can be pulled out or accessed fairly easily, instead of just being pixels on the screen. For UIs you can add attributes to describe what the elements are, such as the role attribute and WAI-ARIA. You could even transform the document using XSLT if you really wanted to.

There are obvious accessibility limitations to SVG at the moment as screen readers don’t read it yet, and less people know how to do it well yet. Once SRs get on the ball, there is no reason why SVG documents can’t be as accessible as HTML documents with little work. You can even include regular HTML elements in SVG via foreignObject if there is a need.

With canvas, doing the equivalent of the SVG tiger can probably be as accessible as SVG, but anything involving text and UI becomes a lot more complex without making an alternative version.

Comment by Just how accessible is SVG? » iheni :: making the web worldwide

[…] XML, being a text based language, also lends SVG to better accessibility than current headline grabbers such as HTML5 canvas which lacks an accessibility API or hooks for screen readers. While the WHAT-WG currently recommend a fallback – a draconian circa 1999 HTML alternative that confines screen reader users to a disability ghetto – they are working on a “built in” rather than “bolt on” approach asking for input from the accessibility community for viable solutions to make canvas accessible. Bruce Lawson has the lowdown on SVG versus canvas in his post  Canvas, accessibility and SVG. […]

Comment by suki

Canvas and SVG are different, so they cannot be compared, but what is clear is all the propreitary rubish are given more attention by Browser implementors, except Opera and Firefox… W3C is more like the Don managing all the mafia…

Comment by breton Slivka

My thoughts on the canvas api and accessibility in the link to my name..

Basic summary: The canvas API is the wrong target for making bespin accessible. What needs to be made accessible is its widget toolkit, not the way it draw the widgets to the screen. How do we do that?

Nobody complains about CSS not being accessible. Why is that? I think canvas belongs firmly in the “Presentation” teir of the webstack, sitting right next to CSS. what’s missing is not some feature of the Canvas API, but the ability to expose Bespin’s object model to an accessable client without having to construct essentially a hidden and duplicated HTML DOM. What else is missing? A design that makes creating accessible apps useful to developers that are not disabled in some way.