March 16, 2009

Thoughts towards an accessible canvas

The canvas element is part of HTML5 and allows for dynamic scriptable rendering of bitmap images. Canvas consists of a drawable region defined in HTML code with height and width attributes. JavaScript code may access the area through a full set of drawing functions similar to other common 2D APIs, thus allowing for dynamically generated graphics. Some anticipated uses of the canvas include building graphs, animations, games, and image composition.
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.

But what, exactly, should content authors include as their fallback content?

This has been an on-going problem since the introduction the <noframes> and <noscript> elements, officially released as part of the HTML4 specification almost a decade ago. Recollections of “This site uses frames, so get a browser that doesn’t suck” are likely in everyone’s memory (at least, of those likely to be reading this) and it highlights a basic problem: there is no standard for applying and conveying this alternative, or ‘fallback’ content, and so authors are left trying to guess what to do. Earlier this year, I complained that the HTML5 Draft specification made including this content optional, using the word ‘should’ (in the RFC 2119 way) instead of ‘must’. The current draft has apparently corrected this deficiency as it now states ‘must’ – however what is missing is instruction (mandate?) on what this fallback content should be.

An oft stated goal of the HTML5 WG is that they do not want to over-burden content authors’ work-flow by adding extra steps; that most authors will not bother and it makes things overly complicated. I understand and accept that. Yet to ensure that we reach even a modicum of equivalency we need to ensure that some basic information be provided to all users. And if we learned one thing from HTML 4’s @accesskey debacle, it’s that consistency is crucial.

With these thoughts in mind then, how can we ensure that the canvas element is at the very least user-friendly to those who may never actually be able to consume the author envisioned content of <canvas>? I propose a ‘block’ of 5 attributes – 2 mandatory and 3 optional – that constitutes the fallback. This block, essentially meta-data, would be contained in-line, perhaps as a definition list (with an ARIA @role?), or through some other means (could we use the <meta> element here?) – the main point being that a prescribed, mandated means should exist to convey this data, so that all instances of <canvas> would consistently include these values. Finally, I propose that any instance of <canvas> that lacks at a minimum the 2 proposed mandatory values be non-conformant and not render on screen. The inclusion of this information should not be left to chance – the specification requires that some fallback content exist – and if it does not exist then the <canvas> element is incomplete, thus it should simply fail all users, not just those who cannot access the content as does the mainstream. As the values are pre-determined by the specification, their presence can be programmatically verified and the 2 mandatory attributes are so basic in nature that it is unlikely that they will be ‘gamed’ or misused/abused. Finally, due to the ‘consistency’ factor, authoring tools could be programmed to collect and insert this data with little overhead or intrusion to the content author.

The proposed attributes are:

[mandatory] A brief description or name of the canvas content. Think along the lines of @alt – tell the user of a user-agent that does not support canvas what is in this region: its purpose or function. This is not to be verbose!


  • Dynamic chart of this week’s votes from American Idol
  • A 3-dimensional shooter game
  • Bespin – A dynamic on-screen editing tool
[mandatory] The owner or creator of the widget. May be an individual or entity, and may also include the anchor element to another URI


  • <a href=>The FOX Broadcasting Company </a>
  • Joe Blough for My Web Developer Company LLC
  • Mozilla Labs Project – Dion Almaer, on behalf of the Bespin development team
[optional] A more detailed explanation, expanding upon the Title. We cannot presume that all users want a verbose explanation of the canvas ‘widget’, however there are times when some might, and providing this information would be of great use.


  • “The FOX Broadcasting Company’s popular American Idol television program allows viewers to vote on their favorite performer each week. This on-screen application creates a visual representation of the weekly votes cast using a common bar graph, with updates posted every 60 seconds.”
  • “A small, on-screen game with a one-person shooter character who must navigate a maze while also shooting opponents. The goal or the game is to exit the maze while also shooting all of the characters. Players can also attempt to beat their score by completing the game in increasingly shorter time intervals.”
  • “Bespin is a Mozilla Labs experiment that proposes an open, extensible web-based framework for code editing that aims to increase developer productivity, enable compelling user experiences, and promote the use of open standards.”
