Re: Thoughts towards an accessible <canvas>

Hi John, thanks for this proposal. I have some serious changes to suggest,  
so details inline...

On Tue, 17 Mar 2009 08:00:56 +0100, John Foliot - WATS.ca <foliot@wats.ca>  
wrote:

> Requirement:
>  When authors use the canvas element, they must also provide content
> that [...] conveys essentially the same function
[...]
> [source: http://dev.w3.org/html5/spec/Overview.html#the-canvas-element]
>
> But what, exactly, should content authors include as their fallback  
> content?

> ... Finally,

Well, you explain the attributes below so this isn't final ;)

> 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...

I think that this is a non-starter. As explained in a narrower follow-up,  
the penalty to browsers who do this means that mainstream browsers simply  
won't, in all probability.

However the rest of the proposal is worth looking at:

> ... the 2 mandatory attributes are so basic in nature that it is
> unlikely that they will be 'gamed' or misused/abused.

I am not so sure. But I am glad to see this issue recognised as important  
in determining whether a proposal will work.

> 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.

This is likewise an important issue.

> 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

This is easy enough to game. Spamming systems that simply added a random  
bit of real text could be adapted to do it here as well in about 5  
seconds. Making title mandatory would be inconsistent with the use of  
title all over HTML.

If we want alt, we could add it. I think there may be value in that, even  
though I expect it to be misused a lot (I don't see that as overwhelmingly  
harmful). The use case is for a quick functional explanation of what you  
are missing, or not perceiving as clearly as needed to make sense of it,  
right? So it would help make a decision about whether to zoom the canvas,  
look inside for the alternative content, or just skip it and get to the  
thing you were looking for.

> 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

I am not sure why this should be mandatory. It's also the sort of thing I  
would see as being more generally useful (e.g. for anything that is  
aria-role="application"), and I think it is the kind of use case that RDFa  
might more effectively deal with.

> 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."
[etc]

Putting this in an attribute seriously reduces its utility - you have a  
big pile of text that cannot include markup. If there is a description  
elsewhere (be it on the page or on another page) then referring to it with  
aria-describedBy seems to make more sense. Otherwise, if it is useful then  
having it in the content of the element (which should be made available,  
as per UAAG [1]) seems more appropriate, since that can at least allow for  
markup (and links, etc).

> 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.
[...]

I think that given we are developing a new thing, the aria-describedBy  
should be used for this (it is in fact analagous to longdesc, just  
applicable to more elements). I also think that this should be the primary  
role of the content of the canvas element.

One issue that hasn't been articulated anywhere I can think of is what to  
do where you have multiple alternatives. Since most of the examples of  
canvas I have seen don't provide any meaningful alternative at all, this  
may be a use case based on wishful thinking, but in principle it is at  
least a reasonable thing to do...

> 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.

Again, I think that this is probably information that can be added to a  
description, and thus covered by the content/@title/@aria-describedBy

> It is important to state that this is just an opening proposal...

Sure, and I appreciate it as such.

cheers,

your friend

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Thursday, 19 March 2009 15:35:47 UTC