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.

(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.

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.

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.

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.

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.

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.

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

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.

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.

[…] 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. […]

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…

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.

I work for Opera, but all opinions contained herein are mine (and are thus incontrovertibly
correct) and do not represent the opinions of my employers. (Comments are copyright their authors, not written by me, and
are therefore probably the ramblings of mad people.)