[optional] Borrowing from the idea of @longdesc, this would be an URI that points to an alternative rendering of the content/concept that the canvas region is delivering. For example, in the case of the dynamic bar-graph, the data driving the bar-graph could also be represented in a tabular (<table>) format. The canvas ‘widget’ might also be available as a stand-alone download in which case the URI for the download would be provided here, or it might be nothing more than a ‘screen-capture’ image (with appropriate @alt)
[optional] A catch all attribute which would be open for use to the content developer to use as desired. The content of Notes would be text only, and might include items such as change-log data or version number, or other developer commentary as required.

It is important to state that this is just an opening proposal – it should be discussed, analyzed, dissected and ruminated upon. It is my belief however that we cannot and should not leave any of this to chance, and equally, we cannot expect content authors to know what we mean when we talk about ‘fallback content’. We need to state clearly and unequivocally what we mean by this, and provide them with the template of these requirements to ensure they get it right the first time, and every time. The specification currently already says they ‘must’ add fallback content, now we need to define what that content should look like.

  1. #1 by catherine on March 16, 2009 - 6:24 pm


    An interesting proposal but, if I may ask, why make the ALTERNATE attribute optional ? From a user perspective, is that not where all the meat is ? I mean, if, as an AT user, all I can access is a short description of function (via TITLE) and the author’s name, what am I left with ? A short description of something I can not use and the creator’s “name” so I may perhaps let them know how I can not use their pretty thingy in the hopes they will let me in ? Am I missing something ? Or maybe you are hoping that WCAG will cover this, for those who adhere or are mandated to do so ?

  2. #2 by John on March 17, 2009 - 12:42 am

    Because sometimes, from what I can see, there will be no real alternative. Good developers will likely try and provide an alternative, but the idea that bad alternative content is as bad, or worse than no alternative content makes sense to me, so personally I would rather keep this value optional, rather than have it gamed with bogus values. This BTW is the same issue as with alt in images, where uninformed developers will add crap values simply to have the tick-box satisfied.

  3. #3 by catherine on March 17, 2009 - 8:32 am

    Well, I guess I am one of the last people on the planet who still thinks ALT should not be optional but required. I understand that bad content is not helpful but I continue to worry about what kind of message this sends.

  4. #4 by John on March 17, 2009 - 9:00 am


    Cat, I believe that all images ‘must’ (RFC 2119) have some form of textual equivalent, but believe as well that @alt is not always the answer. See:

    I’ve taken heat over my comments about Bespin (and really, I don’t want to pick on them), but what, exactly, would you add as an alternative to that? In that situation, telling users what the region contains (and who built the thingy) is about all we can reliably and truthfully tell users – it isn’t perfect, far from it, but it *is* accurate, informative and at the very least shows some basic respect to those users barred from any further participation.

    Overall, I have some real issues with canvas at a higher level, but the reality is that it is here, and will not be going away. Once again, we are playing catch-up, as once again the spec delivers us something new, with little real thought to the accessibility ramifications. All we can hope for at this point is to try and improve a shoddy implementation with some basic repair suggestions: right now the spec looks something like:
    Put something here to satisfy those pesky accessibility folks

    We can (‘must’ RFC 2119) do better! This is just a suggestion to start the dialog – I would love for somebody to better this idea.

  5. #5 by Olivier G. on March 18, 2009 - 3:06 am

    I think that the alternative to a Canvas element will often be much more complicated than just a paragraph of text.

    What about a element, that could be linked to the canvas element through a id/for link ?

    Your example of “american idol votes” could be alternatively renderer using a table element…

  6. #6 by Martin Kliehm on March 18, 2009 - 4:45 pm

    I doubt that anybody will provide redundant content, because either the canvas content is way too advanced and beyond anything that is possible in plain old semantic HTML, or because nobody will take the pains of creating complex content twice. Therefore I would propose to make the child objects available in the DOM where they can receive any ARIA enhancements you can possibly bolt on by scripting. It is true that currently is just a flat bitmap that you can save as PNG or data URL, but when creating shapes and contents in a canvas, why shouldn’t you be allowed to add semantics at the same time? But a prerequisite would be browsers mapping those child objects to the DOM, and perhaps using the RDF features of the XHTML role module to expand the available roles by textnodes or things to describe 3D image galleries or future progressive UIs I can’t imagine at this time.

You must be logged in to post a comment. Here's Why.