(Last Updated on )
Since watching Steve Faulkners’s standards.next presentation about HTML 5 accessibility, I’ve become more interested in the accessibility of the
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.
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.
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 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
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.