- 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=http://www.fox.com>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.