As professionals, we need to keep our jargon accurate. That’s why I hate hearing “HTML5” used as an umbrella term for any web technology, especially when people confuse HTML5 (mark-up and APIs) with CSS 3 (eye-candy). Repeat after me: HTML5 != CSS 3.
So we need a buzzword, as “HTML5 and related technologies” is unwieldy (and inaccurate). I prefer “NEWT” which stands for New Exciting Web Technologies and can thus safely encompass real-HTML5, CSS 3, SVG, XHR2, Geolocation, Web Sockets, WOFF, Web DB, IndexedDB, WebGL and the like.
Because new acronyms need a logo, the talented and generous Rob Winters made a cute newt.
As a part of Microsoft’s continued commitment to interoperability and standards support, yesterday we submitted our request to join the Scalable Vector Graphics (SVG) Working Group of the World Wide Web Consortium (W3C). We’re excited to take part in ensuring future versions of the SVG spec will meet the needs of developers and end users.
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.
(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.
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.
