Thoughts towards an accessible <canvas>

Requirement:
	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.
[source: http://dev.w3.org/html5/spec/Overview.html#the-canvas-element]

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:

Title:
	[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!
	Examples:
	* Dynamic chart of this week's votes from American Idol
	* A 3-dimensional shooter game
	* Bespin - A dynamic on-screen editing tool

Author:
	[mandatory] The owner or creator of the widget. May be an individual
or entity, and may also include the anchor element to another URI
	Examples:
	* <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

Description:
	[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.
	Examples:
	* "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."

Alternate:
	[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)

Notes:
	[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.

JF

Received on Tuesday, 17 March 2009 07:01:44 UTC